hedrick@topaz.rutgers.edu.UUCP (06/15/87)
The terminal servers we use, including those from Bridge and cisco, do have the ability to pass ^S unchanged. Unfortunately, there are reasons why this isn't useful in all situations. Certain terminals (particularly VT100's and emulators) are unable to keep up with output at full speed, so they send ^S to stop output. If the terminal server is set to pass ^S to the host, you may lose characters. Here's why: TCP gets much of its performance by allowing lots of data to be "in flight" at any given time. When you type ^S, it may go to the host immediately, and the host program stops producing data. But everything that is in the various buffers in the host and in the terminal server will still come out. So you get between a few lines and several pages of data even after you have typed ^S. If your terminal needs ^S for flow control, the result is quite likely that you lose data. In summary, ^S acting in a transparent mode isn't much good for flow control. I know of several reasonable solutions: 1) Ban terminals that require flow control for straight text. We adopted this solution for some time, but have recently found it impossible to prevent users from buying VT100 and VT220 compatible terminals. 2) Set up the terminal server to act on ^S locally. Both Bridge and cisco allow the administrator to set up this behavior. This makes flow control work just fine, but it makes ^S and ^Q useless as Emacs commands, since they'll never even make it to the host. If your administrators have taken this approach, then you're going to have to set up Emacs to use something else for those commands, or you're going to have to change the setup on the terminal server when you use it. (Logically, any system whose management preempts ^S and ^Q for flow control should also take time to supply their users with a convenient way to rebind the keys in Emacs.) 3) Set up padding so that flow control is never needed. Both Bridge and cisco allow you to specify that a certain number of nulls should be sent after a CR or LF. Unless you like running VT100's in smooth scroll mode, you should always be able to find a padding setting that keeps your terminal happy. In this case, there is no need for the terminal server to act on ^S locally, since the terminal will never generate one. However, humans may still want a way to pause output. But if this is for use by humans, there is no need to use ^S. So we set up ^\ to pause output on all of our terminal servers. A second ^\ (Bridge) or any character (cisco) will resume output. ^\ was chosen because it didn't seem to interfere substantially with any programs. 4) Use a terminal server that handles the rlogin protocol. This will let you use ^S to stop output normally, but when you go into Emacs, it will turn off this feature. Encore's terminal servers do this, and we hear rumors that cisco will probably do it shortly. Unless your system administrators are particularly restrictive, it should be possible for you to adjust the settings on your terminal server, if you don't like the approach that they have taken. With Bridge it is possible for the system administrator to control whether you have this ability. With cisco it is always present. Unfortunately with Bridge you may have to change settings for each connection that you open, unless the terminal is in your office, where presumably you can be allowed to set up your own defaults. With cisco you should be able to change the setting once, when you first start using the server.
ken@rochester.arpa (Ken Yap) (06/15/87)
|by humans, there is no need to use ^S. So we set up ^\ to pause |output on all of our terminal servers. A second ^\ (Bridge) or any |character (cisco) will resume output. ^\ was chosen because it didn't |seem to interfere substantially with any programs. 4) Use a terminal I guess you don't use Kermit or need to make programs dump core. To be fair, both of these uses can be reprogrammed. Ken