rfc357.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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

      Two break actions are possible:

      (1) a break character encountered in the input buffer IS moved to
          the print buffer at the appropriate time, or
      (2) a break character encountered in the input buffer IS NOT moved
          to the print buffer.

      The server process will specify which break action should be
      followed. (The two actions correspond to echoing or not echoing
      the break character.)

IV.  Description

   (This description is written in terms of the TIP which, of course,
   embodies a User TELNET.)

   Remote Controlled Echoing is an attempt to remove the echo
   responsibility from the Terminal Handler and push it off into the
   TIP; wakeup processing is still handled at the server.  The process'
   interface (system calls, etc.) to the server's Terminal Handler need
   not change, but the (abbreviated) Terminal Handler (actually a Server
   TELNET) must find a way to relay the process' echo requirements to
   the TIP.  It does this with TELNET commands and control information.
   System calls and echo parameters (break classes, etc.) peculiar to a
   particular serving Host must be interpreted by the Server Telnet
   commands.

   Character Flow

      Refer to figure 1.  A character received from a full-duplex
      terminal will be converted to its NVT equivalent and placed in
      both the transmission AND the input buffers.  The TIP's
      transmission strategy determines when it will be removed from the
      transmission buffer; the server's RCE control commands dictate



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


      when it will be removed from the input buffer.

      A character received from the server will be placed in the output
      buffer.

      Of the three labeled paths DISCARD, ECHO and OUTPUT, exactly one
      is enabled at all times.  RCE commands dictate which one.  Thus
      characters may

         (DISCARD:) be removed in sequence from the input buffer and
                    discarded,
         (ECHO:)    be removed in sequence from the input buffer and
                    placed in the print buffer, of
         (OUTPUT:)  be removed in sequence from the output buffer and
                    placed in the print buffer.

      From the print buffer they will be converted from NVT characters
      and be immediately send to the terminal's printer.

                              +----------------------+
                              | Terminal Keyboard    |
                              +----------------------+
                                           |
                                       Convert to NVT characters
      To       +-------------------+       |
   Server <----|Transmission Buffer|       |
               +-------------------+       |      +-----From Server
                        ^                  |      |
                        |------------------+      |
                        V                         V
                +-----------------+       +-----------------+
                | Input Buffer    |       |  Output Buffer  |
                +-----------------+       +-----------------+
                    |        |                    |
            DISCARD |        +--ECHO---+      +---+ OUTPUT
                    |                  |      |
                    V                  V      V
                   To          +----------------------+
              Oblivion         |     Print Buffer     |
                               +----------------------+
                                          |
                                      Convert from
                                     NVT Characters
                                          |
                                          V
                                 To Terminal Printer

                 Figure 1.  Character Flow within the TIP



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


   Commands: Server to Host

      The following are the proposed TELNET commands sent by the server
      process to the TIP.  Commands (2) thru (5) should not be sent if
      RCE is not being used.

        (1) Use Remote Controlled Echoing.  The server asks the TIP to
            employ the echo strategy described in this document.  The
            TIP can respond either YES (I will use it) or NO. (It is
            suggested that the response YES also be "Use RCE" to
            eliminate race conditions.)

        (2) Set Break Action.  This is actually 2 commands.  The server
            can set the break action to echo or not echo a break
            character.

        (3) Set Break Classes.  This command specifies those equivalence
            classes which are to be considered break classes.  It will
            be a two (8-bit) byte command.

            Note: The envisioned implementation requires the TIP to have
            a table with one entry per ASCII character.  Each entry is
            formatted with one bit position for each equivalence class,
            and a bit is set or reset according as the given character