Newsgroups: news.software.b
Path: utzoo!henry
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: relaynews too slow
Message-ID: <1990Sep26.192930.10721@zoo.toronto.edu>
Organization: U of Toronto Zoology
References: <1990Sep23.000826.15925@zoo.toronto.edu> <49453@olivea.atc.olivetti.com> <1990Sep25.153101.2437@zoo.toronto.edu> <49460@olivea.atc.olivetti.com>
Date: Wed, 26 Sep 90 19:29:30 GMT

In article <49460@olivea.atc.olivetti.com> jerry@olivey.olivetti.com (Jerry Aguirre) writes:
>>There seems to be a general illusion that real-time connections are exempt
>>from considerations of efficiency...
>
>It is a pretty convincing illusion.  Certainly the NNTP/network
>connections transfer a lot more news with less CPU load than UUCP
>had...

This is more a function of the nature of the hardware -- typically doing
a packet at a time rather than a character at a time -- than of the
protocol, I would say.  I'm told the costs of NNTP are *not* trivial.
And processing articles one at a time is massively inefficient, even
if the inefficiency is spread out so it's not so noticeable.  Your
machine is being gnawed to death by mice rather than trampled by an
elephant, but it's still losing just as much blood.

>Just how do you propose to prevent massive transmission of duplicates if
>"rnews" squirels away the articles without updating the history file?
>I seriouly want to know your philosophy on this.

There are several tactics on this one.  The one I would personally favor
is to keep a record of received-but-not-yet-processed articles separate
from the history file -- they *are* on disk, so there is no reliability
impact from not processing them immediately -- but I haven't had a chance
to experiment with this yet.
-- 
TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology
OSI: handling yesterday's loads someday|  henry@zoo.toronto.edu   utzoo!henry