跳到主要内容

I. 错误与溢出

按照 NWG/RFC #48 中的讨论, 我们认为应当区分两类错误。一类是真正的错误, 例如一个由两个发送套接字组成的 RFC。这类错误只能由出故障的 NCP 产生。在没有硬件与软件缺陷的情况下, 这类事件根本不应发生; 一旦检测到这类事件, 正确的应对方式已在 NWG/RFC #54 对 ERR 命令的描述中作了概述。

另一类“错误”是由于有限的系统资源被耗尽而产生的溢出情况。如果收到了一个 RFC, 却没有空间来创建所需的表和队列, 就可能出现溢出情况。这并不是真正的错误, 因为没有人做错任何事情（也许系统设计者未能提供足够的表空间等除外）。而且, 针对这种情况可以定义明确的恢复流程, 即只需在将来某个时间重发该请求。因此我们相信, 溢出情况应当与真正的错误区别对待。

在 NWG/RFC #54 中, 溢出情况是通过返回一个 CLS 来报告的, 就好像连接被拒绝了一样。这一序列完成了必要的功能, 也使连接处于正确的状态, 但发起方用户却得到了错误的信息。他被误导而以为自己被对方进程拒绝, 而实际情况并非如此。在某些算法中, 这一区别至关重要。

在进一步定义错误情况时, 我们认为除了指明是什么引起了错误之外, 再指明为何检测到该错误也会有所帮助。在编写 NWG/RFC #55 中提到的伪 Algol 程序时, 我们区分出了 9 类错误（列于下文）。因此, 我们希望提议扩展 ERR 消息, 在操作码之后增加一个 8 位字段, 用以标明错误类型。其后照旧是 length 与 text 字段。我们提议以下错误类型:

  1. UNSPECIFIED ERROR
  2. HOMOSEX（RFC 中的收发套接字对非法）
  3. ILLEGAL OP CODE
  4. ILLEGAL LEADER（消息类型有误等）
  5. ILLEGAL COMMAND SEQUENCE
  6. ILLEGAL SOCKET SPECIFICATION - COMMAND
  7. ILLEGAL COMMAND LENGTH（消息中的最后一个命令过短）
  8. CONNECTION NOT OPEN - DATA
  9. DATA OVERFLOW（消息长于已通告的可用缓冲区空间）
  10. ILLEGAL SOCKET SPECIFICATION - DATA（套接字不存在）

鉴于前文提到的其他考虑, 我们还想提议一个额外的控制命令来标明溢出:

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

该消息的格式与 CLS 消息类似, 在此场景下它取代了 CLS。套接字编号为 32 位, 对应被拒绝的 RFC 中的套接字编号。收到 OVF 的语义应当与收到 CLS 完全相同; 此外, 还应告知用户: 他并未被拒绝, 只是耗尽了对方主机的资源。

也可以不单独创建一个控制命令, 而是利用 CLS 与 OVF 之间的相似性。可以设想在 CLS 命令中增加一个 8 位字段来定义其来源。但我们认为, 这种替代方案在概念上较为逊色, 实现上也更为困难。

如果溢出是相当罕见的事件, 就无需认真考虑。但我们并不认为情况会是这样, 而且我们进一步认为, 缺少对溢出的处理将是对用户的一种不必要的限制。