Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!usenet
From: usenet@ucbvax.ARPA (USENET News Administration)
Newsgroups: net.news.b
Subject: Re: ihave/sendme and 2.10.3
Message-ID: <10545@ucbvax.ARPA>
Date: Sat, 5-Oct-85 04:31:23 EDT
Article-I.D.: ucbvax.10545
Posted: Sat Oct  5 04:31:23 1985
Date-Received: Sun, 6-Oct-85 04:30:54 EDT
References: <190@peregrine.UUCP> <606@oliveb.UUCP>
Organization: University of California at Berkeley
Lines: 84

The inherent problem with all of these schemes is that our base level
transport mechanism (UUCP) is batched, not interactive. To illustrate
what I mean, let's look over the base case:

Three sites A, B, and C, in the following configuration:

	A - B - C

let's say that both A & C are backbone sites, so that B is gonna get it
with both barrels. Let's further state that in an attempt to alleviate
this problem, B has turned on IHAVE/SENDME protocol on both links.

IDEAL sequence:

01) A gets article X from elsewhere and queues an IHAVE X to B
02) A & B connect and speak UUCP
03) B processes the IHAVE X, and queues a SENDME X to A
04) A & B connect and speak UUCP
05) A processes the SENDME X, and queues article X to B
06) A & B connect and speak UUCP
07) B processes article X, and queues an IHAVE X to C
08) B & C connect and speak UUCP
09) C processes the IHAVE X, and queues a SENDME X to B
10) B & C connect and speak UUCP
11) B processes the SENDME X, and queues article X to C
12) B & C connect and speak UUCP
13) C processes article X

Whew! Pretty laborious, wouldn't you say? One possibility that I don't
note in here is that the processing and queueing of a reply to any
message your neighbor just sent you, might get done quick enough to go
back out during the same conversation that the message arrived in
originally. However, it's not that likely, and it still wouldn't cut
down on the number of messages that have to go flying about to move
an article from A to B to C.

Now I'd like to consider a slightly less-than-ideal sequence.

BAD sequence:

01) A gets article X from elsewhere and queues an IHAVE X to B
02) A & B connect and speak UUCP
03) B processes the IHAVE X, and queues a SENDME X to A
04) C gets article X from elsewhere and queues an IHAVE X to B
05) B & C connect and speak UUCP
06) B processes the IHAVE X, and queues a SENDME X to C
07) A & B connect and speak UUCP
08) A processes the SENDME X, and queues article X to B
09) B & C connect and speak UUCP
10) C processes the SENDME X, and queues article X to B
11) A & B connect and speak UUCP
12) B gets article X from A, accepts it, and queues an IHAVE X to C
13) B & C connect and speak UUCP
14) B gets article X from C, and rejects it as duplicate
15) C processes the IHAVE X, and ignores it because it already has X

The problem here occurrs because `B' keeps no record of having asked
for an article from any remote system, and not having gotten it yet.

If you were to add that safe guard against asking for something twice
(or `n' times), you then have another problem. UUCP is known to drop
things on the floor occasionally, and if it drops your request for an
article into the bit bucket, you will never get the article.

Unless you have a timeout... which further delays transmission of
articles. And suppose that `A' (or `C') has expired the article by
the second (or third) time that you ask for it?

To make the IHAVE/SENDME protocol work, we need an interactive
transport level, where two netnews transmission agents can actually
converse both ways to say IHAVE, and the response be either, SENDME or
DONTSENDME (and if the SENDME response was recieved, transmission
should occurr immediately, to keep the window during which they could
get the article from some other system to an absolute minimum).
So long as we're stuck with the batch nature of UUCP, we lose.

The best, most reliable method for propagating netnews articles is the
one in common use today: check the path, and if the article hasn't
already been there, send it.

	keeper of the network news for ucbvax,
		and guardian of the gateway,

	Erik E. Fair	ucbvax!fair	fair@ucbarpa.BERKELEY.EDU