Xref: utzoo news.software.b:8129 news.admin:14935 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!news.cs.indiana.edu!maytag!xenitec!wynnds.xenitec.on.ca!timk From: timk@wynnds.xenitec.on.ca (Tim Kuehn) Newsgroups: news.software.b,news.admin Subject: Cnews "dropped article" Notifications - another proposal Message-ID: <1991Jun4.161440.4161@wynnds.xenitec.on.ca> Date: 4 Jun 91 16:14:40 GMT Organization: TDK Consulting Services Lines: 128 I made a previous proposal about a possible way to notify site admin's that articles are being dropped via some kind of post to news.lists or other relevent newsgroup, and got a reasonable response. There were some shortcomings in that proposal, which, on further thought, I now think I've overcome and present below. Comments, thoughts, and criticisms welcome. Please keep flames to a low-boil :) Praise always welcomed :) Overview: --------- The big part of the hoopla about the current Cnews method of handling badly formatted articles is the fact that Cnews only logs the error, but does not report it. Current proposals on the floor suggest mailing a notification to the offending site admin or posting a list of bad articles to a newsgroup. This falls down when you consider that some sites with a wide fan-out before hitting a current patchlevel Cnews site(s) could theoretically find themselves bombarded with email or the newsgroup flooded with notifications. This is not good. Problem with current proposals: ------------------------------- What seems to be the problem with these kind of proposals is that they're attempting to notify the offender of their errors in a manner that is *too detailed* with article numbers, error types, etc. If too many sites notify one site or set of sites this could lead to a swamping of whatever transmission media (and possibly store-and-forward spool space) may be between the offending site(s) and their upstream feeds, not to mention the hapless sysadmin who finds himself swamped with mail. Alternative Proposal: --------------------- What is *really* needed here is a simple "You're site is posting bad articles" message getting back to the offender, as well as notification of the site name where an error was found. Do *not* include the error type or any article numbers, let the offending site's sysadmin *mail* the sysadmin of one of the sites that caught the error asking for further clarification of what the error was. Assuming co-operative sysadmins (is that too much to expect?) the offender site's sysadmin can fix the problem causing the error and the problem'll be solved. If co-operative sysadmins *are* too much to expect :(, then make the implimentation of this module optional via Cnews's "build" script. If the sysadmin doesn't want to help out, he doesn't have to then. Advantages: ----------- - 100% reporting that errors have been found and articles are being dropped. - would not swamp the net in a net.terrorist fashion. Disadvantages: -------------- - Initially this article could be somewhat large until sites get their posting SW RFC compliant and would use up corresponding bandwidth. - would be repeatedly propogated between machines - does not give specific error messages detailing precise problems or message id's The News Article Design: ------------------------ The news article would be circulated in appropriate newsgroup with the following format: offender_site1: [site_name1:date1, site_name2:date4, site_name3:date7] offender_site2: [site_name1:date2, site_name2:date5, site_name3:date8] offender_site3: [site_name1:date3, site_name2:date6, site_name3:date9] Where: ------ offender_site - the machine name of the site who's posting non-acceptable news articles. site_name - the machine name of the site who caught the badly-formatted news articles and dropped them on the floor date - the last date this site found a badly-formatted article from offender_site. Local "Offender Site" File: --------------------------- offender_site1 error_date1 offender_site2 error_date2 offender_site3 error_date3 offender_site4 error_date4 This would be a local copy of the list of offenders kept by the machine, and would be used to update the news articles when they come in. Procedure: ---------- 1) An article of the above format is received by the site and stored in the system somewhere. 2) This article would be compared against the local "offender_site" list. Any differing or omitted entries in the news article compared to the local offender-site list would be updated in the news article to reflect the current offender-site name and date information. (Note: the news article would only be scanned for entries made by the *local* site. Other site information would not be touched but left to the remote sites to update as required.) 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. Crontasks: ---------- At periodic intervals, a crontask would scan the log file for offending sites who's articles had been dropped. It would then update the local offender-sites file to reflect the new last-error-found-date, and would also scan for expired last-error-found in the offender-site local file entries and delete them if they were too old. 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. ------------------------------------------------------------------------ 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.