Path: utzoo!utstat!news-server.csri.toronto.edu!math.lsa.umich.edu!caen!sdd.hp.com!usc!apple!olivea!olivey!jerry
From: jerry@olivey.olivetti.com (Jerry Aguirre)
Newsgroups: news.software.b
Subject: Re: C News Ihave/Sendme
Message-ID: <49282@olivea.atc.olivetti.com>
Date: 15 Aug 90 21:30:23 GMT
References: <1990Aug14.051835.209@media.medianette>
Sender: news@olivea.atc.olivetti.com
Organization: Olivetti ATC; Cupertino, CA
Lines: 52

In article <1990Aug14.051835.209@media.medianette> rmf@media.medianette (Roger Fujii) writes:
>I am missing something, it seems that Cnews generates a 'sendme' AS
>SOON AS it processes the ihaves.  This destroys any advantage of delaying

>This seems to work, but I have this nasty feeling that this is too simple
>and I am missing something.  Any comments?

Yes, you are missing something.  An alternate way, that involves no code
changes, is to delay the transmission of the ihave messages.  There are
two basic ways to do this.  The first is to rename the "ihave" queue
file.  For example if the was a media.ihave file you could at cron
scheduled intervals rename it to media.ihave.1 after first renameing
media.ihave.1 to be media.ihave.2, etc.  Then you generate the ihave
using media.ihave.N where N is the delay you want.  I use this scheme
here.  In fact I have a general "ihave" queue that I use to generate
ihaves control messages for multiple sites.

A second, simpler, method is to use "at" to schedule turning the ihave
queue file into a control message.  This places the burden on "at" to
save the input file away and run it at the proper time.  I havn't tried
this method personally.

A final improvement on the above is to queue the ihave message for
transmission with a low UUCP grade.  If your UUCP supports it queue
the ihave message separately (not in a batch) with a grade of "z".
That will allow normal batches to be transmitted, and hopefully
processed, before the ihave message.  With sendme messages you want
the opposit.  Queue it with the highest grade possible ("0").  Once
the sendme is issued the articles are going to be transmitted.  If they
are transmitted late then they will likely be duplicates because the
other feed will get there first.

Control of how the ihave and sendme messages are queued is possible
because they are queued using the "to.sitename" newsgroup.  So, a sys
entry like:

    to.media/media:world,to.media:BSUL:/usr/bin/uux -c -z -gZ media!rnews

would queue the ihave message with a very low grade.  A corresponding
entry on media could queue the sendme with a higher than normal grade.
Of course if you are both sending ihave/sendme then this method breaks
down.  A news group other than to.site could be used for the ihave
messages allowing different handling.  I contemplated using a
"from.site" group for a while.  That would allow a single ihave to go to
multiple news neightbors.

Of course by now you may have noticed that this places the burden on the
sending site rather than your method which puts the changes in the
receiving site.  Using the "at" method of delaying ihave messages
shouldn't be to hard for your feed to implement though.

				Jerry