chris@umcp-cs.UUCP (Chris Torek) (11/27/84)
I think everyone realizes that if you are going to preempt characters
for flow control, they aren't going to be available for data. You
*can* have an 8 bit data path in *both* directions *and* have flow
control; you just have to give up at least one character (it can still
be sent by using some kind of protocol, of course).
However, the Berkeley tty drivers just don't allow it. Here's what
goes wrong, at least, what I can think of easily (I haven't tried to
implement 8 bits myself): (1) delays can't be done by meta characters
[this is a problem with LITOUT mode too!]; (2) what if you want the
input character '\377' as a special character?; (3) how do you tell how
many bits should be used to check for special characters; i.e., is
meta-^S a stop character or not?; (4) You have to change every single
da[rm]ned device driver to do things differently because of (1-3).
Speaking of flow control, has anyone ever thought about how much
problems using in-band data for this has caused? If terminals had
hardware flow control, we might not have kludges like the pty driver
sending special packets whenever t_startc and t_stopc change from/to
^Q/^S, and rlogind flushing perfectly good data just to get that OOB
data, and . . . [froth froth]. Have you ever noticed that the pty
driver *doesn't* send any messages about any other state changes (like
raw mode?) [rant rant]. You'd think that if Berkeley saw fit to
provide info about changes in local flow control on a network port to
the program doing the connecting, they'd also see fit to provide nice
ways to get the entire state across, not just one tiny bit [rave
rave]. I'd better stop, I'm getting out of hand here. Maybe I should
add net.flame.... :-)
--
(This line accidently left nonblank.)
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (301) 454-7690
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@marylandhenry@utzoo.UUCP (Henry Spencer) (11/30/84)
> Speaking of flow control, has anyone ever thought about how much > problems using in-band data for this has caused? If terminals had > hardware flow control, we might not have kludges like ... It's hard to make hardware flow control work over phone modems that only support in-band data. Or over any long-propagation-delay network, unless you use positive control ("ok, send me N more bytes") rather than negative control ("stop! my buffers are full!"). Note that many of the ASCII control characters, including DC1 and DC3 (XON and XOFF), are explicitly reserved for this sort of control function. That is, they technically are *not* "in-band data", and people who use them as such do so at their own risk. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry