why does uucico do it this way???

Thread View: net.bugs.uucp

2 messages

[T] Back to Threads [V] Tree View [G] Group Articles

2 total messages Started by Mike Wescott Wed, 08 Oct 1986 20:13

#635

Author: Mike Wescott
Date: Wed, 08 Oct 1986 20:13

36 lines
1523 bytes

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

Re: why does uucico do it this way???

#640

Author: Peter Honeyman
Date: Mon, 13 Oct 1986 16:19

42 lines
1970 bytes

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

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads