3. 遠隔プロセス間のプロセス間通信システム
前節で述べた IPC は、地理的に異なる場所にあるプロセス同士のプロセス間通信 —— たとえばコンピュータネットワーク内での通信 —— を許すよう容易に一般化される。
まず、プロセスが星形の各点に分散している単純な構成を考える。星形の各点には自律的なオペレーティングシステム<5>がある。星形の中心には、ネットワーク制御装置 (Network Controller) と呼ばれるかなり大きく賢いコンピュータシステムが存在する。この中心システムではプロセスは実行できず、むしろネットワーク内の各オペレーティングシステムのモニタの拡張と考えるべきである。
ネットワーク制御装置が SEND, RECEIVE, SEND FROM ANY, RECEIVE ANY, UNIQUE の各操作を実行でき、かつネットワーク内のすべてのタイムシェアリングシステムのすべてのモニタがこれらの操作を自ら実行せず、ネットワーク制御装置に代行を求めるのであれば、遠隔プロセス間のプロセス間通信の問題は解決する。ネットワーク制御装置が、どの RECEIVE が実行されどの SEND が実行されたかを把握し、モデルのタイムシェアリングシステムでモニタが行ったのとちょうど同じようにそれらを突き合わせられるので、それ以上の変更は必要ない。ネットワーク制御装置が特定のポートが特定の時点でどこ (すなわちどのサイト) にあるかを知る、ネットワーク全体のポート番号付け方式も可能である。
次に、共通の中心点が存在せず、そのためにネットワーク制御装置が果たす機能をネットワークの各ノードに分散させねばならない、より複雑なネットワークを考える。本節の残りで、星形ネットワーク制御装置が果たす機能を多数のネットワークサイトに効率よく便利に分散させ、しかも遠隔プロセス間の一般的なプロセス間通信を可能にできることを示す。
分散型ネットワーク制御装置で使えるようにするため、上述の四つの SEND/RECEIVE 操作のそれぞれにいくつか変更を加えねばならない。RECEIVE には、その RECEIVE を送る先のサイトを指定するパラメータが追加される。SEND FROM ANY と SEND のメッセージには、その SEND を送る先のサイトが追加されるが、通常はローカルサイトである。RECEIVE と RECEIVE ANY はどちらも、受け取ったメッセージの送信元サイトを得るための手段が追加される。したがって、RECEIVE が実行されると、その RECEIVE は指定されたサイト —— 遠隔サイトであることもある —— へ送られる。同時に、SEND が同じサイト —— 通常は SEND を実行するプロセスのローカルサイト —— へ送られる。このサイトは会合サイト (rendezvous site) と呼ばれ、そこで RECEIVE が適切な SEND と突き合わされ、メッセージの伝送が 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 操作によって配布させることである。この話題については後述する。
分散型ネットワーク制御装置がどのように働くかを読者に明らかにするため、例を挙げる。どのプロセスがポート番号を選ぶかといった細部はあくまで例示であり、IPC の一部として規定される標準ではない。
ネットワーク内の二つのサイト K と L について、サイト K のプロセス A がサイト L のプロセス B と通信したいと望んでいると仮定する。プロセス B はポート M に未処理の RECEIVE ANY を持っている。
SITE K SITE L
______ ______
/ \ / \
/ \ / \
/ \ / \
/ \ / \
| | | |
| Process A | | Process B |
| | | |
\ / \ /
\ / RECEIVE--> port M /
\ / ANY \ /
\______/ \______/
プロセス A は幸いなことにサイト L にポート M が存在することを知っており、SEND FROM ANY 操作を用いてポート N からポート M へメッセージを送る。このメッセージには二つのポート番号と、プロセス B がプロセス A あてのメッセージをポート Q からポート P へ SEND すべき旨の指示が含まれている。サイト K のサイト番号が、このメッセージの SEND ポート N とともにこのメッセージに付加される。
SITE K SITE L
______ ______
/ \ / \
/ \ / \
/ \ / \
/ \ / \
| | | |
| Process A | | Process B |
| | | |
\ port N / \ port M /
\ /--->SEND FROM --->\ /
\ / ANY \ /
\______/ \______/
to port M, site L
containing K,N,P, & Q
プロセス A はここでポート Q からポート P への RECEIVE を実行する。プロセス A は会合サイトをサイト L と指定する。
SITE K SITE L
______ ______
/ \ / \
/ \ / \
/ \ Rendezvous/ \
/ \ table \
| | | |
| Process A | ^ | Process B |
| | | | |
\ port P / | \ /
\ / | \ /
\ / <--RECEIVE __/ \ /
\______/ MESSAGE \______/
to site L
containing P, Q, & K
RECEIVE メッセージがサイト K からサイト L へ送られ、サイト L の会合テーブルに登録される。別の時点で、プロセス B が会合サイトをサイト L と指定して、ポート Q からポート P への SEND を実行する。
SITE K SITE L
______ ______
/ \ / \
/ \ / \
/ \ Rendezvous/ \
/ \ table \
| | | |
| Process A | | Process B |
| | | |
\ port P / <--------- port Q /
\ / \ /
\ / SEND \ /
\______/ \______/
to site L
containing P & Q
会合が成立し、会合テーブルが消去され、サイト K のポート P への伝送が行われる。送信サイトの番号 (場合によっては SEND ポート番号も) が、受信プロセスの参考のためにその伝送の各メッセージに付加される。
SITE K SITE L
______ ______
/ \ / \
/ \ / \
/ \ / \
/ \ / \
| | | |
| Process A | | Process B |
| | | |
\ port P / \ port Q /
\ /<--transmission<--\ /
\ / \ /
\______/ to port P, site K \______/
containing data and L
プロセス B は同時に、ポート M においてポート N からの RECEIVE を実行したいと望むかもしれない。
このシステムでサイト間を移動する重要な制御メッセージはただ一つだけであり、それは [2] で Host/Host プロトコルメッセージと呼ばれている種類のメッセージであることに注意されたい。この制御メッセージが RECEIVE メッセージである。他にありうるサイト間制御メッセージは二つある: RECEIVE または SEND がタイムアウトしたときに発信元サイトへ送られるエラーメッセージと、会合サイトが SEND サイトでない稀な場合における SEND メッセージである。また、ポート間のメッセージには標準的な形式がなければならない。たとえば次のとおりである:
_________________ __________________ _____________
| rendezvous site | <6> | destination site | | source site |
|-----------------| |------------------| |-------------|
| RECEIVE port | | RECEIVE port | | RECEIVE port|
|-----------------| |------------------| |-------------|
| SEND port | | SEND port | | SEND port |
|-----------------| |------------------| |-------------|
| | | source site | | |
| | |------------------| | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| data | | data | | data |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
|_________________| |__________________| |_____________|
transmitted transmitted received
by SEND by Network by RECEIVE
process Controller process
モデルのタイムシェアリングシステムでは、ポートをプロセスからプロセスへ渡すことが可能であった。分散型ネットワーク制御装置でもこれは依然として可能である。
メッセージがあるプロセスから別のプロセスへ送られるためには、ポート N からポート M への SEND と、ポート N からポート M における RECEIVE とが、通常は SEND サイトで会合しなければならないことを思い出されたい。両方のプロセスは、自分が考える会合サイトがどこかを把握し、そのサイトを適切な操作のパラメータとして与える。RECEIVE を行うプロセスもまた、自分が SEND サイトだと考えている。SEND と RECEIVE が会合すると伝送は RECEIVE の送信元へ送られ、会合テーブルの項目は消去され、N から M へのそれ以降の伝送のたびに再設定されねばならないので、RECEIVE ポートを移動させるのは容易である。あるプロセスがポート番号と会合サイト番号の双方を、別のサイトの新しいプロセスへ送り、そのプロセスがこれら同じ古いポート番号と会合サイト指定を用いて RECEIVE を実行すれば、SEND 側は RECEIVE 側が移動したことを決して知らない。送信ポートを移動させるのは多少難しい。しかし、それが移動する場合には、SEND に使われてきたポート番号の対と元の会合サイト番号が新しいサイトへ渡される。新しい SEND サイトのプロセスは、新サイトからの最初の SEND において元の会合サイトを指定する。RECEIVE 側のプロセスも依然として会合サイトは古いサイトだと考えているので、SEND と RECEIVE は古いサイトで出会う。出会うとそのサイトのテーブルの項目が消去され、SEND と RECEIVE の両メッセージは、最初からそこを宛先としていたかのように新しい SEND サイトへ送られる。その後 SEND と RECEIVE は新しい会合サイトで再び出会い、ポートが一度も移動しなかったかのように伝送を続けられる。すべての伝送が送信元サイト番号を含むので、以降の RECEIVE は新しい会合サイトへ送られる。この特別な操作が必要であることは、SEND メッセージを発信していないサイトで SEND メッセージが受信されることから気づくことができる<7>。SEND ポートと RECEIVE ポートは同時に移動しうることに注意されたい。
もちろん、プロセスが起こりうる移動と新しいサイト番号を告げるメッセージをやり取りすれば、これらすべては同じようにして行うこともできた。
読者が思いつくかもしれない問題は、SEND と RECEIVE のバッファがどのように大きさを合わせられるかである。最も容易な解決策はすべてのバッファが共通の大きさを持つことを要求することだが、これは自律的なオペレーティングシステム内のプロセスが通信しようとする状況へ容易に拡張できないので受け入れられない。第二の解決策は、プロセスがバッファサイズを指定するメッセージを渡すことである。この解決策を採るなら、SEND プロセスから送られたデータのうち過剰で RECEIVE バッファに収まらないものは破棄され、RECEIVE プロセスに通知される。この解決策はその単純さゆえに大きな魅力がある。第三の解決策は、RECEIVE のバッファサイズを RECEIVE メッセージとともに SEND サイトへ渡し、データが送られすぎたときに SEND プロセスに通知する、あるいは RECEIVE バッファサイズを SEND プロセスへ伝えることである。この最後の方法なら、より小さな RECEIVE バッファサイズに合わせる必要がある場合に、SEND サイトのネットワーク制御装置が一つの SEND を二つ以上に分割することも可能になる。
プロセスが地理的に分散している場合、一意番号の維持も問題である。ここではこの問題への三つの解決策を提示する。第一の可能性は、自律的なオペレーティングシステムが当初ネットワーク制御装置に一意番号を求め、その後、オペレーティングシステムの使えるあらゆる手段を用いて、ローカルなプロセスやプログラムが現在所有する一意番号の完全性を保証することである。この場合、ネットワーク制御装置は、一意番号をあるサイトから別のサイトへ送る方法を提供し、その番号の同一性を新しいサイトで保証することになる。第二の方法は、単純に一意番号をそれを使っているプロセスに与え、一意番号を保全することをプロセスの非悪意的な振る舞いに期待するか、事故が起きた場合には伝送を開始するために必要な二つのパスワード (SEND と RECEIVE のポート番号) に期待することである。一意番号が非順序的に配られ、相応に長ければ (たとえば 32 ビット)、危険はほとんどない。最後の方法では、ポート番号に利用者識別が含められ、個々のオペレーティングシステムがこの識別ビットの完全性を保証する。したがってプロセスは、正しいポートが自分へ送信していることを確信できないまでも、正しい利用者のいずれかのポートが送信していることは確信できる。これが W. Crowther [2] によって提案された、いわゆる仮想網 (virtual net) 概念である。<8>
遠隔プロセスが通信したいと望むときに生じる第三の困難な問題は、遠隔プロセス間に高い帯域幅の接続を維持するという問題である。この問題の解決は、進行中の伝送の状態についてプロセスにかなりの情報を与えることにある。まず SEND プロセスを詳しく調べる。プロセスが SEND を実行すると、ネットワーク制御装置のローカル部分がその SEND を会合サイト —— 通常はローカルサイト —— へ渡す。未処理の SEND に対応する RECEIVE が到着すると、ネットワーク制御装置は指定された再開位置への割り込みを起こすことによって SEND プロセスに通知する。同時にネットワーク制御装置は SEND バッファを RECEIVE サイトへ送り始める。伝送が完了するとフラグが設定され、SEND プロセスはそれを検査できる。伝送が行われている間、プロセスはネットワーク制御装置に他の操作 —— 他の SEND を含む —— の実行を求めてよい。すでに伝送中のポート対に対する二度目の SEND は記録され、最初の伝送が完了すると同時にその SEND が有効になる。同一の SEND を三度目に実行すると、SEND を実行したプロセスへエラーメッセージが送られる。次に RECEIVE プロセスを詳しく調べる。プロセスが RECEIVE を実行すると、その RECEIVE は会合サイトへ送られる。この RECEIVE の結果として生じたデータが RECEIVE サイトに到着し始めると、RECEIVE プロセスは指定された再開位置への割り込みによって通知される。伝送が完了するとフラグが設定され、RECEIVE プロセスはそれを検査できる。同じポート対に対する二度目の RECEIVE は許される。三度目は RECEIVE プロセスへエラーメッセージをもたらす。したがって、一対のプロセスが常に、進行中の伝送と未処理の次の伝送の双方を持つことを可能にするだけの仕組みが揃っている。よって効率は損なわれない。一方で、各伝送の前には指定されたバッファへの RECEIVE がなければならず、したがって完全なフロー制御が引き続き提供される。