Newsgroups: comp.dcom.lans Path: utzoo!henry From: henry@utzoo.uucp (Henry Spencer) Subject: Re: CISCO terminal server users, please help Message-ID: <1989Jun6.163942.15568@utzoo.uucp> Organization: U of Toronto Zoology References: <5137@charon.unm.edu> <5187@b11.ingr.com> Date: Tue, 6 Jun 89 16:39:42 GMT In article <5187@b11.ingr.com> goodloe@b11.ingr.com (Tony Goodloe) writes: >This is not what I would expect. The way RS-232 (and all the other specs >I've read) work is that the DTE raises RTS and if the DCE is able to >accect data, it raises CTS in response. When the DCE can't accept more >data, it drops CTS. That sounds like RTS/CTS flow control to me... What most people mean by "RTS/CTS" flow control is using one line for flow control in one direction and the other for the other direction. At least that's my impression. This is, of course, nonstandard. So is the description above, though: CTS is not supposed to drop as long as RTS stays up. RTS is not "I have data for you", it is "start transmitter", and CTS correspondingly is "transmitter operating, send at will". The signals are meant for coordinating with half-duplex modems, which must be told when to transmit and when to listen. As far as I know, it is not kosher for the modem to unilaterally decide to stop transmitting; that is the host's decision. (Many modern half-duplex modems present a full-duplex interface to the host, with direction-switching handled between the two modems without host intervention, but that's a different story.) Unless things have changed since I learned this, RTS and CTS thus are not flow-control signals at all. Note that this is theory, as opposed to the facts of how they are actually used by many devices... -- You *can* understand sendmail, | Henry Spencer at U of Toronto Zoology but it's not worth it. -Collyer| uunet!attcan!utzoo!henry henry@zoo.toronto.edu