Browse Prior Art Database

Comments on The New Telnet Protocol and its Implementation (RFC0559)

IP.com Disclosure Number: IPCOM000003656D
Original Publication Date: 1973-Aug-15
Included in the Prior Art Database: 2000-Sep-13
Document File: 4 page(s) / 10K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

A.K. Bhushan: AUTHOR

Abstract

We at MIT-DN have implemented the new TELNET protocol (both server and user). This RFC describes our experience with the implementation (particularly the use of GO AHEAD) and in bringing the new User and Server TELNET's in operation (the new TELNET is not compatible with the old). We have a few suggestions here which should help other implementors and lead to a smoother transition to the new protocol.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 30% of the total text.

Network Working Group Abhay K. Bushan

Request For Comments #559 MIT Project MAC

NIC # 18482 August 15, 1973

Comments on the new TELNET Protocol and its Implementation

We at MIT-DN have implemented the new TELNET protocol (both server

and user). This RFC describes our experience with the implementation

(particularly the use of GO AHEAD) and in bringing the new User and

Server TELNET's in operation (the new TELNET is not compatible with the

old). We have a few suggestions here which should help other

implementors and lead to a smoother transition to the new protocol.

I. OUR TELNET SERVER IMPLEMENTATION

Our new server TELNET accepts both the "old" and the "new" TELNET

"control sequences". Currently we have the ECHO and the "Suppress Go

Ahead" options implemented and do the "right thing" to varying degrees

with the Interrupt Process (IP), Erase Character (EC), Abort Output

(AO), Are You There (AYT), Break, and Synch character sequences.

A. The ECHO Option

The TELNET server comes up in the default local echo mode and

accepts both the old and the new TELNET control sequences. The server

starts the negotiation for remote echo (server echoing) by sending the

sequence "IAC WILL ECHO" but changes the echo mode only when an

affirmative "IAC DO ECHO" is received. After the cutoff date for old

protocol we will stop "honoring" the old TELNET control sequences.

B. The Go Ahead and Suppress GA option

The server comes up in the send GA mode and transmits the required

"IAC GA" sequence whenever the server detects that it needs to send a

GA. It should be noted that our scheme for sending GA's works most but

not all of the time.

There is really no reliable way for our server TELNET to find out

when a process is actually waiting for network input. On our system,

the server TELNET does not "control" user's process, it only acts as a

terminal handler at the TTY level.

A quick investigation revealed that the above problem (of sending

GA's reliably) is not confined to the ITS operating system alone. In

fact TENEX (ref. conversation with Ray Tomlinson) and DEC-10 (ref.

conversation with Ed Taft at Harvard) systems will encounter similar

problems.

Our solution to the GA sending problem was to have the server wait

2.5 seconds after sending output to see if there is more output to be

sent. If the server has been "idle" for more than 2.5 seconds in the

"output-sent" state it sends a GA and goes in an I/O wait state (looking

for input or output). This scheme works most (but not guaranteed all)

of the time and doesn't cause any noticeable delay. It is possible for

the server to send an extra GA. Our experimentation revealed that 1-5

seconds was a good range for this "idling time constant".

We do implement the "suppress GA" option and will not send GA to

hosts who agree to negotiate out of it. Our server tries to negotiate

these suppress GA option.

C. Other Option...