メインコンテンツまでスキップ

I. エラーとオーバーフロー

NWG/RFC #48 の議論に沿って、我々は2種類のエラーを区別すべきだと考えた。一つは、2つの送信ソケットから成る RFC のような、真のエラーである。この種のエラーは、壊れた NCP でしか発生しない。ハードウェアやソフトウェアのバグがなければ、このような事象は決して起こるはずがない。こうした事象を検出した際の正しい応答は、NWG/RFC #54 の ERR コマンドの説明で概説されている。

もう一つの「エラー」は、有限なシステム資源が枯渇することによって生じるオーバーフロー状態である。RFC を受信したものの、必要なテーブルやキューを作成する余地がない場合に、オーバーフロー状態は起こりうる。これは真のエラーではない。誰も誤ったことをしていない（システム設計者が十分なテーブル領域などを用意しなかった点を除けば、である）という意味で。さらに、回復手順は明確に定義でき、単に後日その要求を繰り返すだけでよい。したがって、オーバーフロー状態は真のエラーと区別すべきだと我々は考える。

NWG/RFC #54 では、オーバーフロー状態は、接続が拒否されたかのように CLS を返すことで報告されていた。この手順は必要な機能を果たし、接続を正しい状態に残すが、接続を開始したユーザーには誤った情報が伝わる。実際にはそうでなかったのに、相手プロセスに拒否されたと思い込まされてしまう。ある種のアルゴリズムでは、この違いは決定的に重要である。

エラー状態をさらに定義するにあたり、我々は、エラーの原因となったものを示すのに加えて、なぜエラーが検出されたのかを示すことが有益であろうと考えた。NWG/RFC #55 で述べた擬似 Algol プログラムを書く際に、我々は9種類のエラー型を区別した（以下に列挙）。そこで、ERR メッセージを拡張して、オペコードの後に8ビットのフィールドを設け、エラーの型を指定できるようにすることを提案したい。その後には、これまでと同様に長さフィールドとテキストフィールドが続く。以下のエラー型を提案する；

  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 メッセージの形式と似ている。ソケット番号は32ビット長で、拒否されようとしている RFC 内のソケット番号に対応する。受信した OVF の意味論は、受信した CLS の意味論と同一であるべきである。さらに、ユーザーは、拒否されたのではなく、相手ホストの資源を使い果たしたのだと知らされるべきである。

独立した制御コマンドを作る代案としては、CLS と OVF の類似性に着目するという考え方がある。CLS コマンドに8ビットのフィールドを追加して、その由来を定義することも考えられる。しかし我々は、この代案は概念的に劣り、実装も実際上より難しいと考える。

オーバーフローが大幅に珍しい出来事であれば、深刻に検討する必要はない。しかし我々はそうはならないと考え、さらに、オーバーフローの報告手段がないことはユーザーにとって不要な制約になると考えている。