mmorse@Z.NSF.GOV ("Michael H. Morse") (05/03/91)
We have a public information system (a bulletin board) that anyone on the Internet can log on to. The user interface is full screen and makes use of cursor control keys, function keys, and keypad functions such as pageup/pagedn. It also uses the Escape key to mean "exit this function." Like curses, we use a timer to distinguish between an escape-sequence and the escape-key. Dispite dire warnings, we have found that this works across the Internet for *most* people. The reason it works, from my inspection of packets, is that, most of the time, Telnet/TCP puts the entire escape sequence into a single packet, so no matter how long it spends traversing the network, our timer works. We have recently run into a system that seem to purposely break the escape sequence up. First it sends a packet with just the Escape character, then it sends a packet with the remainder of the escape sequence. Obviously, a lot of the time this doesn't work on our system, as the timer runs out before the rest of the escape sequence arrives. I assume it is doing this on purpose because it *always* puts an escape in a single packet, but other packets sometimes contain multiple characters. My question is: How common is this? Where did this "feature" come from? Are more or fewer systems going to behave like this in the future? Any information from folks familiar with this area would be appreciated. Is the feature implemented in Telnet or in TCP? I would think that most Telnet/TCP implementations would want to put closely typed characters into a single packet to save overhead, and what could be more closely typed than an escape sequence? Thanks in advance. --Mike p.s. Please don't flame me for the choice of using the Escape key. I understand the technical limitations, and the fact that there is probably nothing in the TCP/IP specs that guarantee that the entire escape sequence should arrive together. -- Michael Morse Internet: mmorse@note.nsf.gov National Science Foundation BITNET: mmorse@NSF 1800 G St. N.W. Room 401 Telephone: (202) 357-7659 Washington, D.C. 20550 FAX: (202) 357-7663
BILLW@MATHOM.CISCO.COM (William Chops Westfield) (05/04/91)
Like curses, we use a timer to distinguish between an
escape-sequence and the escape-key. Dispite dire warnings, we have
found that this works across the Internet for *most* people. The
reason it works, from my inspection of packets, is that, most of the
time, Telnet/TCP puts the entire escape sequence into a single packet,
so no matter how long it spends traversing the network, our timer
works.
We have recently run into a system that seem to purposely break the
escape sequence up. First it sends a packet with just the Escape
character, then it sends a packet with the remainder of the escape
sequence. Obviously, a lot of the time this doesn't work on our
system, as the timer runs out before the rest of the escape sequence
arrives. I assume it is doing this on purpose because it *always*
puts an escape in a single packet, but other packets sometimes contain
multiple characters.
My question is: How common is this? Where did this "feature" come
from? Are more or fewer systems going to behave like this in the
future? Any information from folks familiar with this area would be
appreciated. Is the feature implemented in Telnet or in TCP? I would
think that most Telnet/TCP implementations would want to put closely
typed characters into a single packet to save overhead, and what could
be more closely typed than an escape sequence?
I suspect that what you see is an implementation of the "Nagle algorithm"
(RFC896), which is a method of conserving network bandwidth, by logically
setting the data collection time of the transmitting host to the TCP RTT.
What you do essentially, is send any data you have, but don't send any more
until you receive an ACK for the first packet (or have a full datagram to
send). Nagle algorithms wreck havoc with anything that tries to base
decisions on the timing between characters.
Quite a while ago, cisco proudly implemented this useful sounding
algorithm, and prompt started running into the most obscure problems with
Function keys. The cisco terminal server always put "all" of the available
data in each TCP packet - hwoever, since they were rather fast, we usually
noticed and sent a packet with the first byte of a function key sequence
before the next character had made its way through the uart. Then we
waited for the ACK, but since pressing a function key usually does not
recult in any characters coming back until the whole sequence is received,
we hit the delayed ack code, so the ack was held up for an additional 200
mS in the remote host. Where this got really bad was when using back to
back terminal servers in "milking machine" mode - the algorithm got envoked
in both directions (once on function key, again on the escape sequence to
move the cursor) resulting in total delays from keypress to actual movement
of almost a full second.
The users were not happy. The Nagle algorithm is now optional on cisco
terminal servers.
The latest Van Jacobson TCP degenerates nicely to the Nagle algorthm for
an idle connection, which might be a sign that this sort of thing will
become more common in the future. I don't know if the average unix system's
response to a keypress is fast enough for it to matter most of the time,
but such things tend to keep getting faster...
Bill Westfield
cisco Systems.
-------mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) (05/04/91)
I may be wrong; however, from your description I would suspect that the system in question is either a PDP11 or VAX running almost any of the DEC proprietary operating systems--IAS, RSX, RSTS/E, TSX, VMS, etc. Standard handling of an <ESC> by the terminal driver is to terminate the current read when received. The remainder of the escape sequence will be the inserted as the first bytes in the next buffer. If this is the case, the fault lies in the implementation of the TELNET client software which is not handling escape sequences correctly in this particular environment. Merton Campbell Crockett
imp@solbourne.com (Warner Losh) (05/05/91)
In article <9105040208.AA21383@WLV.IMSD.CONTEL.COM> mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes: >IAS, RSX, RSTS/E, TSX, VMS, etc. Standard handling of an ><ESC> by the terminal driver is to terminate the current read when >received. I don't recall the other operating systems well enough to comment, but this IS *NOT* the case under VMS. The terminal driver "knows" about VT100 escape sequences so it can do command line editing. Since these escape sequences start with ESC, the terminal driver CAN'T abort the read. Now if it gets <ESC><ESC>, then it will abort the read with a bad escape sequence. (Or maybe this is an RMS level function, it has been a while....) Warner -- Warner Losh imp@Solbourne.COM God is an Iron
ejbehr@rs6000.cmp.ilstu.edu (Eric Behr) (05/05/91)
Thanks to Glen Overby, the 10Base-T articles are now ftp-able. Here is Glen's article from comp.dcom.lans: ----------------------------------- Article 4706 of comp.dcom.lans: From: overby@plains.NoDak.edu (Glen Overby) Subject: Re: 10Base-T hubs collection Summary: ok, here it is... Organization: Tea & Ching labs In article <1991May03.044620.12865@rs6000.cmp.ilstu.edu> ejbehr@rs6000.cmp.ilstu.edu (Eric Behr) writes: >i) since it does look hot, how about a volunteer who could provide some >disk space for ftp access? I would, but the only Unix box within 10 miles Ok, time for me to contribute a little bit back to the net. You can find this on plains.nodak.edu [134.129.111.64] in pub/gpo/10Base-T-hubs if you don't have ftp access, ask archive-server@plains.nodak.edu. -- Glen Overby <overby@plains.nodak.edu> uunet!plains!overby (UUCP) overby@plains (Bitnet) ----------------------- -- Eric Behr, Illinois State University, Mathematics Department Internet: ejbehr@rs6000.cmp.ilstu.edu Bitnet: ebehr@ilstu
mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) (05/05/91)
Warner:
-In article <9105040208.AA21383@WLV.IMSD.CONTEL.COM>
-mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes:
->IAS, RSX, RSTS/E, TSX, VMS, etc. Standard handling of an
-><ESC> by the terminal driver is to terminate the current read when
->received.
-I don't recall the other operating systems well enough to comment, but
-this IS *NOT* the case under VMS. The terminal driver "knows" about
-VT100 escape sequences so it can do command line editing. Since these
-escape sequences start with ESC, the terminal driver CAN'T abort the
-read. Now if it gets <ESC><ESC>, then it will abort the read with a
-bad escape sequence. (Or maybe this is an RMS level function, it has
-been a while....)
Are you confusing observed behaviour with actual behaviour? Its been a
number of years since I've looked at the VMS sources and at that time there
was no command line editing; however, it would seem inappropriate to add
command line editing into the terminal port driver (maybe its class--I keep
getting confused as to which deals with the physical interface and which
deals with the logical interface).
I would suspect that there is no logic in the terminal driver that is check-
ing to determine if the I/O request was issued by DCL. The usage of escape
sequences are application dependent and in this case DCL is the application.
If the terminal driver were interpreting escape sequences, receipt of a cursor
up sequence would reposition the cursor one line up on the display and not
display the previous command line on the current line.
Terminal drivers for all of the above operating systems know about ANSI and
DEC proprietary escape sequences. Except in the case of <ESC><ESC>, the
read completes with a successful status with the reason that an <ESC> had
been received. Assuming that the application had been using multi-byte buffers
for its read operations, the status that an <ESC> had been received can be
used to switch to single byte reads until the entire escape sequence has
been read. The application, at this point, performs whatever operations
are appropriate for the escape sequence--perhaps, display the previous command
line on the current line.
Depending on the mode associated with the read, some of the terminal drivers
will return a secondary status that is an encoded value that is a translation
of the entire escape sequence. Some modes such as read-pass-all (essentially
equivalent to Unix "raw" mode) ignore escape sequences in their entirety
and only return a completed status when the receive buffer is exhausted.
Having been involved in porting a TELNET client from a Unix environment some
years ago, the interface to the terminal driver was, perhaps, the most
difficult aspect of the port.
Merton Campbell Crockett
GTE Contel Federal Systemsjbvb@FTP.COM (James B. Van Bokkelen) (05/06/91)
The users were not happy. The Nagle algorithm is now optional on cisco
terminal servers.
Our PC/TCP for DOS always uses the Nagle algorithm, so we chose to make our
full-screen Telnet and Rlogin clients pass the whole escape sequence to TCP
in one write. It may cause trouble when INT 14h redirection is used, though.
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (05/08/91)
In article <9105040208.AA21383@WLV.IMSD.CONTEL.COM> mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes: > If this is the case, the fault lies in the implementation of > the TELNET client software which is not handling escape sequences correctly in > this particular environment. No. The fault lies entirely in a keyboard code convention that produces streams that can't be uniquely decoded without timing information. In a better world, no valid key combination would produce a proper prefix of another, and these problems would disappear. (One would think that a virtual terminal protocol would address these issues. SUPDUP does, anyway.) ---Dan