FREEMAN@SUMEX-AIM.ARPA (Andy Freeman) (03/17/85)
Barry Shein, Boston University writes - As the world becomes more networked login paths are becoming less transparent. Many switches and terminal servers reserve a few chars, typically (like our Ungermann/Bass) ^S/^Q for flow control, some sort of disconnect character or at least a 'wakeup', and quite possibly a DLE (eg. ^P for literally quote next character, this is the ASCII DLE.) What happens is that the switch, being overloaded, wants to send a ^S to the system to stop flow for a while. I *strongly* suggest people start fixing software universally to accomodate this rather than fighting it. All EMACS' that I know of allow re-definition at the user level of ^S/^Q to some other keys. [other suggestions on how to effect the above in 4.2] Argh! Networks are supposed to solve problems, not gratuitously add new ones. Separating data from control is good; just because current implementations of traditional human i/o devices (eg ordinary terminals) don't do a very good job of it is no reason to let other devices screw up and add to the problem. Switches, terminal servers, intermediate hosts, etc. are all computers. If they've got something to say to each other, they should and CAN do it out-of-band. Anything else is like requiring users to prefix every input with routing info. (Besides, there are scads of things for them to talk about, like time-of-day, breath-of-life, are-you-there, what's-your-sign. If the separation isn't made, then soon there won't be any room for what I wanted to "say" or "hear" in the first place.) They already have to do some out-of-band communication, why shouldn't flow control and everything else mentioned above go in that category? Yes, there are defective terminals which don't work at the speeds they are used at. RS-232 has control lines to help them, but they don't work over (private) modems, and many computers would ignore them even if the terminal used them. There are also no good solutions for people who overrun the input buffer on the poor machine they're typing at. Both of these situations are errors. (And both can be fixed by putting the local terminal server in your terminal with an out-of-band way to talk to you.) I'm typing this through a (barely) adequate terminal server. It manages my multiple connections and does whatever flow control, etc. it needs (as opposed to what I need) without taking characters away from my use. The OS' on my hosts, some of whom are 4.2, think of the server as another computer and none of the programs I use know what's going on. Since it is an ordinary terminal, I have to use an in-band command sequence to talk to the server, but that's a hardware deficiency. (It can do my flow control locally, but it isn't as flexible/programmable as that provided by the hosts I use.) I can see asking it to pad my deficient terminal and even provide some of the sub-functions of a screen handling package, but I'd rather have a smarter terminal with a simple integrated server for that and the other obvious features anyway. Sorry this got so long. Dan Ingalls' paper in the first IEEE Software (last January) covers issues like this much more clearly. -andy -------
ron@BRL-TGR.ARPA (Ron Natalie) (03/17/85)
> Switches, terminal servers, intermediate hosts, etc. are all > computers. If they've got something to say to each other, they should > and CAN do it out-of-band. You missed the point. The problem with ^s and ^q and the other things that Barry Shein points out is that they aren't the switches, etc.. talking to each other, it is them talking to the user terminal. The Sytek and other networks use XON and XOFF to temporarily control the speed of data transfers. Most terminals do as well. Ever use EMACS on a VT100? The flow control methods in RS-232C don't work over ANY modems, and terminals are not spec'd to connect to computers directly. That's what NULL MODEMs are for. If you don't like, I guess you'll have to sue ANSI. -Ron