rfc215.txt

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

      4)  The Terminal IMP ignores all RET commands.  The
          Terminal IMP cannot buffer very much input from the
          network to a given terminal due to core size
          limitations.  Accordingly, the Terminal IMP allocates
          only one message and a very small number of bits
          (currently 120 bits; eventually some number in the
          range 8-4000, based on the terminal's speed) on each
          connection for which the Terminal IMP is the
          receiver.  Given such small allocations, the Terminal
          IMP attempts to keep the usable bandwidth as high as
          possible by sending a new allocation, which brings
          the total allocation up to the maximum amount, each
          time that:

          a)  one of the two buffers assigned to the terminal
              is empty, and

          b)  the allocations are below the maxima.

          Thus, if a spontaneous RET were received, the
          reasonable thing for the Terminal IMP to do would be
          to immediately issue a new ALL.  However, if a
          foreign Host had some reason for issuing a first



                                                                [Page 4]

RFC #215


          spontaneous RET, it would probably issue a second RET
          as soon as it received the ALL.  This would be likely
          to lead to an infinite (and very rapid) RET-ALL loop
          between the two machines, chewing up a considerable
          portion of the Terminal IMP's bandwidth.  Since the
          Terminal IMP can't "afford" to communicate with such
          a Host, it ignores all RETs.

      5)  The Terminal IMP ignores all GVB commands.
          Implementation of GVB appears to require an
          unreasonable number of instructions and, at the
          moment at least, no Host appears to use the GVB
          command.  If we were to implement GVB we would always
          RET all of both allocations and this doesn't seem
          very useful.

      6)  The Terminal IMP does not handle a total bit-
          allocation greater than 65,534 (2^16-2) correctly.
          If the bit-allocation is ever raised above 65,534 the
          Terminal IMP will treat the allocation as infinite.
          This treatment allows the Terminal IMP to store the
          bit allocation for each connection in a single word,
          and to avoid double precision addition and
          subtraction.  Our reasons for this decision are:

      a)  A saving of more than 100 words of memory which
          would be required for allocation tables and for
          double precision addition/subtraction routines.

      b)  Our experience, which indicates that very few
          Hosts (probably one at most) ever raise their
          total bit allocation above 65,534 bits.

      c)  Our expectation that any Host which ever raises
          its bit allocation above 65,534 probably would be
          willing to issue an infinite bit allocation if
          one were provided by the protocol.  Once the bit
          allocation is greater than about 16,000, the
          message allocation (which the Terminal IMP
          handles correctly) is a more powerful method of
          controlling network loading of a Host system than
          bit allocation.  We believe that Hosts which have
          loading problems will recognize this.

      7)  The Terminal IMP ignores the "32-bit number" in the
          ICP.  When the Terminal IMP (the "user site")
          initiates the Initial Connection Protocol the actual
          procedure is to send the required RTS to the logger



                                                                [Page 5]

RFC #215


          socket of the user-specified foreign Host and
          simultaneously to set the terminal user's send and
          receive sockets in a state where each will accept
          any RFC from the specified Host.  The 32-bit socket
          number transmitted over the logger connection is
          ignored, and the first RTS and STR addressing the
          user's sockets will be accepted (and answered with
          matching RFCs).

          The ICP allows the foreign Host to transmit the RFCs
          involving Terminal IMP sockets "U+2" and "U+3" at
          any time after receipt of the RFC to the (foreign
          Host's) logger socket.  In particular, the RFCs may
          arrive at the Terminal IMP before the 32-bit
          number.  In the case of a "normal" foreign Host, the
          first incoming RFCs for sockets U+2 and U+3 will come
          from the sockets indicated by the 32-bit number, so
          it doesn't matter if the number is ignored.  In the
          case of a pathologic foreign Host, a potentially
          infinite number of "wrong" RFCs involving U+2 and
          U+3 may arrive at the Terminal IMP before the 32-bit
          number is sent.  The Terminal IMP would be required
          to store this stream of RFCs pending arrival of the
          32-bit number, then issue CLS commands for all
          "wrong" RFCs.  However, the Terminal IMP does not
          have infinite storage available for this purpose (it
          is also doubtful that a terminal user really wants to
          converse with a pathologic foreign Host) so the
          Terminal IMP assumes that the foreign Host is
          "normal" and ignores the 32-bit number.

   B)  Other Design Choices Related to Protocol

          1)  The Terminal IMP ignores incoming ERR commands and
              does not output ERR commands.

          2)  The Terminal IMP assumes that incoming messages have
              the format and contents demanded by the relevant
              protocols.  For example, the byte size of incoming
              TELNET messages is assumed to be 8.  The major checks
              which the Terminal IMP does make are:

              a)  If an incoming control message has a byte count
                  greater than 120 then it is discarded.







                                                                [Page 6]

RFC #215


              b)  If a control command opcode greater than 13 is
                  found during the processing of a control message
                  then the remainder of the control message is
                  discarded.

              c)  If an incoming data message has a byte count
                  indicating that the bit allocation for the
                  connection is exceeded (based on the assumed byte
                  size) then the message is discarded.

          3)  If one control message contains several RST commands
              only one RRP is transmitted.  If several control
              messages, each containing RST commands, arrive "close
              together" only one RST is returned.  [The actual
              implementation is to set a bit each time a RST is
              found (in "foreground") and to reset the bit when a
              RRP is sent (in "background").]

          4)  Socket numbers are preassigned based on the hardware
              "physical address" (in the terminal multiplexing
              device) of the terminal.  The high order 16 bits of
              the socket number give the device number (in the
              range 0-63) and the low order bits are normally 2 or
              3 depending on the socket's gender (zero is also used
              during ICP).  [We would be pleased to see socket
              number length reduced to 16 bits; in that case the
              high order 8 bits would be mapped to the device and
              the low order 8 bits would contain 2 or 3.]

          5)  During ICP, with the Terminal IMP as the user site,
              the Terminal IMP follows the "Listen" option rather
              than the "Init" option (as described at the top of
              page 3, NIC #7170).  In other words, the Terminal IMP
              does not issue the RFCs involving sockets U+2 and U+3
              except in response to incoming RFCs involving those
              sockets.  In this context, we will mention that the
              "deadlock" mentioned in NWG-RFC #202 does not exist,
              since the ICP does not give the server the "Listen"
              option (see NIC #7170, page 2).


          [ This RFC was put into machine readable form for entry ]
            [ into the online RFC archives by Randy Dunlap 5/97 ]








                                                                [Page 7]