Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!umix!honey
From: honey@umix.UUCP (Peter Honeyman)
Newsgroups: net.bugs.uucp
Subject: Re: why does uucico do it this way???
Message-ID: <167@umix.UUCP>
Date: Mon, 13-Oct-86 12:19:14 EDT
Article-I.D.: umix.167
Posted: Mon Oct 13 12:19:14 1986
Date-Received: Mon, 20-Oct-86 22:15:13 EDT
References: <736@sauron.UUCP>
Reply-To: honey@umix.CC.UMICH.EDU (Peter Honeyman)
Organization: University of Michigan
Lines: 42
Keywords: Honey Danber, uucp, uucico, cico.c

this looks better, doesn't it:

	for (;;) {
		ret = imsg(msg, Ifn);
		if (ret != 0)
			break;
		if (msg[0] == 'O')
			break;
		omsg('O', "OOOOO", Ofn);
	}

or even better:

	for (omsg('O', "", Ofn); imsg(msg, Ifn) != 0; omsg('O', "", Ofn))
		if (msg[0] == 'O')
			break;

don't do it.

the 'O' (for OverAndOut) protocol provides for orderly release of the
network connection.  note that both cico's execute this code fragment --
there's no more master/slave relationship -- and that transport layer
protocols have been turned off.  let's look at the protocol in detail, and
at how timing can ruin things.

cico #1 sends his 'O'; when he receives one back, he closes his side of
the network connection.  suppose cico #2 is slow on the uptake; he sends
his 'O', but before he can receive one back, #1 drops the connection,
flushing the 'O' in transit to #2.  oops, no orderly release.

now for a gross hack (this is, after all, uucp): each cico sends two 'O's,
giving some slack time for orderly release.

a sleep would have the same effect, but the hangup protocol isn't really
worth worrying about -- it leaves a benign turd in the status file if it
fails -- so an additional delay in terminating what might be a very
expensive network connection isn't worth the hassle.

note that in all modern uucp's, imsg() strips msg[0] to 7 bits to avoid
parity problems.

	peter