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