timk@wynnds.xenitec.on.ca (Tim Kuehn) (06/11/91)
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.