john@genrad.UUCP (John Nelson) (02/04/84)
Someone is spitting out old news again. Either a site was down long enough to delay the articles for longer than two weeks, or we just have some very long loops. I can't determine who is sending the news around for the second time, but it points out the need for a better expiration algorithm. The history file should not delete articles that have been deleted (expired) for some longer period of time, so that if the article shows up AGAIN, the system is smart enough to reject the article as having already been seen. This does not mean that the articles should be kept any longer (in fact, a shorter period of time might be desirable!) but that the HISTORY of articles should be kept for MUCH longer. Maybe this would not have to be implemented at all sites either, as long as the backbone sites do not try to pass on old news.
gjm@ihnp4.UUCP (Gary J. Murakami) (02/05/84)
ihnp4 stores three weeks worth of news rather than two due to the occasional burps of old news due to propogation delay. But the recent old news repeats are newer than three weeks old. So there has to be another reason (munged headers?)... Gary Murakami AT&T Bell Laboratories ihnp4!gjm
jdi@psuvax.UUCP (John D. Irwin) (02/05/84)
I decided the solution to this problem was just to store a lot of news. Eight
weeks, to be exact. Seriously, though, I don't think that this particular
solution is applicable for too many sites (without huge drives). I think more
the solution lies in fixing the PROBLEM, not trying endlessly to protect every
single news site against one faulty site or sites.
--
Spoken: John Irwin
AT&T: 814-237-5068
Net: jdi@psuvax1.BITNET jdi@penn-state.CSNET
UUCP: {akgua, allegra, cornell, ihnp4, burdvax}!psuvax!jdimark@cbosgd.UUCP (Mark Horton) (02/06/84)
Here are the paths of some of the old articles that reached cbosgd in the last few days: cbosgd!mhuxl!houxm!hogpc!drutx!drux3!ihnp4!inuxc!inuxd!porter cbosgd!mhuxl!houxm!hogpc!drutx!drux3!ihnp4!inuxc!pur-ee!uiucdcs!miller cbosgd!mhuxl!houxm!hogpc!drutx!drux3!ihnp4!inuxc!pur-ee!uiucdcs!miller cbosgd!mhuxl!houxm!hogpc!drutx!drux3!ihnp4!inuxc!pur-ee!uiucdcs!uiuccsb!dollas cbosgd!mhuxl!houxm!hogpc!drutx!drux3!ihnp4!inuxc!pur-ee!uiucdcs!uiuccsb!dollas cbosgd!mhuxl!houxm!hogpc!drutx!drux3!ihnp4!inuxc!pur-ee!uiucdcs!miller cbosgd!mhuxl!houxm!hogpc!drutx!drux3!ihnp4!inuxc!pur-ee!uiucdcs!uiucuxc!tynor cbosgd!mhuxl!houxm!hogpc!drutx!drux3!ihnp4!harpo!decvax!ittvax!wxlvax!rlw cbosgd!mhuxl!houxm!hogpc!drutx!drux3!ihnp4!ixhte!gary cbosgd!mhuxl!houxm!hogpc!drutx!drux3!ihnp4!ihuxe!mbc cbosgd!mhuxl!houxm!hogpc!drutx!drux3!ihnp4!harpo!decvax!dartvax!dalcs!y2175 cbosgd!mhuxl!eagle!hou5h!hou5a!hou5d!hogpc!drutx!drux3!ihnp4!alberta!ubc-vision!uw-beaver!tektronix!ucbcad!ucbvax!ucbtopaz!unisoft!ed cbosgd!mhuxl!eagle!hou5h!hou5a!hou5d!hogpc!drutx!drux3!ihnp4!alberta!ubc-vision!uw-beaver!ssc-vax!ginger As you can see, they all have ihnp4->drux3->drutx->hogpc in the path. What appears to have happened is a logjam in UUCP somewhere in this path burst loose after about 3 weeks. I think the jam occurred in Denver, but it might have been on ihnp4 or hogpc. (Since these are the only paths into and out of Denver, thought, it seems unlikely that the jam wasn't there too.) Mark
gjm@ihnp4.UUCP (Gary J. Murakami) (02/06/84)
This may shed some light on the problem. While ihnp4 usually keeps a 3 week history of news, we had a hit on the history file on Feb. 1. This means that the 3 week "protection" against laggard duplicates on ihnp4 broke down recently. So our neighbors were left to their own history files to eliminate duplicates (typically 1 week). It appears that the net has a greater than 1 week propagation delay along certain paths, so our neighbors received duplicates (sorry). Gary Murakami AT&T Bell Laboratories ihnp4!gjm P.S. The history file may have been hit due to lack of disk space, however my current guess is that we had multiple expires running.