II. ホストのダウンと復旧

ホストがダウンした後、再起動を試みるときには重大な問題が生じうる。2つの場合が容易に区別できる。第一は「ソフト」クラッシュであり、システムはマシンがダウンする旨を事前に知らされており、事前回復手順を実行するのに十分な時間がある。もう一つは「ハード」クラッシュと呼べるもので、多くの場合システム障害の結果である。ほとんど警告は出ない。さらに重要なのは、回復後のマシンの状態がほとんど予測できないことである。

ハードクラッシュからホストが戻ってきたとき、ネットワークは未定義の状態にある。NCP のデータ構造は破壊されているか、無意味になっている可能性が非常に高い。ネットワークはそのホストが死んだと宣言している——しかし、それはデータ伝送を試みて拒否されたプロセスにしか伝わっていない。クラッシュしたホストにとって唯一の選択肢は、自分のテーブルの再初期化である。では、相手ホストにとっての選択肢は何か。

我々は、RESET（RST）と RESET REPLY（RSR）という2つの制御コマンドの追加を提案したい。それぞれ、パラメータを持たないオペコードだけから成る。RST を受信すると、ホストは送信ホストとのすべての接続を直ちに終了するが、CLS は一切発行しない。RST の受信者は、RST の発信者が生きていることも記録し、送信者に RSR をエコーとして返す。RSR を受信したホストは、そのエコーを返したホストが生きていると記録するはずである。（あるホストがダウンしていることを発見した際に、ホストが直ちに関係するテーブルエントリをすべてクローズすれば、RST の機能は部分的に模擬できる。）

こうして、ハードクラッシュの後には、すべての接続と接続要求が終了される。RST はまた、すべての相手ホストに我々が再び生きていることを知らせ、機能しているすべての NCP から RSR が受信される。ホスト生存テーブル（NWG/RFC #55 を参照）は容易に組み立てることができ、接続の確立を再開できる。

クラッシュ前に生成されたメッセージをまだ運んでいるかもしれないネットワークと、初期化された環境を持つ NCP とを同期させようとすると、関連する問題も次々と現れる。リンクのブロック解除やメッセージの廃棄などを行う機能が我々にはない——本提案ではこうした機能が必要になる。BBN とのさらなるやり取りで、これらの困難は解決されるはずである。

「ソフト」クラッシュに伴う問題は、それほど差し迫ってはいないが、より洗練された（すなわち複雑な）解決策を必要とする。ネットワークでの予備的な実験から、優れた初期化と回復のプロトコルのほうがはるかに必要だと示されている。

ここに示したアイデアの多くは、Steve Crocker と Jon Postel との会話を通じて芽生え、あるいは形になった。また、我々の最近の文書の多くの前身となった擬似 Algol プログラムの開発を支えるために多大な努力を注いでくれた、UCLA の Jim Balter と Charles Kline の支援にも謝意を表したい。

注: この RFC は、オンライン RFC アーカイブに収録するため、Katsunori Tanaka により 1998年2月に機械可読形式へ変換された。