rfc215.txt

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

Network Working Group                                      A. McKenzie
Request for Comments: 215                                          BBN
NIC #7545                                               30 August 1971
Categories: C.2, D.1, D.3, G.1
Updates: none
Obsoletes: none

                         NCP, ICP, and TELNET:

                    The Terminal IMP Implementation

       By early December there will be six Terminal IMPs incorporated
into the network, with additional Terminal IMPs scheduled for delivery
at a rate of about one per month thereafter.  For this reason the
implementation of network protocols (and deviations from them) may be of
interest to the network community.  This note describes the choices made
by the Terminal IMP system programmers where choices are permitted by
the protocols, and documents some instances of non-compliance with
protocols.

     Most of the choices made during protocol implementation on the
Terminal IMP were influenced strongly by storage limitations.  The
Terminal IMP has no bulk storage for buffering, and has only 8K of 16-
bit words available for both device I/O buffers and program.  The
program must drive up to 64 terminals which generally will include a
variety of terminal types with differing code sets and communication
protocols (e.g., the IBM 2741 terminals).  In addition, the Terminal IMP
must include a rudimentary language processor which allows a terminal
user to specify parameters affecting his network connections.  Since the
Terminal IMP exists only to provide access to the network for 64
terminals, it must be prepared to maintain 128 (simplex) network
connections at any time; thus each word stored in the NCP tables on a
per-connection basis consumes a significant portion of the Terminal IMP
memory.

     It should be remembered that the Terminal IMP is designed to
provide access to the network for its users, not to provide service to
the rest of the network.  Thus the Terminal IMP does not contain
programs to perform the "server" portion of the ICP; in fact, it does
not have a "logger" socket.











                                                                [Page 1]

RFC #215


     The Terminal IMP program currently implements only the NCP, the
ICP, and the TELNET protocol since these are of immediate interest to
the sites with Terminal IMPs.  It is anticipated that portions of the
data transfer protocol will be implemented in the future; the portions
to be implemented are not yet clearly defined, but will probably include
the infinite bit stream (first) and the "transparent" mode (later).
Developments in the area of data transmission protocol will be
documented in the future.

     The remainder of this note describes, and attempts to justify,
deviations from the official protocols and other design choices of
interest.  Although written in the present tense, there are some
additional known instances of deviation from protocol which will be
corrected in the near future.

   A)  Deviations from Protocols

      1)  The Terminal IMP does not guarantee correct response
          to ECO commands.  If some Host A sends a control
          message containing ECOs to the Terminal IMP, and the
          message arrives at a time when

          a)  the Terminal IMP has a free buffer and

          b)  the control link from the Terminal IMP to Host A
              is not blocked

          then the Terminal IMP will generate a correct ERP for
          each ECO.  In all other cases the ECO commands will
          be discarded.  (All control messages sent by the
          Terminal IMP begin with a NOP control command, so if
          Host A sends a control message consisting of 60 ECO
          commands, the Terminal IMP will answer (if at all)
          with a 121-byte message -- 1 NOP and 60 ERPs.)

          The reason for this method of implementation is that
          to guarantee correct response to ECO in all cases
          requires an infinite amount of storage.  For
          example, suppose Host A sends control messages, each
          containing an ECO command, to Host B at the rate of
          one per second, but that Host A accepts messages from
          the network as slowly as possible (one every 39
          seconds, say).  Then Host B has only three choices
          which do not violate protocol:

          a)  Declare itself dead to the network (i.e., turn
              off its Ready line), thereby denying all its
              users use of the network.



                                                                [Page 2]

RFC #215


          b)  Refuse to accept messages from the network
              faster than the slowest possible foreign Host
              (i.e., about one every 39 seconds).  If Host B is
              a Terminal IMP, this is almost certainly slow
              enough to soon reach a steady state of no users.

          c)  Implement "infinite" storage for buffering
              messages.

          Since it is clear that none of the "legal" solutions
          are possible, we have decided to do no buffering,
          which should (we guess) satisfy the protocol well
          over 99% of the time.

      2)  The Terminal IMP does not guarantee to issue CLS
          commands in response to "unsolicited" RFCs.  There
          are currently several ways to "solicit" an RFC, as
          follows:

          a)  A terminal user can tell the Terminal IMP to
              perform the ICP to the TELNET Logger at some
              foreign Host.  This action "solicits" the RFCs
              defined by the ICP.

          b)  A terminal user can send an RFC to any particular
              Host and socket he chooses.  This "solicits" a
              matching RFC.

          c)  A terminal user can set his own receive socket
              "wild."  This action "solicits" an STR from
              anyone to his socket.  Similarly, the user can
              set his send socket "wild" to "solicit" an RTS.

          If the Terminal IMP receives a "solicited" RFC it
          handles it in accordance with the protocol.  If the
          Terminal IMP receives a control message containing
          one or more "unsolicited" RFCs it will either issue
          CLS commands or ignore the RFCs according to the
          criteria described above for answering ECOs (and for
          the same reasons).  Further, if the Terminal IMP
          does issue a CLS in response to an unsolicited RFC
          it will not wait for a matching CLS before
          considering the sockets involved to be free for other
          use.

      3)  After issuing a CLS for a connection, the Terminal
          IMP will not wait forever for a matching CLS.
          There are two cases:



                                                                [Page 3]

RFC #215


          a)  The Terminal IMP has sent an RFC, grown tired of
              waiting for a matching RFC, and therefore issued
              a CLS

          b)  The Terminal IMP has sent a CLS for an
              established connection (matching RFCs exchanged)

          In either of these cases the Terminal IMP will wait
          for a matching CLS for a "reasonable" time (probably
          30 seconds to one minute) and will then "forget" the
          connection.  After the connection is forgotten, the
          Terminal IMP will consider both sockets involved to
          be free for other use.

          Because of program size and table size restrictions,
          the Terminal IMP assigns socket numbers to a terminal
          as a direct function of the physical address of the
          terminal.  Thus (given this socket assignment scheme)
          the failure of some foreign Host to answer a CLS
          could permanently "hang" a terminal.  It might be
          argued that the Terminal IMP could issue a RST to the
          offending Host, but this would also break the
          connections of other terminal users who might be
          performing useful work with that Host.