遠隔手続き呼び出し

なんかもう思いっきり手抜き。

これからスパコン勉強会のテキスト翻訳〜

\section{遠隔手続き呼び出し}
\subsection{問題の領域}
RPC(Remote Procedure Call)は透過でなければならない. つまりプログラマがどのライブラリ手続きが局所的で,どの手続きが遠隔であるかを意識してはならない. しかしRPCにおいて透過性を保とうとした場合,広域変数を処理できないという問題や,手続きに与えられる変数の大きさがわからないという問題がある.


またRPCによるコマンドラインパイプライン処理をクライアントサーバモデルで考えた場合,パイプラインで接続されているいずれかのプログラムが,サーバとして働かなければならない. しかしプログラムはクライアントとして動作するように設計されているので,クライアントサーバモデルではうまく動かない. この問題に対する解決方法として,読み取り駆動型と書き込み駆動型とが考えられるが,この場合も最初に要求を出すクライアントがいないのでうまく動くことができない.

\section{グループ通信}
\subsection{グループ通信の概要}
グループとは共に動作するプロセスの集まりで,グループ通信とは,メッセージをグループ自体へ送信する場合にグループの全てのメンバーがそれを受信するというものである.グループを用いるのは,プロセスがプロセスの集まりを単一の抽象プロセスとして処理できるようにするためである.

グループ通信の通信方法としてグループ毎にネットワークアドレスを与えて,そのアドレスにパケットを送ることで,そのネットワークに参加しているマシンに自動的に配送される多重通信がある. 多重通信が使えないネットワークの場合,パケットを全てのマシンに配送し,マシンがソフトウェアで自分あてのパケットかどうかを調べる同胞通信がある. 最後にどちらも使えない場合でも送信側からグループの書くメンバーに対して個々にパケットを送ることでグループを実現する方法もある. このように単一の送信側から単一の受信側へのメッセージの送信をユニキャストという.

\subsection{設計上の問題}
\subsubsection{閉じたグループと開かれたグループ}
誰が誰に送信できるかによって,グループ通信を扱うシステムを閉じたグループと,開かれたグループの2つに分けることができる. 閉じたグループではグループのメンバーのみがグループに送信することができ,開かれたグループは全てのプロセスがどのグループへも送信することができる. 通常どちらのグループを使用するかは最初にプロセスを扱うときの理由を元に決定される.
%並列処理に用いられるようなプロセスは,外部の世界との相互作用がないために閉じたグループを形成する.

\subsubsection{同一レベルグループと階層化グループ}
グループ内に階層構造があるかどうかによって,同一レベルグループと階層化グループの2つに分けることができる. 同一レベルグループは全てのプロセスが平等で,調停者がいない. そのために一つのプロセスがクラッシュしても全体は問題なく動き続けることが可能となるが,何かを決定するときに採決しなければならないので複雑になる. 階層化グループはあるプロセスが調停者で,他の全てのプロセスが作業者となる. そのために調停者が失われるとグループ全体が停止してしまうことになるが,決定は調停者のみで行うことができる.

\subsubsection{グループメンバーの資格}
プロセスがグループに参加したり脱会したりするための方法として,グループサーバを用意する方法がある. この方法は簡単であるが,グループサーバがクラッシュするとグループ管理機構がなくなるという問題がある.
反対の方法として,開かれたグループのメンバー全てに対して部外者がその存在を通知してグループに参加し,また脱会を通知してグループから脱会するという方法である. 閉じたグループの場合でもそれに類する方法は必要である. この方法は簡単であるが,メンバーがクラッシュした場合,退会が通知されないという問題と,入会と退会は送信メッセージと同期を取らなければならないという問題がある.
%メンバーが入会した瞬間からグループに送信されるメッセージを受信して,退会と同時にグループからのメッセージを受け取ってはならないし送信してもならない.

\subsubsection{グループアドレスの指定}
プロセスにアドレス指定が必要なように,グループにもアドレス指定をしなければならない.
1つ目の方法として,グループにアドレスを与えて,多重通信,同報通信,ユニキャストによって通信する方法である. いずれの方法の場合もプロセスはグループアドレスにメッセージを送るだけで,メッセージが全てのメンバーへ送信される. メッセージがどのように送られるかはオペレーティングシステム次第で,送信側はそれを意識しない. 2つ目の方法として,送信側に全ての宛先のリストを提供させる方法がある.この場合プロセスはどのグループメンバーか正確に意識し,グループメンバーが変更された場合はメンバーリストを更新しなければならない. 3つめの方法として,述語アドレス指定というものがある.これはメッセージの送信は前記のいずれかの方法を使用するが,そこに受信側のマシン番号や局所変数その他の要因を示す述語を含めたものである. この方法を用いると例えば4M以上の空きメモリがあるマシンにのみメッセージを送ると言うようなことができる.

\subsubsection{送信基本機能と受信基本機能}
理想的には,2地点間通信とグループ通信を融合させて一揃いの基本機能とするべきである. しかし通常のユーザ通信機構がRPCである場合には,RPCが1対1の通信であるのに対し,グループ通信が1対nであるために,RPCとグループ通信を融合させることは困難である.

ここで2つの通信方式を統合したい場合の方法を示す,まずメッセージを送信するためのsendの1つ目の引数が宛先を示し,2つ目の引数がメッセージを示す. 宛先がグループアドレスの場合はメッセージはグループ全てのメンバーに送信される. receiveはメッセージをうけとる意志を示し,2地点間もしくはグループのメッセージが到着したときに完了する. この方法では通信は一方向となり,応答は単独でメッセージに依存しない.


\subsubsection{不可分}
グループ通信は,メッセージが全てのグループメンバに届かなければならず,一部だけ届いたり届かなかったりと言う状況は許されない.このような配送の性質を不可分,もしくは不可分同報通信という. 不可分は一部だけメッセージが届かなかったときの処理を考えなくていいので,分散システムでのでのプログラミングは容易になる.

不可分同報通信の実現方法としては,メッセージの受信時に確認応答を宛先から送信させる方法がある. この場合マシンがクラッシュしない限りうまく行く.
もうひとつの方法として,送信側はグループ全てのメンバーにメッセージを送信し,タイマを設定して必要に応じてメッセージの再送信を行う. グループ内のプロセスがメッセージを受信すると,まだ見ていないメッセージであれば,グループ全てのメンバーにメッセージを送信する. このときもタイマを設定して必要に応じてメッセージの再送信を行う. すでに受信したメッセージであればプロセスはメッセージを破棄する. こうするとクラッシュしたマシンの台数や紛失したパケットに関係なく全てのメンバーがメッセージを受信できる.


\end{document}