rfc357.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 732 行 · 第 1/3 页

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
   with 1's set for each wakeup character, and another table with 1's
   set for each break character.  This approach becomes fairly expensive
   in terms of core memory as the number of terminals becomes large; the
   system must store these bit tables itself since in most cases the
   user process will not be in core while echoing is being done by the
   Terminal Handler.

   To reduce the storage requirements, the system can make known to all
   its programmers a limited number, say 4, of supported break
   characters for his process from, for example:

      a. alphanumeric characters,
      b. punctuation characters,
      c. echoable control characters (including the bell and CR, etc.),
         or
      d. non-echoable control characters (Control-C, etc.),

   by specifying in a system call which break set(s) should be used.
   This requires no more than 4 bits of system storage per terminal, and
   a single table to identify the set(s) to which each of the 128
   possible ASCII characters belongs.

   For the user process to communicate (3) to the Terminal Handler
   (which break characters should and which should not have echoed), the
   process can specify another 4 bit field with 1's set for those break
   classes whose members should be echoed.  For the 4 classes above,
   only 3 bits would be required since members of class (d) are defined
   to be non-echoable.

   To communicate the completion of an output response (4), the user
   process could issue an explicit system call; or, the Terminal Handler
   could assume completion when the user process requests input of the
   first character following the break.

   "Hide your input" (5) would be communicated by a system call which
   specifies either:

     (a) "break on every character and don't echo any break characters",
         or, for example
     (b) "don't echo anything and break on punctuation, or any control
         character" for an alphanumeric password,

   depending on the syntax of the expression to be hidden.






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


III.  Definitions

   Several new terms need to be defined, some of which are direct
   extensions of the terms used in the "standard echo strategy"
   description.  There is no reason to insist that the four buffers
   presented all be implemented as individual constructs; they are
   logically separated for clarity in the discussions which follow.

   Remote Controlled Echoing (RCE)

      This is the name for the echo strategy described in this document.
      Echoing will be controlled by the (remote) server but performed by
      the User TELNET.

   Input Buffer

      This is a logical buffer used by a User TELNET to hold characters
      in sequence as they are received from the terminal keyboard (after
      they have been converted to NVT characters).

   Transmission Buffer

      This is a logical buffer used by a User TELNET to hold NVT
      characters which have been typed but have not yet been transmitted
      to the server.

   Output Buffer

      This is a logical buffer used by a User TELNET to hold the NVT
      characters received from the server.

   Print Buffer

      This is a logical buffer residing in the User TELNET from which
      characters will be sent in sequence to the terminal printer. (The
      output buffer contains NVT characters which may have to be
      converted to characters employed by the actual terminal.)

   Break Classes

      The 128 possible (7-bit) ASCII characters employed by the Network
      Virtual Terminal can be partitioned into several quasi-equivalence
      classes (for example alphabetic, numeric, punctuation characters,
      etc.). These classes can be defined so that each character is a
      member of at least one class, although it may belong to more than
      one.





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


      A server process may indicate to a User TELNET that certain of
      these classes (or all, or none) are to be considered break
      classes.  That is, a break class is an equivalence class which is
      of special significance to the server process.  In terms of the
      discussion of section II, the Server recognized 4 equivalence
      classes any combination of which might be designated as break
      class by a particular process.

      The RCE implementation will have more than 4 equivalence classes
      (perhaps as many as 8) to provide more flexibility in the choice
      of break character sets.

   Break Action