How does modem TO modem flow control work?
Maynard J. Handley
handshaking gives flow control from my mac to the modem. Thus my mac will
ship out data at 57600 bps say, and the modem will assert that it can't
cope with what's being sent by asserting or de-asserting the CTS line.
But now suppose I am calling computer remoteC. RemoteC's modem, which we
will call remoteM, picks up the data off the phone line and ships it up to
remoteC. Now suppose remoteM is not at that time ready to deal with this
flood of data---it's swapping to disk say. In an ideal world, my guess is
it would de-assert DTR to say it's not ready for data, this would be
conveyed in some out of band fashion to my modem and up onto my mac. Then
everything would stop until remoteC said it was ready for data. Is this in
fact how things happen?
Or suppose remoteC is ready, in the sense that it can field the interrupt
from the serial port, but the app that's supposed to eat the incoming data
is in background or such and not calling WaitNextEvent() because the
foreground app is decoding a massive JPEG. Again does the serial driver (or
whetevr is responsible) throttle the flow or are character just dropped?
If you don't have hardware handhsing cables, then how do XON/XOFF fit into
this picture? Are they sent computer to modem, modem to modem, or computer
to computer, passed through the modem without intrepretion?
Thanks for any info on how this all works together,
Maynard Handley
Dave Newman
In article <1993Feb17.2...@msc.cornell.edu> (comp.sys.mac.comm), may...@leah.msc.cornell.edu (Maynard J. Handley) writes:
| People, I'm pondering flow control. As I understand it, hardware
| handshaking gives flow control from my mac to the modem. Thus my mac will
| ship out data at 57600 bps say, and the modem will assert that it can't
| cope with what's being sent by asserting or de-asserting the CTS line.
|
| But now suppose I am calling computer remoteC. RemoteC's modem, which we
| will call remoteM, picks up the data off the phone line and ships it up to
| remoteC. Now suppose remoteM is not at that time ready to deal with this
| flood of data---it's swapping to disk say. In an ideal world, my guess is
| it would de-assert DTR to say it's not ready for data, this would be
| conveyed in some out of band fashion to my modem and up onto my mac. Then
| everything would stop until remoteC said it was ready for data. Is this in
| fact how things happen?
Yes, the modem will communicate the "halt of data" to your modem. How it
is done (in-band or out-of-band) is part of the modem specs that we hear
about all the time. Usually you don't need to worry about the specifics
of how the modems communicate this info back and forth.
| Or suppose remoteC is ready, in the sense that it can field the interrupt
| from the serial port, but the app that's supposed to eat the incoming data
| is in background or such and not calling WaitNextEvent() because the
| foreground app is decoding a massive JPEG. Again does the serial driver (or
| whetevr is responsible) throttle the flow or are character just dropped?
Yes, normally the serial driver is responsible for communicating to the modem
that no more data can be handled. This happens because the serial driver's
own internal buffer to place incoming characters is not being emptied by
the comm application and is becoming dangerously full.
| If you don't have hardware handhsing cables, then how do XON/XOFF fit into
| this picture? Are they sent computer to modem, modem to modem, or computer
| to computer, passed through the modem without intrepretion?
Xon/Xoff can get tricky. Usually you want to configure the modems to be
transparent when Xon/Xoff flow control is used. Transparent behavior means
that the Xon/Xoff characters pass right through the modems without the modems
ever reacting to the Xon/Xoff characters. In this case the Xon/Xoff flow
control exists only between the two computers and the modems to not participate.
Now the fun stuff... Many modems have options to allow them to participate
in Xon/Xoff flow control, and in two distinct ways.
The first option is for
the modem to "swallow" the Xon/Xoff characters and react to them. Essentially,
an Xoff from your computer to the modem will cause the modem to stop sending
data to your computer, and the modem does not send the Xoff to the remote
modem - the "swallowing" part. Xon will start the follow of data again,
and it too is swallowed.
The other option is for the modem to react to the Xon/Xoff characters _but_
also allow them to be passed through to the remote modem. The modem reacts
in the same way as above, but when it passes the Xon/Xoff characters through,
the receiving modem seeing these coming in from the phone line does not
react to them, but merely passes them on to the computer on the remote side.
Personally, I use modems either in the hardware handshake mode discussed
above, or I use modems in the Xon/Xoff transparent mode. I've not had too
much success with either of the Xon/Xoff options turned on.
--Dave
------------------------------------------------------------
Dave Newman | AOL: AFC Tinman
Artillery Spotter | ALink: TINMAN
Notable Technologies, Inc. | CIS: 70743,3323
Voice: 510.208.4449 | internet: da...@notable.com
FAX: 510.444.4493 | AT&TMail: DaveNewman
------------------------------------------------------------