Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!ames!vsi1!teraida!news
From: news@teraida.UUCP (Teraida Newsadm)
Newsgroups: news.software.b
Subject: Re: Forwarding Cancels For Unreceived Articles (A suggestion)
Keywords: suggestion cancels
Message-ID: <10976@teraida.UUCP>
Date: 20 Sep 89 07:39:58 GMT
References: <5200@looking.on.ca> <66812@uunet.UU.NET> <1989Sep7.151826.11816@i88.isc.com> <3919@hplabsz.HPL.HP.COM> <5553@videovax.tv.Tek.com> <11111@looking.on.ca> <1989Sep19.164120.26245@eci386.uucp>
Organization: Teradyne EDA Inc., Santa Clara, Calif.
Lines: 67

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.