Browse Prior Art Database

Comments on RCTE from the Tenex Implementation Experience (RFC0718)

IP.com Disclosure Number: IPCOM000003763D
Original Publication Date: 1976-Jun-30
Included in the Prior Art Database: 2000-Sep-13
Document File: 2 page(s) / 4K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

J. Postel: AUTHOR

Abstract

Comments on RCTE from the TENEX Implementation Experience

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

Network Working Group Jon Postel (SRI-ARC)

Request For Comments: 718 Jun 1976

NIC #35874

The following memo was a page of a document describing changes in

version 1.34 of the Tenex system. I believe that the author is Ray

Tomlinson or someone else in the BBN-RCC Tenex group. In any case Ray

has agreed that these comments should be circulated to the to the

network community, rather than to only the Tenex community.

Comments on RCTE from the TENEX Implementation Experience

The code to implement the RCTE option of the new TELNET protocol for

TENEX has been completed. The RCTE option permits a reduction in network

traffic by deferring the transmission of characters which will not cause

the receiving user program to be activated until a character which will

cause the user program to be activated. A further reduction is achieved

by minimizing the flow of echo characters back to the user TELNET

program. This is done by having the server instruct the user TELNET to

echo the group of characters up through the next wakeup character. By

sending this command as the user program is about to read the first

character of that group, the echo is guaranteed to follow any response

to the preceding group of characters.

Significant problems with the RCTE protocol were encountered. The

handling of spontaneous output was specified in a way that made the

implementation extremely difficult to do correctly (if, indeed, a

correct implementation is possible). The solution here was to completely

isolate the control of input transmission and echoing from the

characters flowing in the output stream. Synchronization of input and

output then occurs directly by virtue of the embedding of control

information in the output stream. This approach permits a simplified

coding of both the user TELNET and server TELNET.

A second problem was the handling of interrupt characters. The RCTE

protocol fails to provide an explicit mechanism for interrupt characters

thus necessitating the handling of interrupt characters as program

wakeup characters. Since the interrupt characters are not actually

handled as program wakeup characters and, in fact, bypass the terminal

input buffer, a special provision had to be made to get the command sent

back to the user TELNET to indicate that the character stream should be

echoed beyond the point where the interrupt character was typed. The

transmission must be synchronized with the processing of the terminal

input buffer so that it will be sent at the proper time. This was

achieved by putting a marker in the input buffer at the point where the

interrupt character was. This marker is never given...