[net.bugs.uucp] why does uucico do it this way???

wescott@sauron.UUCP (Mike Wescott) (10/08/86)

Honey Danber uucp has the following code fragment to execute when closing
down the connection:

from cico.c
		.
		.
		.
	(void) alarm(2 * MAXMSGTIME);	/* give slow guys some thrash time */
	omsg('O', "OOOOO", Ofn);
	CDEBUG(4, "send OO %d,", ret);
	if (!setjmp(Sjbuf)) {
		for (;;) {
			omsg('O', "OOOOO", Ofn);
			ret = imsg(msg, Ifn);
			if (ret != 0)
				break;
			if (msg[0] == 'O')
				break;
		}
	}
	(void) alarm(0);
		.
		.
		.

Why do two consecutive omg('O',"OOOOO", Ofn) calls before calling imsg() ?

It has caused problems on a (non-TTY) channel with scarce buffering resources.
I've fixed the behavior of the channel but wonder if there is a reason for
the double omsg(), or whether putting omsg at the bottom of the for(;;) loop
would work as well.  Are there compatibility problems with other verions if
such a change is made?

	Mike Wescott
	ncrcae!wescott

honey@umix.UUCP (Peter Honeyman) (10/13/86)

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