🚀 go-pugleaf

In <1991Jun6.154027.1309@ecl.psu.edu> fenner@jazz.psu.edu (Bill Fenner) writes:
>In <1991Jun4.161440.4161@wynnds.xenitec.on.ca> timk@wynnds.xenitec.on.ca 
	(Tim Kuehn) writes:
>|3) If the news article was changed by the local machine, it would be
>|reposted to the net and shipped out with the next poll. If it was
>|not changed, then it would not be reposted.

>When you repost it, do you change the Message-ID?  If yes, you might get
>hundreds of articles in this group... let's say site a posts an article, and
>sends it to sites b and c.  

[..example deleted..]

This is the main sticking point with this proposal - particularly on sites
that are not running SW to impliment this scheme. The only way around that
problem would be to create a psuedo-group (news.errors?) with a 1-day
expire to punt off these messages soon after they've had time to be 
propogated. 

[..a rather convoluted second example deleted..]

>Now we have 5 articles, 2 of which are identical except for message-ID, 
>and only 2 out of the 5 have all the information needed.

The other idea would be to keep a master-file on site with the latest
dates reported for  *all* the offender-reporting sites on the net, (not 
just your local information), and the offending machines they found. This 
way it's not required that all error-packets pass through a given machine
in order to be completely updated, but instead error-found notification 
propogates through the system much like our current "flood" algorithm for 
articles.

Keep a current log of reporting sites on the system, and issue a copy 
of your own logfile once every n days (say, 7 days or so). While this 
increases the latency time of the notification, it decreases the BW 
requirements significantly.

>Also, how do you decide what machine posts the original message for 
>others to modify?

If a given machine doesn't have a copy of the relevent message, it makes
one and ships it out. 

>|Question/Caveat:
>|----------------
>|Under (3) above, if multiple copies of the article came in, provision
>|would have to be made to ensure that the number of copies kept on the
>|local spool area don't grow like wildfire, but only one file is kept
>|on the system at a time.

>So you would need more of a "pseudo-group", with a program running every
>once in a while to consolidate the articles (do you consolidate before or
>after you batch for other sites? ...).  

On sites running the updating SW there should only be one file on the 
system at a time. On sites that aren't running the updating SW - just 
pass it on and dump ASAP.

>Seems like an awfully CPU-intensive and high-bandwidth solution.

In it's original form it would be. If we introduce an artifical 
latency time to give error reports a chance to propgate through 
the net, the cpu time and BW requirements will decrease by a similar
factor.

>Bill Fenner     fenner@jazz.psu.edu     ..psuvax1!hogbbs!wcfpc!wcf
>                wcf@hogbbs.scol.pa.us   (+1 814 238-9633 2400MNP5)

------------------------------------------------------------------------ 
Tim Kuehn			 TDK Consulting Services  (519)-888-0766
timk@wynnds.xenitec.on.ca  -or-  !{watmath|lsuc}!xenitec!wynnds!timk
Valpo EE turned loose on unsuspecting world! News at 11!
"You take it seriously when someone from a ballistics research lab calls you."
Heard at a Unix user's meeting discussing connectivity issues.