4. 潜在的な応用

現在存在する資源共有コンピュータネットワークはただ一つ、ARPA コンピュータネットワークだけである。本節では、本稿で述べたシステムの ARPA ネットワーク [2][5][9] への応用について論じる。

ARPA ネットワークは現在、合衆国全土に広がる十のサイトから成る。各サイトは、Host と呼ばれる一〜三 (将来的には四) の独立したコンピュータシステムと、IMP と呼ばれる一つの通信コンピュータシステムから成る。あるサイトのすべての Host はその IMP に直接接続されている。IMP 同士は 50 キロビットの電話回線で接続されている (はるかに高速な回線も可能性としてはある) が、各 IMP が接続される他の IMP は一〜五にすぎない。各 IMP は、Host が通信するための通信サブネットを提供する。データは、ネットワークメッセージ (network message) と呼ばれる任意の大きさのメッセージ (現在は約 8000 ビット) として通信サブネットを通って送られる。ネットワークメッセージが宛先サイトの IMP で受信されると、その IMP は RFNM と呼ばれる確認応答を送信元サイトへ送る。

ARPA ネットワーク向けのプロセス間通信システム (これを IPC for ARPA と呼ぼう) は現在、UCLA の S. Crocker を議長とするネットワークワーキンググループ (Network Working Group) によって設計されている。彼らの設計は通信サブネットによってある程度制約されている [5]<9>。私は IPC for ARPA と本稿で開発したものを一点ずつ比較したいのだが、そのような比較のためには、まず IPC for ARPA の現状をここでほとんど一から述べる必要がある。IPC for ARPA についての最新の情報は公開文献にほとんど現れていないからである [2]。また IPC for ARPA はかなり複雑で、それを記述する作業文書は現在数百ページに達しており、いかなる記述も長くなり本稿にはふさわしくない。<10> したがって、二つのシステムについて散発的な比較をいくつか述べるにとどめるが、その最初のものはこの段落に暗黙のうちに含まれている。

ARPA ネットワーク向けに開発されているプロセス間通信システムは、ほとんど別個のいくつかの部分から成る: Host/IMP プロトコル、IMP/IMP プロトコル、そして Host/Host プロトコルである。ビットをあるサイトから別のサイトへ正しく伝送する責任は IMP だけが負う。プロセス間の接続を確立する責任は Host だけが負う。Host と IMP の双方がフロー制御とメッセージの順序付けに関心を持ち、少しずつ責任を負う。本稿で述べたプロセス間通信システムを応用すると、私は責任の配分を変えることになる。IMP は依然としてビットをあるサイトから別のサイトへ正しく移動させ続けるが、ネットワーク制御装置も IMP 内に存在し、フロー制御は完全に Host 内で実行されるプロセスの手中にある —— ただし IMP が提供する仕組みを用いる。

各 IMP は、SEND, RECEIVE, SEND FROM ANY, RECEIVE ANY, UNIQUE の各操作をやや変更した形で Host に提供し、必要に応じて SEND ポートの移動を含む会合テーブルも維持する。これらの操作を IMP に置くことにより、Host/Host プロトコルプログラムは、現在 ARPA ネットワークで行われているように何度も書くのではなく、一度だけ書けばよくなる。五つの操作をもう一度順にたどることは、おそらく役に立つ。

SEND。Host は IMP に SEND ポート番号、RECEIVE ポート番号、会合サイト、バッファ指定 (たとえば始点と終点、あるいは先頭位置と長さ) を与える。SEND は会合サイトの IMP —— 通常はローカル IMP —— へ送られる。対応する RECEIVE がローカル IMP に到着すると、Host は今到着したメッセージの RECEIVE ポートを通知される。このポート番号は SEND を行ったプロセスを識別するのに十分であるが、特定のオペレーティングシステムではこのポート番号を有用な内部プロセス識別子へ写像する内部テーブルを保持する必要があるかもしれない。同時に IMP は Host に SEND バッファの特定の断片を要求し始め、それらの断片をネットワークメッセージとして宛先サイトへ送る。RFNM が長い間受信されなければ、ネットワークメッセージがネットワーク内で失われたことを意味するので、Host に同じデータが再び要求され、それが再送される。<11> バッファの最後の断片を除き、IMP が Host に要求する断片は、送信元 Host、IMP、宛先 Host の語長の公倍数である。これにより伝送途中の語境界合わせの問題を避けられる。

RECEIVE。Host は IMP に SEND ポート、RECEIVE ポート、会合サイト、バッファ記述を与える。RECEIVE メッセージは会合サイトへ送られる。伝送を構成するネットワークメッセージがその RECEIVE ポート向けに到着すると、それらは RECEIVE ポート番号 (場合によっては SEND ポート番号も) とともに Host へ渡され、Host にこのデータを入力バッファのどこに置くかの指示も与えられる。SEND バッファの最後のネットワークメッセージが Host へ渡されると、それに応じた印が付けられ、Host はそれによってそれを検知できる。(RECEIVE メッセージが、会合サイトへ向けてネットワークを横断する際に、ネットワーク帯域の一部を確保することも考えられよう。)

RECEIVE ANY。Host は IMP に RECEIVE ポートとバッファ記述子を与える。これは RECEIVE と同様に働くが、ローカルサイトが会合サイトであると仮定する。

SEND FROM ANY。Host は IMP に RECEIVE ポートと SEND ポート、宛先サイト、バッファ記述子を与える。IMP はできるだけ速くバッファを要求し伝送する。存在しないポートへの SEND FROM ANY は宛先サイトで破棄される。

ARPA ネットワークでは、IMP が Host に対して、伝送をネットワークメッセージに物理的に分割することを要求しており、単一の伝送の連続するメッセージは、前のメッセージの RFNM を受信するまで遅延させねばならない。ここで述べたシステムでは、RFNM が特定のバッファ断片の伝送に結び付いており、また Host が、各バッファ断片をどこに置くかを IMP が Host に告げることによって IMP に Host 内でのバッファの再組み立てを許すので、単一バッファの断片を並行するネットワークメッセージで伝送でき、複数の RFNM を同時に未処理にできる。これにより Host は、より自然な大きさの伝送と、単一伝送あたりより高い帯域幅を扱える。

さらなる効率のために、IMP は RECEIVE が特定の別サイトへ届くまでのおおよその時間を知り、あるプロセスあてのメッセージの到着が近いことをその直前に Host に知らせてそのプロセスを起こすよう促してもよい。