Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: net.dcom
Subject: Re: XON/XOFF Deadlock
Message-ID: <6235@utzoo.UUCP>
Date: Wed, 18-Dec-85 13:26:58 EST
Article-I.D.: utzoo.6235
Posted: Wed Dec 18 13:26:58 1985
Date-Received: Wed, 18-Dec-85 13:26:58 EST
References: <848@rlgvax.UUCP>, <176@altos86.UUCP>
Organization: U of Toronto Zoology
Lines: 17
Keywords: XON/XOFF protocol, deadlock, full duplex, tty driver, terminal

> Even this solution *may* not solve the problem.  Each machine has presumably
> XOFFed the other because it was not ready to recieve more data.  If one machine 
> is significantly faster than the other or one machine is in a state where it
> is not unblocking the input data stream it may actually lose the XON and stay
> deadlocked...

The solution to this is the "persistent" kind of xon/xoff that some devices,
notably the ones from HP, do.  If you sent an XOFF and the other end is still
sending data, send another XOFF after a little while.  (A reasonable strategy
is to send one when you're down to [say] 128 characters of buffer, another at
64, another at 32, etc.)  And if you sent an XON and the other end is silent,
send another XON after, say, 15 seconds.  And persist.  XON/XOFF is not a very
good protocol, but it's the best we have right now, and "persistent" versions
of it are much more robust than simplistic ones.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry