GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc215

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.
    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]
/data/webs/external/dokuwiki/data/pages/rfc/rfc215.txt · Last modified: 1997/05/12 20:47 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki