遠隔プロセス間のプロセス間通信
前節で述べたシステムは、地理的に異なる場所にあるプロセス同士、例えば計算機ネットワーク内のプロセス同士のプロセス間通信を可能にするよう、容易に一般化できる。
まず、星形の各点に分散したプロセスの単純な構成を考える。星形の各点には自律的なタイムシェアリングシステムがあり、星形の中心にはネットワークコントローラと呼ばれるかなり大きく賢い計算機システムが存在する。この中心システムではどのプロセスも走らせることができないが、むしろネットワーク内の各タイムシェアリングシステムのモニタの拡張と考えられるべきである。
読者には明らかであろうが、ネットワークコントローラが SEND、RECEIVE、SEND FROM ANY、RECEIVE ANY、UNIQUE の各操作を実行でき、ネットワーク内のすべてのタイムシェアリングシステムのすべてのモニタがこれらの操作を自ら実行せず、代わりにネットワークコントローラに実行を依頼するのであれば、遠隔プロセス間のプロセス間通信の問題は解決したことになる。それ以上の変更は必要ない。
ネットワークコントローラの存在を仮定してもすべてが引き続き機能するのは、ネットワークコントローラが、どの RECEIVE が実行されどの SEND が実行されたかを追跡し、モデルタイムシェアリングシステムでモニタが行ったのとちょうど同じようにそれらを対応づけられるからである。ネットワーク全体にわたるポート番号付けの方式も可能であり、その場合ネットワークコントローラは、ある特定のポートが特定の時点でどこに (すなわちどのサイトに) あるかを知っている。
次に、共通の中心点が存在しない、より複雑なネットワークを考える。その場合、ネットワークコントローラが担う機能をネットワークの各ノードに分散させなければならない。本節の残りで、星形のネットワークコントローラが担う機能を多数のネットワークサイトに効率よく便利に分散させつつ、それでも遠隔プロセス間の一般的なプロセス間通信を可能にできることを示す。
分散ネットワークで使えるようにするには、上述の4つの SEND/RECEIVE 操作のそれぞれに変更を加えなければならない。RECEIVE には、その RECEIVE を送る先のサイトを指定するパラメータが追加される。SEND FROM ANY と SEND には、その SEND を送る先のサイトを指定するパラメータが追加されるが、通常これはローカルサイトである。RECEIVE と RECEIVE ANY の両方には、受信したメッセージの発信元サイトを取得する仕組みが追加される。こうして、RECEIVE が実行されると、その RECEIVE は指定されたサイト (遠隔サイトであることもある) へ送られる。同時に、SEND が同じサイトへ送られる。通常それは、その SEND を実行するプロセスのローカルサイトである。このサイトはランデブーサイトと呼ばれ、そこで RECEIVE が適切な SEND と対応づけられ、メッセージの伝送がその RECEIVE の発信元のサイトへ向けて行われることが許される。
RECEIVE ANY は自分の発信元サイトを決して離れず、そこに SEND FROM ANY の必要性がある。RECEIVE ANY ポートにメッセージを送り、そのメッセージが送信元サイトで RECEIVE を待ってブロックされないようにできなければならない。もちろん、SEND/RECEIVE のランデブーが RECEIVE サイトで行われるようにシステムを構成し、SEND FROM ANY 操作をなくすこともできただろうが、私の判断では、通常の SEND 伝送を発信元サイトでブロックできる能力は、増える複雑さを十分に補って余りある。
各サイトのどこかにランデブーテーブルが保持されている。この表には、そのサイトで受信した未対応の SEND または RECEIVE ごとの項目と、そのサイトで与えられたすべての RECEIVE ANY の項目が入っている。対応する SEND/RECEIVE の組は、対応が成立するとすぐに、あるいはおそらく伝送が完了したときに、表から消去される。モデルタイムシェアリングシステムで保持されていた同様の表と同様に、長すぎる間対応づけられなかった SEND と RECEIVE の項目はタイムアウトし、発信元に通知される。RECEIVE ANY の項目は、それを満たすメッセージが到着したときに表から消去される。
ネットワークコントローラの機能を分散させるのに必要な最後の変更は、各サイトに一意の番号の一部を与え、それをそのサイトの UNIQUE 操作で配布させることである。この話題は以下でさらに論じる。
分散ネットワークコントローラがどのように働くかを読者に明らかにするため、以下に例を示す。どのプロセスがポート番号を選ぶかなどの細部は単なる例示であり、システムの一部として規定された標準ではない。
ネットワークに2つのサイト K と L があるとしよう。サイト K のプロセス A が、サイト L のプロセス B と通信したいと考えている。プロセス B はポート M に RECEIVE ANY を保留している。
SITE K SITE L
________ ________
/ \ / \
/ \ / \
/ \ / \
| Process A | | Process B |
| | | |
| | | |
\ / \ /
\ / \ port M /
\________/ \____^___/
|
RECEIVE ANY
幸いなことに、プロセス A はサイト L にポート M が存在することを知っており、SEND FROM ANY 操作を使ってポート N からポート M へメッセージを送る。そのメッセージには2つのポート番号と、プロセス B がポート Q からポート P へプロセス A にメッセージを送るための指示が含まれている。サイト K のサイト番号が、そのメッセージの SEND ポート N とともにこのメッセージに付加される。
SITE K SITE L
________ ________
/ \ / \
/ \ / \
/ \ / \
| Process A | | Process B |
| | | |
| | | |
\ / \ /
\ port N /--->SEND FROM --->\ port M /
\________/ ANY \________/
to port M, site L
containing K, N, P, & Q
プロセス A は今度は、ポート Q からポート P へ RECEIVE を実行する。プロセス A はランデブーサイトとしてサイト L を指定する。
SITE K SITE L
________ R ________
/ \ e / \
/ \ n T/ \
/ \ d a \
| | e b Process B |
| Process A | z l |
| | v e |
\ / o \ /
\ port P / RECEIVE ---> u \ /
\________/ MESSAGE s \________/
to site L
containing P, Q, & K
RECEIVE メッセージがサイト K からサイト L へ送られ、サイト L のランデブーテーブルに登録される。別の時点で、プロセス B がポート Q からポート P へ SEND を実行し、ランデブーサイトとしてサイト L を指定する。
SITE K SITE L
________ R ________
/ \ e / \
/ \ n T/ \
/ \ d a \
| | e b Process B |
| Process A | z l |
| | v e |
\ / o \ /
\ port P / u <--- port Q /
\________/ SEND s \________/
to site L
containing P & Q
ランデブーが成立し、ランデブーテーブルの項目が消去され、サイト K のポート P への伝送が行われる。SEND サイトの番号 (さらには SEND ポート番号も) が、受信プロセスの参考のために伝送のメッセージに付加される。
SITE K SITE L
________ ________
/ \ / \
/ \ / \
/ \ / \
| Process A | | Process B |
| | | |
| | | |
\ port P / \ port Q /
\ / <---- transmission <---- \ /
\________/ to port T, site K \________/
containing data and L
プロセス B は同時に、ポート M でポート N からの RECEIVE を実行したいと思うかもしれない。
このシステムでサイト間を移動する重要な制御メッセージはただ一つだけであり、それは [3] でホスト/ホストプロトコルメッセージと呼ばれている種類のメッセージであることに注意されたい。この制御メッセージが RECEIVE メッセージである。他に可能なサイト間制御メッセージが2つある。RECEIVE や SEND がタイムアウトしたときに発信元サイトへ送られるエラーメッセージと、ランデブーサイトが SEND サイトでないまれな場合の SEND メッセージである。
もちろん、ポート間のメッセージにも標準的な形式がなければならない。例えば次のようなものである。
+-----------------+ +-----------------+ +-----------------+
| rendezvous site | | destination site| | source site |
+-----------------+ +-----------------+ +-----------------+
| RECEIVE port | | RECEIVE port | | RECEIVE port |
+-----------------+ +-----------------+ +-----------------+
| SEND port | | SEND port | | SEND port |
+-----------------+ +-----------------+ +-----------------+
| | | source port | | |
| | +-----------------+ | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| data | | data | | data |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
+-----------------+ +-----------------+ +-----------------+
transmitted transmitted received
by SEND by Network by RECEIVE
process Controller process
注: SEND FROM ANY メッセージの場合、ランデブーサイトは宛先サイトである。
モデルタイムシェアリングシステムでは、ポートをプロセスからプロセスへ渡すことができた。分散ネットワークコントローラでもこれは依然として可能である。[ポート受け渡しの有用性に納得していない読者は、[11] の再接続に関する節を読まれたい。]
あるプロセスから別のプロセスへメッセージを送るには、ポート N からポート M への SEND と、ポート M でポート N からの RECEIVE が、通常は SEND サイトでランデブーしなければならないことを思い出されたい。両方のプロセスは、自分がランデブーサイトだと考えている場所を記録し、そのサイトを該当する操作のパラメータとして与える。RECEIVE を行うプロセスは自分が SEND サイトだと考え、SEND を行うプロセスも通常は自分が SEND サイトだと考えている。SEND と RECEIVE がランデブーすると、伝送は RECEIVE の発信元へ送られ、ランデブーテーブルの項目は消去され、N から M へのさらなる伝送のたびに再び設定しなければならないので、RECEIVE ポートを移すのは容易である。あるプロセスがポート番号とランデブーサイト番号の両方を、別のサイトにある新しいプロセスへ送り、そのプロセスがこれら同じ古いポート番号とランデブーサイト指定を使って RECEIVE を実行すれば、送信側は受信側が移ったことに決して気づかない。SEND ポートを移すのはもう少し難しい。しかしそれが起きた場合、ある SEND に使われ続けてきた一対のポート番号と元のランデブーサイト番号が新しいサイトへ渡される。新しい SEND サイトのプロセスは、そのサイトからの最初の SEND で元のランデブーサイトを指定する。RECEIVE を行うプロセスも依然としてランデブーサイトは元のサイトだと考えているので、SEND と RECEIVE は元のサイトで出会う。出会うと、そのサイトのテーブルの項目が消去され、SEND メッセージのランデブーサイト番号がその SEND メッセージを発したサイトに変更され、SEND と RECEIVE の両方のメッセージが新しい SEND サイトへ送られる。それは、最初からそこを宛先としていたかのようである。その後 SEND と RECEIVE は新しいランデブーサイトで再び出会い、ポートが一度も移っていないかのように伝送を続けられる。すべての伝送が発信元サイト番号を含むので、以降の RECEIVE は新しいランデブーサイトへ送られる。この特別な操作が必要であることは、SEND メッセージが、それを発していないサイトで受信されたことから分かる。すべてがこれほど容易に変えられるのは、切断して移すべき恒久的な接続が存在しないからである。かつて ARPA ネットワークで提案された再接続方式 [10][11] とは異なり、つまりここで述べるシステムでは接続は一時的にしか存在せず、したがって、ある時点で互いのポート番号を知り、それぞれがどこにいるかについて何らかの手がかりをもつ任意の一対のプロセスの間で作り直すことができるのである。
もちろん、これらすべては、プロセスが互いにメッセージをやり取りして、起こりうる移転と新しいサイト番号を通知し合うことによって行うこともできた。