Path: utzoo!mnetor!uunet!pcrat!rick
From: rick@pcrat.UUCP (Rick Richardson)
Newsgroups: comp.dcom.modems
Subject: Re:  EIA Flow Control
Message-ID: <474@pcrat.UUCP>
Date: 23 Feb 88 14:35:42 GMT
References: <8802222331.AA03700@ucbvax.Berkeley.EDU>
Reply-To: rick@pcrat.UUCP (Rick Richardson)
Organization: PC Research, Inc., Tinton Falls, NJ
Lines: 58

In article <8802222331.AA03700@ucbvax.Berkeley.EDU> RAF@NIHCU.BITNET ("Roger Fajman") writes:
>> As has been pointed out, there are many, many ways to make a null modem.
>> The cross of 4 and 5 is 'best' when you have devices which implement
>> the so called "EIA Flow Control" (aka hardware flow control).  Here,
>> CTS controls the flow from DTE to DCE, RTS controls the flow from
>> DCE to DTE.  In this scheme, there is no longer any correlation between
>> the assertion of RTS and the reply with CTS.
>
>Interesting.  What are some examples of devices that work that way?
>I haven't run across any, while I have seen a lot that use DTR.
>
>Does the RS-232C standard really cover this use of Request To Send?
>I haven't read it lately, but judging from the name of the pin, I
>suspect not.  If that is true, then it is something of a misnomer to
>call it "EIA flow control."  The normal use of RTS/CTS that the DTE
>brings up RTS when it wants to transmit and receives CTS from the
>DCE when it is ok to do so.  It's important with half duplex modems.

I don't believe this usage is in any standard.  And I agree that
the name is poor.  However, as half-duplex modems are disappearing,
and there's a clear need for full duplex out-of-band flow control,
this scheme has become popular.  I've heard this called
"hardware flow control", "EIA flow control", and "RTS/CTS full
duplex flow control".

Several DCEs, including the 'Blazer implement this.  AT&T's
ISDN data modules implement this.  I'm told NCR, Pyramid, and Gould
have it available on some DTE products.  I think that the Procomm Plus
terminal emulator for the IBM PC implements it (though I'm not
at all convinced it can be done reliably with an 8250 and software).
There's probably more.

Even though the DTR drop was a pre-existing method of faking
out-of-band flow control from the DTE back to the DCE, it
fails miserably in the following (common) configuration:

You've got a DCE that moves data via packets.  This could be
a packetizing modem, or an ISDN data module that can accept
X.25 data calls on either the 16K or the 64K channel.  The
interface speed might be locked at 9.6K or 19.2K, or could
vary depending upon the whims of an incoming caller.  Your
DTE computer will need flow control both directions since
the caller/network/DCE could instanteously and/or on
average be running either faster OR slower than your DTE
computer is.  You can't use DTR to signal the DCE to slow
down, since, presumably, you'd want the DCE to answer calls
ONLY if there is a live DTE (maybe a "getty") attached.  You
also want the DCE to drop the call (and maybe reset parameters)
if the DTE drops DTR.

If I were buying a computer today, and looking toward the future
of data communications, I'd bug the vendor about their support
and or plans for support of (fill in favorite name) flow control.
-- 
		Rick Richardson, President, PC Research, Inc.

(201) 542-3734 (voice, nights)   OR     (201) 834-1378 (voice, days)
uunet!pcrat!rick (UUCP)			rick%pcrat.uucp@uunet.uu.net (INTERNET)