On Mon, 24 Mar 1997 proff@suburbia.net wrote:
> > Here's an abbreviated transcript of the *per group* conversation,
> > ignoring the beginning and ending parts:
> >
> > <- list active newsgroup-name
> > -> 215: list:
> > -> newsgroup-name <high> <low> <flag>
> >
> > This is repeated for each newsgroup in the screen. I suspect it tries
> > to avoid a full 'list active' which can be a long operation on a
> > loaded server.
>
> Ugh. That is rouge behavior.
>
> The list command should NOT be used for obtaining upto-date singular
> group information. The GROUP command is the correct place for that.
But they are checking if the newsgroup exist at all, for which LIST
ACTIVE is the proper tool! :-) They aren't interrested in *entering*
the group, for which GROUP would be the command to use.
GROUP enters a newsgroup and gives more detailed information about a
newsgroup, information that isn't necessary for a newsgroup
selector... It's not unreasonable to expect an *active* cacheing
news-server to start pre-fetching articles when it gets the GROUP
command!!!
Nothing short of LISTGROUP will get a correct number of articles, and
even that won't work if you have kill-files, so the extra information
isn't that valuable. Neither of them are reliable on nntpcache
anyway... (there might be articles beyond what nntpcache currectly
consider the high-water mark)
If someone manages to convince GROUP really is the way to go I will
try to change the trn4 source-code, and to get the patch accepted, but
currently I feel that the behavior trn4 shows is better than using
GROUP. The overhead of GROUP could be almost unmeasurable large for an
active pre-fetching cacheing server.
I suspect that even if there might not exist any active pre-fetching
news-servers now they might well evolve later, possibly even from
nntpcache (v2 ? :-)), and in that case using GROUP may be a serious
mistake.
I might be convinced if testing shows that other news-servers also
have much higher overhead for LIST active than GROUP, I might write a
test program and run it against our INN server.
> nntpcache can locate an individual group data from the sum of
> newsgroups very quickly. It uses a 31337 (prime) entry hash table,
> with binary trees for resolving hash collisions.
>
> RFC977 defines the arguments to list as:
>
> LIST {active,newsgroup,active,times,overview.fmt} [pattern]
>
> Note the optional usage of the pattern keyword. This is typically used for
> examples like:
>
> LIST active alt.*
>
> and not for pulling in information on a specific group in isolation, which is
> what your news-reader appears to be doing. When the pattern argument is
> specified, nntpcache walks the entire group list, pattern matching every
> against every group.
Hmmm, AFAIK the RFC says nothing about intended usage, time to dig
them up.
Most people are probably accustomed to INN/CNEWS et al, and in that
case the server have a full LIST active available, the only thing it
has to do for LIST active <pattern> is to run a reg-exp package over
the 'LIST active' list and send the result.
--
Torbjörn Lindgren
E-mail: tl@funcom.com
If Santa ever DID deliver presents on Christmas Eve, he's dead now.
