要約

  • Andrew G. Malisが1983年4月に書いた RFC 852 は、C/30型IMPにつながるARPANETホスト向けに短時間ブロックを規定した。従来は一通のためにホストからの後続入力が最長15秒止まり得た。短時間方式では、処理できないメッセージを最大2秒で拒否し、理由を付けたType 9の不完全転送応答を返す。
  • 早く窓口を開くと、提出順と受理順がずれる。先のメッセージが拒否されたことをホストが知る前に、後のものが受理され得る。同じ優先度・送信元・宛先で網が守る順序は受理順だった。提出順が不可欠な処理には、短時間方式を避けるかホスト側で順番を管理する判断が必要になる。

窓口に難しい書類が一枚来た。担当者は必要な資料を探しに行き、ほかの客の受付まで閉めてしまう。次の客は別件で、すぐ終わるかもしれない。それでも待たされる。RFC 852 が扱ったのは、ホストとインターフェース・メッセージ・プロセッサー、IMPとの間にあったこの窓口の問題だ。IMPは受け取ったメッセージを処理する資源が足りないと、同じホストからの後続をすべて止めた。必要な資源はメッセージの種類、長さ、宛先で違う。一件の難題が、無関係な仕事まで道連れにした。

従来の足止めは最長15秒。Malisの提案は、ホストが短い上限を選べるようにすることだった。2秒以内に処理資源が揃わなければ、IMPはそのメッセージを拒否し、理由を載せたType 9の応答を返す。IMP自身は資源を探し続ける。その間、ホストはほかのメッセージを出し、拒否されたものは後で再提出できる。早く返事が来ることと、元の一通が届くことは別の出来事である。窓口が開いたぶん、持ち帰った書類を扱う係が要る。

方式はメッセージのサブタイプで選ぶ。通常のType 0でサブタイプ0なら従来の制御機能を使い、最長15秒待つ。サブタイプ1なら同じ機能を使いながら、待ちは最大2秒になる。配送保証のない「uncontrolled」パケットにも、長い上限のサブタイプ3と短い上限の4があった。短いほうを選ぶホストはType 9応答を正しく処理しなければならない。対象はC/30型IMPで、ホスト側は1822と1822Lのどちらでもよい。報告書1822にあった旧来の非ブロック方式は実装されておらず、RFC 852は新たな案として実装者の意見を求めていた。

拒否理由は単なる飾りではない。新しいType 9の区分には、接続を作る時間、エンドツーエンドの流量制限、宛先IMPのバッファ不足、経路の混雑、送信元IMP自身の資源不足が並ぶ。ある宛先の接続が遅くても、別の接続は進めるかもしれない。送信元IMPのバッファや表の空きがなければ影響はずっと広い。「網が忙しい」だけでは、どの次の仕事を受け付けられるか分からない。

流量制限には数字がある。一つの接続で処理結果の返事を待てるメッセージは八通まで。九通目を出しても、そこには空きがない。長さにも境界があり、96ビットのリーダーを除いて1,008ビットを超えるメッセージには、宛先IMPでのバッファ予約が要る。予約が難しければ大きい一通は待つが、短い一通や別の接続宛ては通せる場合がある。九通目のためにホストの窓口を全部閉めるのは、仕事の割り振りとして乱暴だった。

ただし、客を先に通すと順番が変わる。ARPANETの順序付き配送は、優先度、送信元、宛先が同じメッセージをIMPが受理した順番に従った。ホストからの提出とIMPからの応答は同期しない。最初の一通の拒否がホストに届く前に、次の一通が受理されることがある。最初のものを再提出したとき、その順番は後ろになる。RFC 852は、網による順序付き配送が厳密に必要なら短時間ブロックを使わない、と明確に書いた。

短い待ち時間は、仕事を消したのではなく持ち場を変えた。IMPは一件の資源不足でホスト全体を止めず、何が足りないかを早く返す。ホストは別件を進められる。その代わり、拒否された一通をいつ戻し、後の一通との順序をどう守るかを決める。窓口は2秒で開く。番号札の管理はホストに移った。