The Terminal IMP implementation(3)

　　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　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 RFCfrom 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 RFCto 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 pthologic 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.

　　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 RFCwas put into machine readable form for entry ]

　　[ into the online RFCarchives by Randy Dunlap 5/97 ]