Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.bugs.uucp
Subject: Re: 4.2 uucp bug?
Message-ID: <2403@sun.uucp>
Date: Tue, 9-Jul-85 21:38:04 EDT
Article-I.D.: sun.2403
Posted: Tue Jul  9 21:38:04 1985
Date-Received: Fri, 12-Jul-85 04:08:26 EDT
References: <226@nsc-pdc.UUCP>
Distribution: net
Organization: Sun Microsystems, Inc.
Lines: 40

> When I look in LOGFILE I see the "OK (conversation complete)" message
> followed by a "TIMEOUT (machine-name)" message. It looks like our 4.2 BSD
> machine is missing the "OOOOO" message from the other machine.

Actually, this bug's existed in most versions of UUCP since the beginning of
time; the 4.2BSD one is the only one (with the possible exception of honey
danber) which actually bothered to report the timeout, so I guess nobody
knew about it until then.  The hangup sequence for UUCP is supposed to be:

Master - sends H, indicating it has no more work and is ready to switch
	roles (if the slave has work) or hang up (if the slave has no more
	work either), and waits for an HY or HN from the slave
Slave - if it has no work, it responds with HY and waits for an HY or
	HN from the master
Master - reads the HY from the slave, sends an HY, turns off the protocol
	on its end (reverting to the initial "imsg"/"omsg" protocol),
	sends an OOOOO, sends another OOOOO, and waits for the slave to
	reply with OOOOO
Slave - reads the HY from the master and shuts down the same way the master
	did

However, when the slave reads the HY from the master, instead of shutting
down immediately, it sends back *another* HY.  If the "g" protocol is being
used, this means that there is unacknowledged output; the slave waits for an
acknowledgment which never comes.  Eventually, it times out, but in the
interim the master hasn't seen its OOOOO and times out also.

This is somewhat timing dependent, so you may not get this sequence every
time - however, the bug in the protocol is obvious.  Either the slave should
not send an HY when it receives the HY, or the master should expect an
additional HY in response to the HY it sent.  I originally implemented the
second solution - it's not the "correct" solution, but it does match what
most systems do.  Rick Adams later implemented the first solution, and I
believe 4.3BSD will have his UUCP.  That is the right solution; furthermore,
it made some timeouts that the second solution caused to occur (it seemed to
happen either when talking to System V UUCP or honey danber UUCP, I'm not
sure which) go away.  Since I don't care whether the other guy gets spurious
timeouts (they don't clutter my "uustat" output), I prefer that solution.

	Guy Harris