Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!sun-barr!olivea!spool.mu.edu!mips!zaphod.mps.ohio-state.edu!usc!ucsd!nosc!crash!simpact!cmkrnl!jeh
From: jeh@cmkrnl.uucp
Newsgroups: comp.dcom.modems
Subject: Re: Hardware Flow Control
Message-ID: <1991Jun22.154139.118@cmkrnl.uucp>
Date: 22 Jun 91 22:41:39 GMT
References: <42910619180524.0004025717NB2EM@mcimail.com>
Organization: Kernel Mode Consulting, San Diego CA
Lines: 101

In article <42910619180524.
0004025717NB2EM@mcimail.com>, 
HAL/MISSLINKS/MikeB%Traveling_Software;_Inc.@MCIMAIL.COM (MikeB) writes:

> I'm curious how exactly the RTS/CTS handshaking flow control works between a 
> PC and a modem. From what I've seen the following is true:
> 
> o The CTS is asserted when the modem buffer is full 

um, depends on what you mean by "asserted".  To many people "asserted" means
"actively driven to one state or the other, as opposed to simply floating 
free", without specifying *which* state it's driven to.  Lets use the terms
"drives the signal true" or "drives the signal false", or just "raises" and
"drops", instead of "asserts". 

Anyway, when the modem wants datam, it drives the CTS signal true, and when its
outgoing buffer is full, it drives the CTS signal false.  The PC is expected
to send and not send data, respectively.  

> (256 bytes?).

the size of the buffer is dependent upon the modem.  

> o If a PC asserts RTS, it causes the *remote* modem to stop sending data 
> although a few bytes still get through.

no.  RTS controls the *local* modem.  When the local modem sees RTS go false,
it stops sending data to the PC; when RTS is true, the local modem sends data
to the PC. The PC drives RTS true or false when it wants, or does not want,
data, respectively. 

> o There is no way to signal the local modem to stop sending data.

No.  Just the opposite; there is no (direct) way to signal the *remote* modem
to stop sending data.  There is no provision for passing modem-control signals
"through the link" to the remote modem.  Modem-control signals, by definition,
control the local modem.  

However, on an error-corrected link such as V.42 or PEP, and assuming that both
ends' modems and hosts are using full-duplex RTS/CTS flow control, what will 
happen is:

	1.  The local system's buffer fills up and it sets RTS false.
	2.  The local modem stops sending data to the local system.  
	3.  The modem's received-data buffer fills up, since it has no
	place to dump the data, so the modem stops sending ACKs to the 
	remote (sending) modem, or it stops sending send credits, or it
	sends a "send no more data" signal, or 	whatever is appropriate for 
	the protocol in use.  
	4.  In response to the lack of ACKs, or whatever, the remote modem
	stops sending data to the local modem. 
	5.  The remote system keeps sending, but the remote modem doesn't,
	so the remote modem's send-data buffer fills up, and...
	6.  ...the remote modem sets CTS false, causing the remote system
	to stop sending data to the remote modem.  

At this point all traffic has stopped, but there is a bunch of data in both
modems' buffers, data that was sent sometime later than the time that the 
local system dropped RTS.  

As soon as the local system raises RTS, the local modem starts sending data to
the local system again.  Soon the local modem's buffer is less full and its
flow control mechanism tells the remote modem to resume sending.  Soon the
remote modem's buffer is less full, and the remote modem raises CTS to tell the
remote system to resume sending. 

But the local system's RTS signal is *not* passed directly to the remote
modem.  If there is no flow control protocol in effect between the two 
modems, the local system's RTS signal will not even have a delayed effect
on the remote modem or the remote system.  

(Implication:  If you're not using a protocol such as V.42 that does flow
control between the modems, two statements can be made about RTS/CTS :

	1.  RTS flow control will not help you avoid losing data.  It may 
	help you avoid buffer overruns in your local host but data can still
	be lost elsewhere.  

	2.  CTS flow control can still be used for those cases where your 
	link speed is slower than the host-to-modem speed and you want to 
	avoid overrunning the local modem's buffer, but that is the only 
	thing it will do for you; it will not tell you whether you're 
	overrunning either the remote modem's receive buffer or the remote
	host's buffer.
)


Clear now???

I will also note in passing that the signal on pin 4, when used as part of
"RTS/CTS flow control", is properly called "Ready To Receive (RTR)" rather than
Request To Send.  When the DCE (modem) uses pin 4 for RTR, it assumes that RTS
is always  true. This is according to the latest version of EIA-232, EIA-232-E.

(Thanks to Toby Nixon of Hayes Communications for this info, and for his work
on the relevant standards committee!) 

	--- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA
Chair, VMS Internals Working Group, U.S. DECUS VAX Systems SIG 
Internet:  jeh@dcs.simpact.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com
Uucp:  ...{crash,scubed,decwrl}!simpact!cmkrnl!jeh