Echoing strategy for satellite links
RFC 357

Document Type RFC - Unknown (June 1972; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 357 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
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 characters' They are specified by the user process
   based upon the syntax of the expected input.  Normally break
   characters are also wakeup characters.  As examples:

      1. A text editor may gobble up typed English sentences every time
         a period or question mark is echoed.  The two characters are
         wakeup characters only.  There is no need to suspend echoing.

      2. In some systems, an ESC character is used to invoke command
         recognition.  The user who types

               CO [ESC] ABC [ESC] XYZ

         should see as output

            COPY (FROM FILE) ABC (TO FILE) XYZ

         The ESC is both a break and a wakeup.  The printout should be
         the same no matter how fast the user types.

   The server must provide a means for each user process to communicate
   the following to the Terminal Handler:

      1. the set of wakeup characters,
      2. the set of break characters,
      3. which break characters should and which should not be echoed,
         (Some break characters - such as ESC in example 2 - should not
         be echoed).
      4. completion of an output response,
      5. whether or not to echo characters. (Not echoing is useful in
         "hide your input" applications.)

Davidson                                                        [Page 2]
RFC 357         An Echoing Strategy For Satellite Links        June 1972

   As far as implementation, 1. and 2. could be communicated by allowing
   the user process to specify a 128-bit (for an ASCII device) table
Show full document text