Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!MATHOM.CISCO.COM!BILLW From: BILLW@MATHOM.CISCO.COM (William Chops Westfield) Newsgroups: comp.protocols.tcp-ip Subject: Re: Escape sequences over Telnet/TCP Message-ID: <12682493086.11.BILLW@mathom.cisco.com> Date: 3 May 91 20:55:15 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 62 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. -------