Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site faron.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!linus!faron!kbb
From: kbb@faron.UUCP (Kenneth B. Bass)
Newsgroups: net.dcom
Subject: Re: XON/XOFF Deadlock
Message-ID: <415@faron.UUCP>
Date: Wed, 18-Dec-85 15:39:23 EST
Article-I.D.: faron.415
Posted: Wed Dec 18 15:39:23 1985
Date-Received: Fri, 20-Dec-85 03:24:46 EST
References: <848@rlgvax.UUCP> <176@altos86.UUCP>
Reply-To: kbb@faron.UUCP (Kenneth B. Bass)
Organization: The MITRE Coporation, Bedford, MA
Lines: 47
Keywords: XON/XOFF protocol, deadlock, full duplex, tty driver, terminal
Summary: Who's flowcontrolling who?

In article <176@altos86.UUCP> jon@gateway.UUCP (Jonathan Stern) writes:
>In article <848@rlgvax.UUCP> dennis@rlgvax.UUCP (Dennis Bednar) writes:
>>multiplexor(MUX), flow control, out of band data
>>
>>I recently came across a very interesting situation which can
>>cause deadlocks over an asynchronous serial computer link when
>>both machines use the xon/xoff protocol, and the traffic is full-duplex
>>(both machines can send data to each other at the same time).
>>The deadlock causes both machines to cease transmission - permanently.
>
>                                   What this underscores is that XON/XOFF is
>not a practical flow control method for full duplex, high speed, data transfer.
>I would be very interested to hear how others have attacked this problem.
>
>-------
>Jonathan Stern Altos Computer Systems -- ucbvax!dual!vecpyr!altos86!jon


I have to disagree.  XON/XOFF flow controlling is practical for full duplex,
high speed data transfer.  This is assuming, of course that the XON/XOFF
characters are truly "out-of-band" characters.  It seems that the problem
above occurs because this MUX is only "semi-intelligent".  That is, it
sounds like the MUX is doing some of the flow controlling, but not all of
it.

The MUX should either: 1) do full flow controlling at both sides
(to/from network, and to/from host); or 2) do no flow controlling at all.
If case 1 is chosen, then the MUX would trap and process XON/XOFF's
it receives from the network, as well as from the host; but it would
not pass these characters through.  For the other case, the MUX would
be "dumb" and just pass the XON/XOFF's it receives - either from the host,
or from the network - through to the network or host.

The only major problem I have ever encountered with any type of flow
controlling is when does the receive end decide to send the XOFF signal.
In the latter case above, where the MUX is dumb and does not do any
flow controlling, then the XOFF must travel through the MUX, 
through the network, through the MUX to the remote host.  The remote
host will be sending data throughout this time, and will not stop
until it sees the XOFF.  The problem then, is how many characters
max will the host need to be able to buffer AFTER it sends out the
XOFF.


				"Tell me why"
				ken bass
				linus!faron!kbb