Xref: utzoo news.admin:15332 news.software.b:8321 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!crdgw1!crdos1!davidsen From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) Newsgroups: news.admin,news.software.b Subject: Re: automatically mailing warnings about dropped news to originators Message-ID: <3437@crdos1.crd.ge.COM> Date: 18 Jun 91 20:03:13 GMT References: <1991Jun12.163939@mccall.com> <1991Jun14.224045.26157@zorch.SF-Bay.ORG> <1991Jun17.105848@mccall.com> <1991Jun18.113758.16382@zorch.SF-Bay.ORG> Reply-To: davidsen@crdos1.crd.ge.com (bill davidsen) Followup-To: news.admin Organization: GE Corp R&D Center, Schenectady NY Lines: 76 In article <1991Jun18.113758.16382@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: | Not at all true if a month of news gets barfed back | onto the net by a mechanism that looks like a bad | header problem and evokes this mechanism you defend; | at that point, if the Bnews site connectivity from | the failing site is enough to get the barf out to | the "whole net", the deluge of messages this | mechanism you defend would dump on the net would | disable the whole net for a significant period of | time, like weeks, while sysadmins cleared up the | junk while trying to preserve the news and mail. I don't think you thought that one through. Start with two statements which I believe are widely if not without exception true. 1. we would generate a reject notice for badly formed articles 2. we would not forward rejected articles Thus you are unlikely to have anything broken reach "the whole net." I would also question a failure mechanism which would mung old articles in such a way that they would satisfy these criteria to cause problems: 1. munged enough to be rejected elsewhere 2. intact enough to be accepted by news locally 3. intact enough to be sent out. Remember that sendbatch runs from the database at most sites, and just restoring the articles won't send anything. Also, batches are compressed, and I can't believe damage as limited as is needed to satisfy the requirements above could happen in a compressed file. Finally, bad messages generating warnings would generate a reply from at most every site at which they were received, hardly likely to bring down the net with a few lines per site worst case. Some weeks I get my sys file requested 6-7 times in a week, and that doesn't even make a bobble in the volume curve. I bet some of the postings have generated flames from more readers than one per site, and the net survived. The fact that rejectors don't propigate saves the volume. In short I believe your scenario of gigabytes of rejects is an overexageration of any worst case failure I can imagine. | Don't know about where you are, but here the dropped | news and other problems require redundant feeds and | still we miss parts of source group multi-part | postings and such. Using a threaded newsreader like | trn gives you a new appreciation of just how much | news _never_ gets to your site; I'd guess the raw | failure rate is between 5% and 15% of all news goes | missing with a single feed, 2%-5% with two fairly | independent feeds. Depends on the quality of the feed. Some news is dropped at the site, and unless you have a feed right from them you don't get it. The volume dropped in a feed from a site like uunet is probably a lot less than the 2% you quote. I can't measure easily, because a lot of news here come *first* from another site. I can tell there's a lot of news I didn't get from uunet, but I can't tell if I would have gotten it if I didn't already have the article. | More important, it is probably really worthwhile | putting up and agreeing upon the design goals for | notification, before haranguing about whether one or | another proposed design meets the goals; a moving | goalposts problem again. It is always worth setting the goals before evaluating the solutions. I sense a lack of agreement that letting the poster know about rejections is not a goal in C news. I can't help think that dropping the news, not saying that it was dropped, and not saying why, is a case of putting the computer before the user. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) GE Corp R&D Center, Information Systems Operation, tech support group Moderator comp.binaries.ibm.pc and 386-users digest.