Path: utzoo!mnetor!uunet!nbires!hao!ames!oliveb!jerry
From: jerry@oliveb.olivetti.com (Jerry Aguirre)
Newsgroups: comp.dcom.modems
Subject: Re:  EIA Flow Control
Message-ID: <16056@oliveb.olivetti.com>
Date: 25 Feb 88 20:06:03 GMT
References: <8802222331.AA03700@ucbvax.Berkeley.EDU> <825@vixie.UUCP> <3158@phri.UUCP>
Reply-To: jerry@oliveb.UUCP (Jerry Aguirre)
Organization: Olivetti ATC; Cupertino, Ca
Lines: 58

In article <3158@phri.UUCP> roy@phri.UUCP (Roy Smith) writes:
>In article <825@vixie.UUCP> paul@vixie.UUCP (Paul Vixie Esq) writes:
>[regarding using RTS/CTS as flow control, contrary to what RS-232 says]
>> It very desperately needs to become an official standard, since it is in
>> very wide use as an unofficial one. [...]  In short, Everybody Does It
>> This Way, so could somebody please document it in an IEEE or ANSI spec
>> somewhere?
>
>	Clearly, there needs to be some official written standard which
>includes hardware flow control for RS-232ish circuits.  Unofficial RTS/CTS
>flow control sucks.  Unofficial DTR flow control sucks.  XON/XOFF flow
>control sucks.

I agree that flow control should be standardized.  Having to make
special cables so that CTS can be coupled to DTR is a pain.  (And then
there is Data General where CTS stops output on the next bit instead of
on a character boundry.) But it is important to remember that whatever
gets specified is only going to be an option for devices that are able
to do flow control.

With so may of our connections being buffered intelegent boxes today is
is easy to think that everything should be able to do flow control.
While a packetized modem like the TrailBlazer, with more power than some
computers, can easily do it many modems and other devices just can not.

The best an unbuffered device such as a modem or data switch will be
able to do is to pass the flow control information to the device on the
other end.  This requires that it have a channel available to carry the
flow control signals to the other end.  With packetized channels such as
the Blazer and terminal servers it is easy to piggyback the flow control
in with the data.

But many communications devices have just the single channel.  Adding a
reverse channel means either creating another carrier frequency or
multiplexing it in with the data.  Either solution means added expense.

Some of the older modems used to have a seperate channel.  If you check
the rs232 spec. you will find that it has a "secondary channel" that
even has its own modem control signals.  I remember reading the manual
for a modem that supported this.  The secondary channel was good for 5
bits per second, just right for flow control.  Using the secondary
transmit and secondary receive for flow control makes more sense, within
the rs232 spec., than using RTS and CTS.  However few modems seem to
support the secondary channel.

In practice manufacturers usually add flow control after the product has
already been designed.  It is then that they find that users are
unwilling to have their million dollar computer busy-wait on a slow
peripheral.  They then look at their interface and notice that some of
the modem control signals, originally added out of superstition, arn't
really being used and can be subverted for flow control.  Using any
other pins would mean changing the hardware and would cost too much.

Even with a buffered device, like the TrailBlazer, flow control should
really be end to end.  If the final consumer of the data can't signal
all the way back to what is generating the data then data can be lost.
If even one part of the path can't support flow control then it won't be
end to end.  The future doesn't look good.