Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.6.2.17 $; site uiucuxc.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!inuxc!pur-ee!uiucdcs!uiucuxc!hamilton
From: hamilton@uiucuxc.UUCP
Newsgroups: net.unix-wizards
Subject: Re: uucp through flow-controlled (XON/XO
Message-ID: <31700008@uiucuxc.UUCP>
Date: Thu, 22-Nov-84 01:59:00 EST
Article-I.D.: uiucuxc.31700008
Posted: Thu Nov 22 01:59:00 1984
Date-Received: Sun, 25-Nov-84 03:39:06 EST
References: <5805@brl-tgr.UUCP>
Lines: 19
Nf-ID: #R:brl-tgr:-580500:uiucuxc:31700008:000:979
Nf-From: uiucuxc!hamilton    Nov 22 00:59:00 1984


> Question: Should uucp be able to function over a flow-controlled
> 	network that uses XON/XOFF as flow control.

>>One simple fix (well, kludge) is to add a simple byte-stuffing layer
>>underneath the packet driver, which takes any XONs, XOFFs, and other
>>objectionable characters (some I/O packages won't transmit NUL, for
>>example) and encode them as a unique sequence of two characters
>>before transmission, performing the reverse transformation at the other
>>end.  This allows the use of flow control, and slows things down only a
>>little since only a few bytes get expanded.  More CPU overhead, though.

i have a similar problem with multiplexors.  even worse, mine eat the
parity bit, so i only get a 7-bit channel.  i have implemented the
byte-stuffing kludge for my machines (turns out to be almost trivial).
if you're interested, send me mail.  if i get enough requests, i'll
just post it to net.sources.
	wayne ({decvax,ucbvax}!pur-ee!uiucdcs!uiucuxc!)hamilton