Problem using trn & INN 2.3.1 (fwd)

[Patrick Vervoorn]

This is the first of two reactions I received on the trn-users
mailing-list.

Maybe it would be handy of INN and trn developers started talking with
each-other to work this out, because it seems there may be different ideas
about that each should/could expect of the other?

Best regards,

Patrick.

---------- Forwarded message ----------
Date: Wed, 6 Dec 2000 12:46:22 -0800 (PST)
From: Wayne Davison <trn at blorf.net>
To: Patrick Vervoorn <vervoorn at cddb.ubicom.tudelft.nl>
Cc: trn-users at lists.sourceforge.net
Subject: Re: Problem using trn & INN 2.3.1 (fwd)

On Wed, 6 Dec 2000, Patrick Vervoorn wrote:
> From: System Operatour <NewsUser at free-n0rp.NetScum.dk>
> This is ....  This is disgusting.   This is ...  st00pid.  This
> is incredibly stupidly obnoxiously brane-damaged.

[Since the fellow is being insulting, I am tempted to insult him back, but
I am resisting the urge.  Obviously the fellow does not understand the
intricacies of the (very limited) NNTP protocol.]

The reason that trn asks for data in chunks is so that it can be
interrupted.  The NNTP protocol does not allow for any kind of
out-of-band "stop" message (short of closing the connection), so,
when trn needs to do things in the background, it asks for things
in chunks.  Both INN and the reference NNTP were optimized for the
case of a newsreader asking for successive chunks.  If this
optimization was lost, that need to be fixed.

> Why do you need all the information from all the tens or hundreds of
> thousands of articles in such a froup, every time you enter it?

It's very simple.  Context.  Every article exists in a context of its
thread, and trn likes to know all the threads in the group.  This could
probably be optimized better even without resorting to a much-needed new
reader protocol, but that would involve asking for newsgroup chunks
backwards from new to old until all the threads of unread articles were
fully fleshed out (using the date of the head article as a stopping point
in time).  Even this wouldn't be perfect, though, since dates are often
mis-configured, and root articles are often missing.

A much-needed optimization (that someone really should write) is a way to
cache overview information locally so that only the new overview info
needs to be fetched.  Trn would then have to ask for a list of all current
article numbers to know which articles had expired or been canceled and
trim the vanished articles out of the list.

Another potential solution is to set a maximum group size so that trn will
just treat articles farther back than that as non-existent.  That would be
pretty simple to code up.  Any takers?

> It's usually the case that the first article present (when it's still
> present) of the range of hundreds of thousands is a long-lived FAQ,
> followed by a gap of tens of thousands of missing articles

Trn has an algorithm to deal with this that causes the newsreader to
position itself at the last known article and then issue a "next", which
should advance it past the whole gap and cause it to find the next chunk
of overview info.  If this isn't happening, then it sounds like something
is wrong with the news server's implementation of the NNTP reader
protocol.

Also, a previous email made it should like INN(?) is now doing the wrong
thing when it has no items to return in response to a request of an
overview subset that has no articles in it.  Someone should check this out
to be sure, but it should be returning an empty list, not an error.

..wayne..