Skip to main content

I. Errors and Overflow

In line with the discussion in NWG/RFC #48, we felt that two types of errors should be distinguished. One is a real error, such as an RFC composed of two send sockets. This type of error can only be generated by a broken NCP. In the absence of hardware and software bugs, these events should never occur; the correct response upon detection of such an event was outlined in the description of the ERR command in NWG/RFC #54.

The other "error" is an overflow condition arising because finite system resources are exhausted. An overflow condition could occur if an RFC was received, but there was no room to create the requisite tables and queues. This is not a real error, in the sense that no one has done anything incorrect (expect perhaps the system planners in not providing sufficient table space, etc.) Further, a recovery procedure can be well defined, and simply entails repeating the request at a future time. Thus, we believe an overflow condition should be distinguished from a real error.

In NWG/RFC #54 an overflow condition was reported by returning a CLS, as if the connection had been refused. This sequence performs the necessary functions, and leaves the connection in the correct state, but the initiating user is misinformed. He is deluded into thinking that he was refused by the foreign process, when, in fact, this was not the case. In certain algorithms this difference is crucial.

In further defining error conditions, we felt that it would be helpful to specify why the error was detected, in addition to specifying what caused the error. While writing the pseudo-Algol program mentioned in NWG/RFC #55 we differentiated 9 types of errors (listed below). We would, therefore, like to propose the extension of the ERR message to include an 8-bit field following the op code to designate the type of error. This would be followed by the length and text fields, as before. We propose these error types;

  1. UNSPECIFIED ERROR
  2. HOMOSEX (invalid send/rcv pair in an RFC)
  3. ILLEGAL OP CODE
  4. ILLEGAL LEADER (bad message type, etc.)
  5. ILLEGAL COMMAND SEQUENCE
  6. ILLEGAL SOCKET SPECIFICATION - COMMAND
  7. ILLEGAL COMMAND LENGTH (last command in message was too short)
  8. CONNECTION NOT OPEN - DATA
  9. DATA OVERFLOW (message longer than advertised available buffer space)
  10. ILLEGAL SOCKET SPECIFICATION - DATA (socket does not exist)

In light of the other considerations mentioned earlier, we would also like to propose an additional control command to singify overflow:

        +-------------+-------------------+---------------------+
        |     OVF     |     my socket     |     your socket     |
        +-------------+-------------------+---------------------+

The format of the message is similar to that of the CLS message, which it replaces in this context. The socket numbers are 32 bits long and correspond to the socket numbers in the RFC which is being rejected. The semantics of an incoming OVF should be indentical to an incoming CLS; in addition, the user should be informed that he has not been refused but rather has overtaxed the foreign host's resources.

An alternative to creating a separate control command can be realized by considering the similarity between a CLS and an OVF. Conceivably, an eight-bit field could be added to the CLS command to define its derivation. We believe, however, that this alternative is conceptually inferior and practically more difficult to implement.

Overflow does not require serious consideration if it is a significantly rare occurrence. We do not believe this will be the case, and we further believe that its absence will be an unnecessary restriction upon the user.