Browse Prior Art Database

Echoing strategy for satellite links (RFC0357)

IP.com Disclosure Number: IPCOM000004893D
Original Publication Date: 1972-Jun-26
Included in the Prior Art Database: 2001-Jul-11
Document File: 14 page(s) / 30K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

J. Davidson: AUTHOR

Abstract

As mentioned in RFC 346 ("Satellite Considerations" by Jon Postel) those interactive systems which provide echoing for full-duplex terminals over the ARPANET become more awkward to use as transmission delays increase. The reason, of course, is that a character's round trip time is added to the inherent echo delay of the server with the result that the terminal echoing appears extremely sluggish.

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

Network Working Group John Davidson Request for Comments: 357 University of Hawaii NIC: 10599 Will Crowther Categories: Remote Controlled Echoing, Satellite, TELNET BBN References: RFC's 346, 355, 358, 318 John McConnell

ILLIAC Jon Postel

UCLA June 26, 1972

An Echoing Strategy For Satellite Links

I. Introduction

As mentioned in RFC 346 ("Satellite Considerations" by Jon Postel) those interactive systems which provide echoing for full-duplex terminals over the ARPANET become more awkward to use as transmission delays increase. The reason, of course, is that a character's round trip time is added to the inherent echo delay of the server with the result that the terminal echoing appears extremely sluggish.

For a terminal separated from its server by a single satellite link, the delay will be such that even if echoing at the server were instantaneous, the latency between keying and printing of an input character will be nearly half a second. If, in addition, the character is routed thru a portion of the surface net, the delay will be of course increase. It is estimated that echo delays of at least one second will not be uncommon.

This document describes a strategy which will eliminate the delay associated with simple echoing and allow the transmission delay to be hidden in the cost of computation only. This scheme is proposed as an optional addition to existing User TELNETs; its use requires the explicit support of a cooperating server process.

II. Standard Echo Strategy

Echoing for locally connected full-duplex terminals is normally provided at the server by a resident system task called the (e.g.) Terminal Handler. The Terminal Handler echoes on a one-for-one or simple replacement basis and buffers all typed input on behalf of the user process.

To let the user process operate most efficiently, the Terminal Handler should collect characters until a complete command or parameter (or whatever) has been typed. Then, presumably, the process can do some significant computing. Since the user process

Davidson [Page 1]

RFC 357 An Echoing Strategy For Satellite Links June 1972

knows the syntax of the string it expects, it can specify to the Terminal Handler those characters which delimit completed parameters. Such characters are called 'Wakeup Characters' since the user process is awakened as they are echoed.

Certain commands keyed by the user will require an output response from the process. In order that the typed commands be followed by its response and be separated from succeeding commands, the Terminal Handler must suspend echoing of user type-ahead. It can resume echoing (starting for type-ahead with the unechoed characters in the buffer) as soon as the process has stated (implicitly or explicitly) that it has completed the output response.

Characters which cause the Terminal Handler to suspend echoing are called 'break char...