付録: 一つの適用例
現在存在する資源共有コンピュータネットワークはただ一つ、前述の ARPA ネットワークだけである。本付録では、本覚書で述べたシステムを ARPA ネットワークに適用できることを示したい。ARPA ネットワーク内のプロセス間通信については、かなりの量の作業がすでにある。この作業は、ほとんど別個のいくつかの部分から成る。ホスト/IMP プロトコル、IMP/IMP プロトコル、そしてホスト/ホストプロトコルである。以下の議論では、これらの作業に読者が通じていることを前提とする。[参考文献 [1][3][4][10][11]、Specifications for the Inter-connection of a Host to an IMP, BBN Report No. 1822、および ARPA Network Working Group Notes #37, 38, 39, 42, 44, 46, 47, 48, 49, 50, 54, 55, 56, 57, 56, 59 を参照されたい。]
ARPA ネットワークでは、あるサイトから別のサイトへビットを正しく伝送する責任は IMP だけが負っている。プロセス間の接続を作る責任はホストだけが負っている。流量制御とメッセージの順序づけについては、ホストと IMP の両方が関与し、少しずつ責任を担っている。私が述べたプロセス間通信システムを適用すると、私は責任の配分を変えることになる。IMP は引き続き、あるサイトから別のサイトへビットを正しく運び続けるが、ネットワークコントローラも IMP 内に存在し、流量制御はホスト内で走るプロセスの手に完全に委ねられる。ただし、彼らは IMP が提供する機構を使うかもしれない。
IMP は、ホストに対して、SEND、RECEIVE、SEND FROM ANY、RECEIVE ANY、UNIQUE の各操作を少し形を変えて提供し、さらに必要に応じて SEND ポートの移転を含め、ランデブーテーブルを維持する。
おそらく最も簡単なのは、この5つの操作をもう一度順にたどることである。
SEND. ホストは IMP に、SEND ポート番号、RECEIVE ポート番号、ランデブーサイト、そしてバッファ指定=20 (例えば始点と終点、先頭と長さ) を渡す。その SEND はランデブーサイトへ送られる。通常はローカルサイトである。対応する RECEIVE が到着すると、ホストは今到着した受信メッセージの RECEIVE ポートを知らされる。このポート番号は、その SEND を発したプロセスを識別するのに十分である。ただし、特定のタイムシェアリングシステムでは、このポート番号を有用な内部プロセス識別子へ対応づける内部表を維持しなければならないかもしれない。同時に IMP は、データバッファの特定の塊をホストに要求し始める。これらの塊は、IMP の RFNM 制御が許す範囲で宛先へ送り出される。RFNM が長い間届かなければ (ネットワーク内でメッセージが失われたことを意味する)、ホストは同じデータの塊を再び要求される [これは同時に、メッセージを IMP ネットワークが完全に捨て去ることも可能にする。それが何かの役に立つ場合には]、しかしこの時点でホストには伝送を中止する選択肢がある。伝送が行われている間、ホストは IMP に他の SEND を含む他の操作の実行を依頼できる。すでに伝送中の一対のポートに対する2度目の SEND は記録され、その SEND は最初の伝送が完了するとすぐに有効になる。3度目の同一の SEND は、ホストへのエラーメッセージとなる。SEND がタイムアウトした場合も、エラーが返される。
RECEIVE. ホストは IMP に、SEND ポート、RECEIVE ポート、ランデブーサイト、そしてバッファ記述を渡す。その RECEIVE メッセージはランデブーサイトへ送られる。ある伝送の塊がその RECEIVE ポート宛てに到着すると、それらは RECEIVE ポート番号 (おそらく SEND ポート番号も) とともにホストへ渡され、同時にホストは、データを自分の入力バッファのどこに置くべきかの指示を受け取る。SEND バッファの最後の部分がホストへ渡されると、それはそれに応じて印され、ホストはそれを検出できる。同じポート対に対する2度目の RECEIVE は許される。3度目はホストへのエラーメッセージとなる。本段落と前段落で述べた機構により、一対のプロセスは常に、進行中の伝送と保留中の次の伝送の両方をもつことができる。したがって効率はまったく損なわれない。一方で、各伝送の前には指定されたバッファへの RECEIVE が必要であり、これによって完全な流量制御が提供される。(RECEIVE メッセージが、ランデブーサイトへ向かう途中でネットワーク帯域の一部を確保することも考えられる。)
RECEIVE ANY. ホストは IMP に RECEIVE ポートとバッファ記述子を渡す。これは RECEIVE と同じように働くが、ローカルサイトをランデブーサイトとみなす。
SEND FROM ANY. ホストは IMP に RECEIVE ポートと SEND ポート、宛先サイト、バッファ記述子を渡す。IMP はできるだけ速くそのバッファを要求して伝送する。存在しないポートに対する SEND FROM ANY は、宛先サイトで破棄される。
RFNM は、確認応答が現在パケットに結びつけられているのとちょうど同じように、ある特定のバッファの塊の伝送に結びつけられ、同じ役割を果たす。ホストが、上述したように IMP がホストにバッファの塊をどこに置くべきかを告げる方式で、IMP がホスト内でバッファを再組み立てすることを許すなら、単一のバッファの塊を並行して伝送でき、同時に複数の RFNM を未完了にできる。パケットの再組み立ては依然として IMP 内で行われる。
IMP が提供しなければならない最後の操作がある。UNIQUE 操作である。一意の番号を維持する方法は多くあり、ここでは3つを示す。第一の可能性は、ホストが最初に IMP に一意の番号を要求し、その後、ホストが利用できるあらゆる手段を用いて、現在ローカルプロセスとプログラムが所有している一意の番号の完全性を保証する、というものである。この場合 IMP は、一意の番号をあるホストから別のホストへ送る方法を提供し、その番号の新しいサイトでの同一性を保証することになる。
第二の方法は、一意の番号をそれを使っているプロセスへそのまま与え、一意の番号を保全するのはプロセスの非悪意な振る舞いに依存する、あるいは万一事故が起きた場合は、伝送を開始するのに必要な2つのパスワード (SEND ポートと RECEIVE ポート) に依存する、というものである。一意の番号が順序どおりでない仕方で配られ、しかもそれなりの長さ (例えば32ビット) であれば、危険はほとんどない。
最後の方法では、ポート番号にユーザ識別が含められ、個々のタイムシェアリングシステムがこれらの識別ビットの完全性を保証する。こうして、あるプロセスは、正しいポートが自分に送信していることを確信できないまでも、正しい利用者のあるポートが送信していることは確信できる。これが W. Crowther によって提案された、いわゆる仮想ネット (virtual net) の概念である [3]。
雑多な内容。これらの操作を IMP に置くことは、ホスト/ホストプロトコルのプログラムを1度だけ書けばよいことを意味する。現在 ARPA ネットワークで行われているように何度も書く必要はない。IMP は、通信サブネットの輻輳問題を緩和するのに必要と思われる場合、特定のホストの伝送を止めることができる (しばらく次の塊を要求しないことによって)。また IMP は、RECEIVE がある特定の別のサイトへ届くのに要するおよその時間を知っているかもしれず、あるプロセス宛てのメッセージが到着する直前になったら、そのことをホストに警告してそのプロセスを起こさせることができる。
Note: This RFC was put into machine readable form for entry into the online RFC archives by Katsunori Tanaka 4/99.