The Terminal IMP implementation(2)

　　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 RFCto 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" RFCit　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:

　　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　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.