Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!ucsd!nosc!crash!simpact!jeh From: jeh@simpact.com Newsgroups: comp.dcom.modems Subject: Re: Modem control lines Message-ID: <698.253b4e13@simpact.com> Date: 17 Oct 89 23:06:42 GMT References: <1180@srhqla.SR.COM> <2532@cs.yale.edu> Distribution: usa Organization: Simpact Associates, San Diego CA Lines: 112 In article <2532@cs.yale.edu>, Owens-Christopher@cs.yale.edu (Christopher Owens) writes: > There is something about RTS/CTS and modem links that I have never > fully understood. My understanding of flow control is as follows. > I'm sorry if I am mixing up RTS and CTS -- I don't have the reference > handy. By RTS I mean the line from the DTE to the modem telling the > modem that the DTE is ready to accept data. By CTS I mean the line > from the modem to the DTE telling the DTE that the modem is ready to > accept data. This is correct insofar as popular (nonstandard) usage is concerned, and we'll assume this for sake of argument. (According to RS232, RTS is indeed sourced by the DTE and read by the modem, but it means "modem, I want to send", not "modem, I can receive". A DTE using this protocol raises RTS when it wants to send data (ie when a write is queued to the modem port) and then waits for CTS from the modem before proceeding. CTS from the modem shouldn't be present in the absence of RTS from the DTE. (This was used primarily on old-style half-duplex modems (eg Bell 201) which had to do line turnarounds.... not unlike modern high-speed mostly-half-duplex modems. The difference is that the modern modems initiate a turnaround automatically upon receipt of data from the "wrong" DTE, rather than relying on RTS signalling.) > Let's say I am connected and configured at both ends to use RTS/CTS. > Now if I am at the receiving end of a data transfer, and I find my > input buffer filling, I will drop RTS, which tells my modem to stop > sending characters to me. Now, presumably, the modem's internal > buffer is going to fill up pretty fast, at which point it is going to > want to send some kind of signal to the other modem to tell it to stop > sending data down the communications line. Either that or it just stops sending acknowledgements to the other modem. > The exact nature of this > signal would depend upon the modem protocol, of course. If the other > modem obeys this signal, then pretty soon its buffer is going to fill > up, at which point it wants to signal the computer at its end to stop > sending characters to it, presumably by dropping CTS. By this time I > have emptied my input buffer, so I re-assert RTS, which tells my modem > to start sending characters to me again. When my modem's buffer > begins to empty, it sends a signal to the other modem to tell it to > start sending data to it again Or, more likely, it just starts sending ACKs again. > at which point its buffer begins to empty, > and it turns on the flow at the far end by re-asserting CTS. > > So, according to my understanding, RTS and CTS are in some indirect > sense passed through the telecommunications link in that, if the DTE > at one end shuts off the flow from the modem, the modem at the other > end will eventually shut off the flow from the DTE to which it is > connected. Yes, between similar modems which use this type of signalling. > Now what I don't understand is, what do the modems use for this > mystery signal to communicate with each other? I can't speak in the general case, but at least some modems in my experience encapsulate the user data into packets (with framing characters, CRC checksums, etc.). A "packet type" field in the packet header can be used to say "this packet contains no user data, rather it's a modem-to-modem supervisory message", and in that case other fields in the packet header tell what sort of message it is (ack, nak, whatever). It is also possible to use "alternate channel" techniques. The Trailblazers, when operating in PEP mode, divide the bandwidth into a number of subcarriers. One or more of these could be used for supervisory data. I don't know for certain if they actually work this way or not (it's really impossible to tell from the outside0. > How sophisticated a > protocol does one need to be using before this happens? The sophistication level must be at least 42. Seriously, I don't know how to answer this. I believe that MNP 5 and up will do it, but I'm not certain. Trailblazers in PEP mode do it. > Does a plain > analog modem (e.g.: Bell 212) do anything of this kind? If not, what > happens when one drops RTS at one end of the connection? No, they don't. A Bell 212 obeys the standard meaning of RTS (ie it means that the DTE wants to send). But being a true full-duplex modem there is no notion of line turnaround. Thus if you raise RTS, the modem will immediately raise CTS, and if you drop RTS, the modem will drop CTS. (But, being a full-duplex modem, I doubt that it will stop accepting data.) > To throw in > an additional monkey wrench, what if one modem is configured to use > rts/cts flow control, and the other is configured to use XON/XOFF. > Assuming a modem protocol like, for example, MNP5, is everything > sorted out correctly such that de-asserting RTS at one end will result > in an XOFF being sent at the other end? If everything is configured correctly, yes, this works. Of course, "interesting" situations develop if the DTE that's using rts/cts tries to send a data byte that just happens to look like either an xon or an xoff. I don't know whether the other DTE's modem, being configured for xon/xoff flow control, will refuse to pass this "inband data" to the DTE or not. If the byte does get to the DTE it will have no way of distinguishing this from an xon or xoff sent by the local modem for flow control purposes. --- Jamie Hanrahan, Simpact Associates, San Diego CA Chair, VMSnet [DECUS uucp] and Internals Working Groups, DECUS VAX Systems SIG Internet: jeh@simpact.com, or if that fails, jeh@crash.cts.com Uucp: ...{crash,scubed,decwrl}!simpact!jeh