bart@videovax.tv.Tek.com (Bart Massey) (09/11/89)
The reason that I, at least, am persuaded that cancels should be forwarded whenever there is any doubt about whether the downstream site will receive them is simple cost-benefit analysis. Generally, cancel messages are only sent when a poster has done something really stupid -- the consequences of the cancel failing to reach some machines can be devastating, either emotionally/psychologically or, as in the case described below, legally. The cost of spreading extra cancel messages is very low -- they generally are just a collection of headers, with a zero or one line body. Given the low cost and the high benefit of the redundancy obtained, IMHO there is only one correct choice. Note that, as earlier posters have pointed out, even if every site were running the latest, most perfectly functional software (fat chance :-), cancels might be dropped during transmission... About 5 years ago, a person broke into the account of a Reed College professor (who had chosen a truly lame password), and posted a demo version of a copyrighted commercial Macintosh program with its copyright notice altered to state that the program was "shareware" written by said professor, for which he was charging $25. As the sysadmin and asst. sysadmin were out of town at the time (my first week on the job, but that's another story :-), it fell to me to handle the situation. Well, of course, by the time I found out about this, 2 days had passed (Saturday and Sunday). The first thing I did was send a cancel message off. The second was to post a note apologizing, asking people to remove any copies they'd saved, etc. Imagine my surprise when a number of people sent me flames of the form "why the @#$% didn't you cancel the article??". These were followed about a day later by guru-level explanations of why cancelling the article only caught (in this case) about 10% of the net -- since these explanations have been given many times in this forum, I won't bother to repeat them. As a result, the professor in question was threatened with legal action -- in part because we had supposedly been somewhat negligent in taking remedial action. I, at least, am convinced that we would have experienced much less hassle if everyone had propagated cancels regardless of whether they received the article first... Bart Massey ..tektronix!videovax.tv.tek.com!bart ..tektronix!reed.bitnet!bart
brad@looking.on.ca (Brad Templeton) (09/12/89)
Well, perhaps what's needed is an emergency cancel and a regular cancel. Actually, a cancel to news.config.ctl will probably zip around the whole net very quickly, although that may not be widely known. All I know is that I put out around 200 cancel messages per day. Most of them should never leave this site, and only a few are intended to make it more than one or two sites downstream. Supersedes would have been a lot easier but we all know why I couldn't use it. It will cause no harm to send them all out over the whole subnet, it will just waste disk space and money. -- Brad Templeton, Looking Glass Software Ltd. -- Waterloo, Ontario 519/884-7473
jmm@eci386.UUCP (09/19/89)
In article <11111@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes: > [...] > >All I know is that I put out around 200 cancel messages per day. Most >of them should never leave this site, and only a few are intended to >make it more than one or two sites downstream. Supersedes would have >been a lot easier but we all know why I couldn't use it. > >It will cause no harm to send them all out over the whole subnet, it will >just waste disk space and money. >-- >Brad Templeton, Looking Glass Software Ltd. -- Waterloo, Ontario 519/884-7473 Most of the discussion about the "cancels should be propagated netwide" is perfectly correct, yet Brad's case shows an important exception. If a cancel is processed on the original system and can ensure that the article has never left that system (and is not irretrievably batched to leave the system), then it is safe to handle the cancel locally only. After the article has left the original system, then the earlier arguments that the cancel should be propagated netwide are appropriate. The trick is determining whether an article has "left the system". I make no claims about whether such a determination can be accurately made with any of the current news transport mechanisms (particularily for all possible combinations of batched/unbatched ihave/sendme partial feeds, etc.), but I expect that C-news provides enough flexibility for a knowlegable sysadmin to extend it to make such determinations for his own specific configuration. -- "Software and cathedrals are much the same - | John Macdonald first we build them, then we pray" (Sam Redwine) | jmm@eci386
news@teraida.UUCP (Teraida Newsadm) (09/20/89)
jmm@eci386.UUCP writes: >In article <11111@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes: >> [...] >> >>All I know is that I put out around 200 cancel messages per day. Most >>of them should never leave this site, and only a few are intended to >>make it more than one or two sites downstream. . . . >Most of the discussion about the "cancels should be propagated netwide" is >perfectly correct, yet Brad's case shows an important exception. >If a cancel is processed on the original system and can ensure that the >article has never left that system (and is not irretrievably batched to >leave the system), then it is safe to handle the cancel locally only. Here's a suggestion. I invite discussion and/or criticism of my idea, but flames to /dev/null. There are five basic cases 1) the article arrives but no cancel ever arrives, 2) the article arrives followed later by a cancel, 3) a cancel arrives, but the article never arrives, 4) the cancel arrives followed by the article, 5) neither arrives. 1) Article is not cancelled. The cancel was lost, but this rare, and does not change the way cancel currently works. No action is required. 2) Cancel deletes the article and marks it so in the history file. The cancel is propagated downstream. 3) Article is entered into history file as cancelled, but not propagated since we never propagated the original article. 4) Arrival of cancel has same effect as 3. Later article arrives. Regenerate cancel request passing it back upstream from whence the article arrived, or to all feeds, if more reliability is desired. 5) No action required. The effect of this strategy is that if your system has seen the article then it propagates the cancel as well. If the article never made it to your downstream sites, then they mark the article as cancelled and do not propagate the cancel as per case 3. So in this case the cancel goes one system farther than it needs to, but no further. The reason for regenerating the cancel request in case 4, is in case the cancel gets dropped somewhere along the way, it is regenerated to continue cancelling the original article. This gives cancel some additional robustness, to overcome network unreliability. I know that this solution does not guarantee that the article is cancelled everywhere, but it should work with a high degree of reliability. It also stops propagating the cancel needlessly when the article is confined to one or just a few systems. Of cource, if a cancel follows another cancel, the duplicate cancel is not propagated. Cancel propagation stops when a cancel arrives on a system that has already cancelled the article or has never seen the article. -- Mikel Lechner UUCP: mikel@teraida.UUCP Teradyne EDA, Inc.