Path: utzoo!utgpu!watmath!looking!brad
From: brad@looking.on.ca (Brad Templeton)
Newsgroups: news.software.b
Subject: Re: cancel propagation (was Re: Supersedes problems with rapid-fire articles)
Message-ID: <6561@looking.on.ca>
Date: 1 Sep 89 04:46:19 GMT
References: <5200@looking.on.ca> <536@logicon.arpa> <3246@deimos.cis.ksu.edu> <1989Aug30.174430.20687@anise.acc.com> <1989Aug31.034105.2177@utstat.uucp> <6233@looking.on.ca> <1989Sep1.004629.17171@utstat.uucp>
Reply-To: brad@looking.on.ca (Brad Templeton)
Organization: Looking Glass Software Ltd.
Lines: 35
Class: rebuttal

In article <1989Sep1.004629.17171@utstat.uucp> geoff@utstat.uucp (Geoff Collyer) writes:
>I don't believe one can assume, in general, that a site will get an
>article and its cancel from the same neighbour, nor even assume that
>they will travel the same routes.  Remember that notions of "upstream"
>and "downstream" are fuzzy and don't even always apply to leaf sites.
>Thus it is possible for a cancel to arrive before its target.  Throwing
>away cancels (due to absence of its target) will tend to cause some
>sites to never see a cancel even though they will see the target.

I don't follow this.  If you get a cancel for an article that isn't
there, and you remember it but don't send the cancel message, how is
the downstream site going to see the article itself?  You're not going
to send it to them, after all.  You're not going to send it to anybody,
since its message ID is already in your database, and you will simply
toss it (as a duplicate, for example) if it ever shows up.

So the only way they could see the article is through a path that doesn't
come via you.  But any path that sends them the article will also send
them the cancel message.

Yes, if the other path is all old B news that throws away cancels and
doesn't record that they came, and the cancel comes through first,
then there is a problem.  But that's hardly your site's problem.
You have done your duty by making sure you never send out the cancelled
article.

The fix to either news version is trivial.  If a cancel or supersedes
comes in for a message that's not already there, story it in the
message-id database as an expired article.  Throw away the cancel message.
All future attempts by that article to arrive will cause it to be
rejected as a duplicate.   For extra points, put a flag on the database
entry that says "cancelled" instead of just expired, so that you can
say "cancelled" in the log file instead of "duplicate."
-- 
Brad Templeton, Looking Glass Software Ltd.  --  Waterloo, Ontario 519/884-7473