brian@sdcsvax.UUCP (Brian Kantor) (05/19/85)
Phil Ngai suggests that hardware flow control is gross, and that XON/XOFF is the proper way to go. As this attitude is widespread among those who don't really understand why hardware flow control exists: XON/XOFF could be considered an example of what is called ``inband signalling'', where a communications channel carries both data and control signals in the data stream. When such a scheme is used, there has to be some way to separate the control signals from the data. There can be some special sequence of characters, or reserved characters, or timing, or a combination of these. There are a lot of disadvantages to this. Hayes modems, for example, use timing and a sequence of characters. To disconnect an open data connection, you stop all outgoing data for 3 seconds, send +++, and pause for another 3 seconds. If you are already connected and discover that you have to send exactly that pattern for some reason, you are out of luck - the modem is going to disconnect and you can't do anything about it (oh, you could have changed the control characters BEFORE you connected, but once you have connected, too bad. You could also have disabled the feature, but then you have to have some other method of disconnecting the modem). XON-XOFF (aka DC1/DC3) are examples of reserved characters. When they occur in the data stream, they are interpreted. If its desired that they be treated as data (for example, as a command key for EMACS, or as binary data), it is necessary to ``escape'' them - to send another reserved character that signifies that the character following it is NOT to be interpreted. So its then necessary to have software watching the data stream and handling the escape character too. (To send the escape character itself as data, you would then send it twice.) Hardware flow control has none of these complications. It is ``out-of-band'' signalling, i.e., it performs its control functions without giving any special significance to or altering the data stream in any way. This means that you can transmit anything over the data stream without worrying about what funny noises it might generate along the way. But, I hear you saying, ``This is normal typing at a terminal. We're not going to send funny characters!''. Well, maybe YOU aren't, but the equipment you're using might. The original question was regarding terminals and such connected through a Local Area Network (LAN). Because a LAN typically has contention for its bandwidth, it is sometimes necessary to stop the data flow into the network for a brief period of time until congestion is alleviated. With the XON/XOFF protocol, that means that the Network Attachment Device (NAD) (sort of like a modem) has to send an XOFF to the terminal or computer until its buffers empty out a bit, and then send XON to resume data flow. Consider the following scenario: You are reading the USENET news, and you decide to pause the screen for a moment. You type a control-S (XOFF) and the NAD stops sending you data. But the computer is still sending, and does so until the other NAD (at the computer end) fills up, and sends an XOFF to the computer. You begin reading again (send an XON to restart output), and not until the computer NAD empties out again do things start to flow out of the computer (the computer NAD sends XON to restart output there). This all works well, and is reasonably invisible to the user. (The NAD also has to know when to throw away buffered data, like when you kill a process or something, or else you get a couple of screens of unwanted characters after you thought you'd killed the job). Of course, you can't change your flow control characters or method, as that would require reprogramming the NADs at both ends. But consider. Now you have two Un*x systems talking to each other with UUCP, and the network gets congested. UUCP needs an eight-bit transparent path, so it doesn't really handle XON-XOFF. How is the network to tell the sending computer that it should stop? Perhaps you could reserve special high-priority network connections for uucp, but that doesn't solve the problem of a user who is perhaps doing file transfers to his microcomputer from a normal terminal line, or something similar. And how about a Diablo terminal, that wants ETX/ACK instead of XON/XOFF? And consider a network that is carrying encrypted data. Is the NAD supposed to be smart enough to encrypt/decrypt the XON/XOFF? Point is, hardware flow control is a good answer when transparency is required in the data stream, as it frequently is. XON/XOFF worked ok when its only function was to turn on and off the paper tape reader in a teletype machine, but the world has moved past that era. There are simply too many applications where you don't want to tamper with the data stream to do flow control. Brian Kantor UC San Diego decvax\ brian@ucsd.arpa akgua >--- sdcsvax --- brian ucbvax/ Kantor@Nosc
chris@umcp-cs.UUCP (Chris Torek) (05/21/85)
Actually, there's nothing wrong with software flow control, just so long as it's *completely invisible* above the level where flow control is required. TCP/IP and XNS both handle flow control in software, without preempting any bytes. (Of course there is more transmission overhead....tanstaffl.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland
phil@amdcad.UUCP (Phil Ngai) (05/23/85)
In article <879@sdcsvax.UUCP> brian@sdcsvax.UUCP (Brian Kantor) writes: >Phil Ngai suggests that hardware flow control is gross, and that >XON/XOFF is the proper way to go. As this attitude is widespread among >those who don't really understand why hardware flow control exists: No, I don't think hardware flow control is gross, what's gross is implementing bi-directional hardware flow control on a 25 pin connector and calling it RS-232. It's not RS-232 after you have done that and you shouldn't call it RS-232. If you want to use RS-232 then use in-band flow control (XOFF/XON). But those signals called DTR and CTS, etc, have defined meanings and if you change their behavior they aren't the same signals anymore. On a more global sense, you're really out to change the world if you want to use bi-directional hardware flow control with the most of the equipment that you will find out there. I work with networks for a living and do understand why flow control exists. I also understand RS-232 better than most people. And do you know which vendor seems to do RS-232 best? Believe it or not, IBM. Their 7171 product follows the spec in all the little details that other vendors seem to ignore. And I bet you didn't know IBM did ASCII or RS-232. Well, they made some mistakes when they first started. Their 3101 terminal has a female 25 pin connector, which is wrong. But they learn from their mistakes and listen to their customers. The IBM-PC and the 7171 are both DTE and have male connectors, just like they're supposed to. The 7171 understands the Ring signal, Data Terminal Ready, Clear To Send, Data Set Ready, Data Carrier Detect, and Request To Send. How many pieces of equipment do you know that look at or do anything meaningful with DSR? Argh. I cring at the idea of using DTR for flow control. I am sure people will say, printers do it all the time, or "it works for me". I still cring. I'd like you to try doing it through a 212 modem some time. -- What do you do the day after a peak experience? Phil Ngai (408) 749-5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.ARPA
phil@amdcad.UUCP (Phil Ngai) (05/23/85)
In article <879@sdcsvax.UUCP> brian@sdcsvax.UUCP (Brian Kantor) writes: >XON-XOFF (aka DC1/DC3) are examples of reserved characters. When they >occur in the data stream, they are interpreted. If its desired that >they be treated as data (for example, as a command key for EMACS, or as You're not supposed to use XOFF/XON as data. Many people would claim that EMACS is broken for using XOFF for a search command. Some have remapped it. Certainly terminals like the VT100 and the VT220 like to use XOFF/XON for flow control. I have seen people send padding characters to avoid using XOFF/XON, since I seem to have overworked the word "gross" I won't give my opinion about such methods. >But consider. Now you have two Un*x systems talking to each other with >UUCP, and the network gets congested. UUCP needs an eight-bit >transparent path, so it doesn't really handle XON-XOFF. How is the >network to tell the sending computer that it should stop? If you want to complain about not having an eight-bit transparent path, try beating on the people who run X.25 networks. See how far you get. Our friends in Europe decided the right way to use uucp over X.25 networks was to invent a new "f" protocol (which is in the 4.3 BSD uucp) which restricts itself to 7 bit characters. Binary data can be sent, the protocol maps the byte into a valid character range and prefixes a special byte. I believe this is what kermit does to use 7 bit data paths also. >similar. And how about a Diablo terminal, that wants ETX/ACK instead of >XON/XOFF? I believe those are valid characters. By the way, if you are interested in funky character sets, you should look at the programmers manual for the VT220 to see how they handle the extra characters needed to function in a European market. I'll give you a hint: they don't use XOFF as data. One neat thing (which is sort of irrelevant) is the availability of software configurable character sets. You can actually down load the fonts. And you don't need an eight bit data path for that either. -- What do you do the day after a peak experience? Phil Ngai (408) 749-5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.ARPA
henry@utzoo.UUCP (Henry Spencer) (05/23/85)
The ultimate problem here is two slightly-different definitions of what
"data" is. Narrowly speaking, the ASCII control characters are just that --
*control* characters, not data -- and hence they *are* out-of-band as far
as transmission of ASCII text goes. The difficulties arise because of a
combination of (a) not enough keys on the keyboard for things like fancy
editors, and (b) the ability to send control characters from the keyboard.
Programs like uucp that want to send arbitrary bit patterns make it worse.
The result of this is predictable: there is now a strong preference for
classing *all* ASCII characters as "data", which implies that out-of-band
flow control has to use some other mechanism.
CTS/RTS is workable at short range, but since those wires were never meant
for flow control, much hardware (modems, local networks, dumb terminal
multiplexors) won't handle it. (What *were* CTS and RTS meant for, you
ask? For turning around half-duplex modems.)
In any case, neither XON/XOFF nor CTS/RTS is really ideal, because both
are negative ("stop, I can't take any more!") flow control methods. This
means that they fall down badly when propagation delays are long (e.g.
long-haul networks or satellite channels), because the other end doesn't
get the word quickly enough. What is really wanted is a standard method
of *positive* flow control ("I'm OK for another 347 characters now").
I don't see much hope for getting one established, though.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henryedward@ukma.UUCP (Edward C. Bennett) (05/24/85)
In article <879@sdcsvax.UUCP>, brian@sdcsvax.UUCP (Brian Kantor) writes: > Hayes modems, for example, use timing and a sequence of characters. To > disconnect an open data connection, you stop all outgoing data for 3 > seconds, send +++, and pause for another 3 seconds. If you are already > connected and discover that you have to send exactly that pattern for > some reason, you are out of luck - the modem is going to disconnect and > you can't do anything about it (oh, you could have changed the control > characters BEFORE you connected, but once you have connected, too bad. > You could also have disabled the feature, but then you have to have some > other method of disconnecting the modem). > > Brian Kantor UC San Diego > > decvax\ brian@ucsd.arpa > akgua >--- sdcsvax --- brian > ucbvax/ Kantor@Nosc Go read your manual!! Why do you think the 3 second time is required before and after the +++'s? Just don't let the time buildup. Enter data fast enough to prevent a 3 second interval. Even if you do drop into command mode, it's simple to reconnect. And while in command mode, you CAN change your escape character. Also the number of them and the length of the pause required. NOTE: The comments are based on ownership of a Prometheus ProModem 1200, which emulates a Hayes. -- edward {ucbvax,unmvax,boulder,research}!anlams! -| {mcvax!qtlon,vax135,mddc}!qusavx! -|--> ukma!edward | {decvax,ihnp4,mhuxt,seismo}! -+-> cbosgd! -| {clyde,osu-eddie,ulysses}! ---| "Well, what's on the television then?" "Looks like a penguin." () | |-- Support barrier free design /|--- | \ _ \___/ \=
cyrus@symplex.UUCP (cyrus) (05/25/85)
Now I like this discussion...it has some meat to it... > when they first started. Their 3101 terminal has a female 25 pin connector, > which is wrong. But they learn from their mistakes and listen to their > customers. The IBM-PC and the 7171 are both DTE and have male connectors, > just like they're supposed to. The 7171 understands the Ring signal, Why is a female connector on a DTE terminal port wrong??? As far as ASYNC-only devices go, a male DTE connector is quite rare. For multiplexers with SYNC composite channels, most are male in order to avoid customer confusion in differentiating the host connectors from the modem connector. In any case the vendor should supply a cable with the proper gender at each end to help the customer. > Data Terminal Ready, Clear To Send, Data Set Ready, Data Carrier Detect, > and Request To Send. How many pieces of equipment do you know that look > at or do anything meaningful with DSR? Most SYNC devices will refuse to communicate without DSR asserted. > Argh. I cring at the idea of using DTR for flow control. I am sure people > will say, printers do it all the time, or "it works for me". I still cring. > I'd like you to try doing it through a 212 modem some time. Personally, I cringe at the thought of using half-dux transmission (RTS, CTS, and DCD all toggling at just the right moments) over a full-dux line...All that wasted bandwidth!!! > What do you do the day after a peak experience? Take a shower...:-). -Cyrus Azar (313) 995-1555 || ihnp4!umich!symplex!cyrus Symplex Communications 5 Research Drive Ann Arbor, MI 48103 "The opinions expressed here are nothing more than the random effects of a slew-rate limited 1488 being fed by a rather noisy switching power supply"
minow@decvax.UUCP (Martin Minow) (05/25/85)
... "What is really wanted is a standard method of *positive* flow control. I.e., 'I'm ready for another 347 bytes now'." The "negative" flow-control methods work (XOFF/XON) work satisfactorily if sufficient space is allocated for overrun. For example, (assuming 9600 Baud transmission) the receiver can allocate a 400 byte buffer, sending XOFF when there are 100 bytes unprocessed bytes in the terminal input buffer. This gives the host about 600 msec. to stop output. The terminal might send XON when, say, only 50 bytes are in the input buffer. (Actual numbers are made up and shouldn't be taken as a recommendation -- a university-level course on simulation might give you tools for selecting real values.) As has been already noted, it is important to implement flow-control algorithms at a low-level in the operating system, preferably within the terminal device interrupt-service routine. Martin Minow decvax!minow
robert@gitpyr.UUCP (Robert Viduya) (05/26/85)
> The ultimate problem here is two slightly-different definitions of what > "data" is. Narrowly speaking, the ASCII control characters are just that -- > *control* characters, not data -- and hence they *are* out-of-band as far > as transmission of ASCII text goes. And what if I want to send a program binary? Doesn't that, from this point of view, qualify as 'data'? > > CTS/RTS is workable at short range, but since those wires were never meant > for flow control, much hardware (modems, local networks, dumb terminal > multiplexors) won't handle it. (What *were* CTS and RTS meant for, you > ask? For turning around half-duplex modems.) > Halfway correct. CTS/RTS has slightly different meanings when operating either under half-duplex or full-duplex mode. To quote from the EIA RS-232-C standard - Aug, 1969 (editted appropriately): "Request To Send (to DCE (data communication equipment)): This circuit is used to condition the local DCE for data transmission and, on a half duplex channel, to control the direction of data transmission of the local DCE. On one way only channels or duplex channels, the ON condition maintains the DCE in the transmit mode. The OFF condition maintains the DCE in non-transmit mode. On a half duplex channel, the ON condition maintains the DCE in transmit mode and inhibits the receive mode. The OFF condition maintains the DCE equipment in receive mode. Clear To send (from DCE): Signals on this circuit are generated by the DCE to indicate whether or not the data set is ready to transmit data. The ON condition together with the ON condition on interchange circuits RTS, DSR and, where implemented, DTR, is an indication to the DTE (data terminal equipment) that signals presented on circuit TD (transmit data) will be transmitted to the communication channel. The OFF condition is an indication to the DTE that it should not transfer data across the interface on circuit TD." That last paragraph has the phrase 'flow-control' written all over it. Unfortunately, the EIA standard only allows the DCE (modem, network box, etc) to flow control the DTE (terminal, computer). It gives no provisions for allowing the DTE to flow-control the DCE. The Ungermann/Bass (sp?) boxes, when set up for RTS/CTS flow control stayed as close to the standard as they could and still allowed for bi-direction flow-control. I'll spare you the details, but I believe they will work properly when connected to a DTE the strictly adheres to the standard. robert -- Robert Viduya Georgia Institute of Technology ...!{akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!robert ...!{rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!robert
chris@umcp-cs.UUCP (Chris Torek) (05/26/85)
> The "negative" flow-control methods work (XOFF/XON) work satisfactorily > if sufficient space is allocated for overrun. True, but unfortunately, the amount of space that is sufficient has recently gone way up... > For example, (assuming 9600 Baud transmission) And no end-to-end network delays! > the receiver can allocate a 400 byte buffer, sending XOFF when there > are 100 bytes unprocessed bytes in the terminal input buffer. This > gives the host about 600 msec. to stop output. That's assuming the XOFF makes it from the stopper to the stoppee without delay; untrue in general, now. (If you gave yourself sufficient buffering to handle up to 30 seconds of delay, I suppose I'd call that sufficient: no one would want to wait longer for echo . . . .) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland
henry@utzoo.UUCP (Henry Spencer) (05/27/85)
> > when they first started. Their 3101 terminal has a female 25 pin connector, > > which is wrong. ... > > Why is a female connector on a DTE terminal port wrong??? > As far as ASYNC-only devices go, a male DTE connector is quite rare. The original rule, I believe, was that DCEs were female, and a DTE was supposed to *come with a cable* with a male end to plug into the DCE. This obviously made the sex of the connector on the DTE itself irrelevant. So much for the old days... My observations around our shop suggest that the current de-facto standard is that computers (i.e. the connector panels on their terminal muxes) are male and everything else is female. (Make of this what you will...) -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
henry@utzoo.UUCP (Henry Spencer) (05/27/85)
> > ... (What *were* CTS and RTS meant for, you > > ask? For turning around half-duplex modems.) > > Halfway correct. CTS/RTS has slightly different meanings when operating either > under half-duplex or full-duplex mode. To quote from the EIA RS-232-C > standard... > > ... > The ON condition together with the ON condition on > interchange circuits RTS, DSR and, where implemented, > DTR, is an indication to the DTE (data terminal equipment) > that signals presented on circuit TD (transmit data) > will be transmitted to the communication channel. > > The OFF condition is an indication to the DTE that > it should not transfer data across the interface > on circuit TD." > > That last paragraph has the phrase 'flow-control' written all over > it... Unfortunately, taken in conjunction with the preceding paragraph it doesn't, since said preceding paragraph is quite clear about the role of CTS -- it tells you whether you are connected to the communication channel, i.e. whether RTS has succeeded yet. Whether or not the standard says it out loud, half-duplex line turnaround is very definitely what CTS and RTS were *intended* for. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
marcum@rhino.UUCP (Alan M. Marcum) (05/29/85)
In article <1808@ukma.UUCP> edward@ukma.UUCP (Edward C. Bennett) writes: >In article <879@sdcsvax.UUCP>, brian@sdcsvax.UUCP (Brian Kantor) writes: >> Hayes modems, for example, use timing and a sequence of characters.... >> Brian Kantor UC San Diego > > Go read your manual!! > Why do you think the 3 second time is required before and after... >NOTE: The comments are based on ownership of a Prometheus ProModem 1200, which > emulates a Hayes. >edward Many times, "compatible" modems (terminals, ...) aren't really. I've seen many instances when a "compatible" modem, or a modem which "emulates" some other modem, either adds a few nice whistles, or is compatible on only some stuff. Indeed, read the manual FOR YOUR MODEM! -- Alan M. Marcum Fortune Systems, Redwood City, California ...!ihnp4!fortune!rhino!marcum
phil@amdcad.UUCP (Phil Ngai) (05/30/85)
In article <5633@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >> > when they first started. Their 3101 terminal has a female 25 pin connector, >> > which is wrong. ... >> >> Why is a female connector on a DTE terminal port wrong??? >> As far as ASYNC-only devices go, a male DTE connector is quite rare. My H19 is male. My VT100 is male. My VT220 is male. My IBM-PC serial port is male. My IBM 7171 protocol converter is male. All my VAX serial ports are male. All this equipment is DTE and conforms to the RS-232 standard. I don't think male DTE connectors are rare at all. -- What do you do the day after a peak experience? Phil Ngai (408) 749-5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.ARPA