Problem using trn & INN 2.3.1 (fwd)

Olaf Titz olaf at
Thu Dec 7 09:06:41 UTC 2000

> trn does it's xover stuff to grab information.  However, because many of
> the articles are expired, much is not returned.  Trn is probably then has
> not yet assumed that the article is non-existent, but rather than the xover
> database is corrupt/out-of-date/or something.  So, later on, when trn tries

trn is just showing its age here. Try to monitor every command it
tries - looks like it is trying any NNTP extension ever conceived :-)
(Incidentally, tin does that too.)
When the trn 3.0 XOVER code was written, XOVER was an exotic
performance hack which _some_ people put into their NNTP "reference
implementation" to cache often-wanted information. trn had reason to
not expect XOVER to be available, and try a different protocol if it

What breaks:
- trn assumes the XOVER fails when it returns empty (BUT see my
  previous message that the command seems to really fail when it ought
  not to)

What is suboptimal:
- The chunk sizes follow the news volume in 1990
- XOVER is THE standard means of getting group data since INN 2.0

> >From the description given below, it sounds like INN generates the xover
> response differently depending on whether you pull the whole range or not.
> This is stupid, because it could be that at some point the client and the
> server are out of date as to what the entire range is, and the server is
> going to generate a large amount of data the very hard way.  Not a very
> brilliant design, IMO.

Right. This ought to be fixed. BUT on my system this works correctly.
Something must have changed in the last few monts breaking XOVER in
this margin case.

> > A Real Newsreader[tm] will keep track of the last article you read
> > in the froup, and only get information from that point forward.

Of course trn does do that. Apart from trn being the thing which comes
closest to a Real Newsreader of any I have ever seen, it is very
careful to process group data in a linear fashion, always starting
where it left off, and cache state as much as it can. Again, look at
the pattern in which XOVER is requested - this is optimized for a
server which keeps the overview file open or one which generates it on
the fly from a C News spool.

The reasons for not pulling the whole overview at once, I _think_ this
is the order of importance:
- Saving memory, in case the client is a 16-bit machine (just look at
  the trn source to find out how old it is, and warning, it is ugly)
- Giving the server "breathing breaks" (I think this is actually good
  client-side behavior)
- Allowing rather seamless background threading in the client
- Giving the user the chance to interrupt the process


More information about the inn-workers mailing list