Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!oliveb!olivey!jerry
From: jerry@olivey.olivetti.com (Jerry Aguirre)
Newsgroups: news.software.b
Subject: Re: Supersedes problems with rapid-fire articles
Message-ID: <47702@oliveb.olivetti.com>
Date: 7 Sep 89 20:07:26 GMT
References: <66812@uunet.UU.NET> <1989Sep7.121502.11649@.uucp>
Sender: news@oliveb.olivetti.com
Reply-To: jerry@olivey.UUCP (Jerry Aguirre)
Organization: Olivetti ATC; Cupertino, Ca
Lines: 26

In article <1989Sep7.121502.11649@.uucp> trent@.uucp (Trent MacDougall) writes:
>A small machine (A) gets a large feed, but doesn't have the room to keep
>the articles around for long, so it expires some groups daily and others
>every 3 days and yet others every 5 days.  This small site feeds a larger
>machine (B) that keeps the articles around for 2 weeks, and it too feeds
>other sites.  So a cancel message comes and fails on A and never gets
>forwarded to B who still has the article (and quite possibly some of the
>sites B feeds).

Even if site A expires the articles it should still keep them in its
history file for at least 2 weeks.  So when the cancel arrives it should
see the entry in the history file, mark it as canceled, and forward the
message.

Of course this again gets into the fine points of the meaning of having
the cancel succeed.  The article wasn't on the system so it couldn't
actually be removed.  But the history entry was.  The intent
seems clear to me even if the wording of the RFC is a little vague.

Clearly this is an issue of robustness verses effeciency.  Nothing
breaks if the control message is sent round the world;  we just all pay
for a few more bytes.  Just as clearly it will not always catch all the
copies of the target articles even under the kind of failures it is
touted for.  So the trade off is the extra overhead where the cancel
catches up with its target against the extra number of places were the
cancel doesn't catch up.