🚀 go-pugleaf

Just one (umm, well, three) minor point(s)..:

In news.software.b, article <1gmasdINNgg4@news.UU.NET>,
  tale@ten.uu.net (David C Lawrence) writes:
> Matthias Urlichs:
>    - Reworked "newsfeeds" (nee sys) file with much finer control as to what
>      actually gets written to batch files.
> 
> First off, I don't think you really have that much finer control.
> Secondly, I have philosophical differences here.  It is my belief that
> someone who has requested "rec.bicycles" would by default like to get
> whatever rec.bicycles is reorganised to.  [...]

I was actually talking about the third field, which under C News has flags
like "f" or "F" -- I never could remember what these mean. :-/

INN has things like "Tc,Wnmb,<65536" which translates to "this is a channel
(i.e.  the fourth field is interpreted as a command name) to which relative
file name, message ID, and article size are written (one line per article),
and the remote system doesn't want to see any article bigger than 64k".

This means that if you want to log every article, all the newsgroups it's
posted to, where it's coming from, where it's going, et al., all you have
to do is to hook up one statistics gathering program into INN. In my
opinion, this is preferable to scanning log files and reopening articles
to get some of the data (unless the article is expired or cancelled...).

I do know that not everybody needs all of this, but the added flexibility is
important for some sites.

>    - Directly feed the batch into a program, via pipe. People have been seeing
>      article transfer times on the order of 200 msec, using this method to feed
>      another system via nntplink.
> 
> This is a win if you really care.  I think it is a mistake to care
> about 200msec propagation times, even having been one of the very
> first people to run relaynewsd and nntplink with logfile mode.

I don't really care either, except that your article will most likely still
be in the buffer cache during those 200 msec and that nobody needs to
constantly create/write/look for/rename/read/remove batch files. The
200 msec are a neat but relatively unimportant side effect.

On our previous News machine, with relatively slow disks but reasonably
large main memory, this translated into noticably less system load than
the equivalent C News setup. Your mileage will vary.

Besides, if everybody runs INN+nntplink, how else do you stay among
the first 20 sites in the Top 1000 listings?  :-)  :-)  :-)
(This obviously is no problem for UUNET.  :-)  :-)

>    - Combine the previous two to do some really ugly things like statistics
>      gathering or sendsys-bomb cancelling. Especially the latter isn't really
>      doable, given the above subsecond transfer times, unless you can get the
>      Cancel into your news server _right_now_.
> 
> There doesn't seem to really be that big a win for INN here, either,
> except maybe in that cancelling area.  Then again, how much do you
> really have your server really making such time critical assessments of
> message validity automatically?
> 
The (small) effort to do this validation will pay for itself the first time
somebody forgets to limit their sendsys message's distribution. It has done
this a number of times, in our case.

-- 
Matthias Urlichs  --  urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de   /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  +49-721-9612521     \o)/