分散システムにおけるプロセス 間通信 プロセス間通信 プロセス間通信

プロセス間通信
分散システムにおけるプロセス
間通信
„
プロセス間通信:分散システムの中核
„
メッセージパッシングに基づく
„
„
„
教科書2章
ネットワークの下位層で提供される低位のサービス
大規模分散システムの構築 Æ 高位の通信手段が必
要
4つの(高位の)通信モデル
„
„
„
„
遠隔手続き呼び出し(RPC)
遠隔メソッド実行 (RMI)
メッセージ指向ミドルウェア(MOM)
ストリームベース通信
1
2
プロセス間通信
„
プロセス間通信:分散システムの中核
„
„
„
ネットワークの下位層で提供される低位のサービス
大規模分散システムの構築 Æ 高位の通信手段が必
要
„
„
„
„
手続きsend,receiveなどの使用: アクセス透過性を達成でき
ない
遠隔手続き呼び出し(Remote Procedure Call, RPC)
を提案[Birrel and Nelson 1984]
„
4つの(高位の)通信モデル
„
分散システム: メッセージ送受信に基づくが...
„
メッセージパッシングに基づく
„
„
遠隔手続き呼び出し(RPC) (1/2)
マシンA上のプロセスがマシンB上の手続きを呼び出す
マシンA上のプロセスはマシンBに呼び出しパラメタの情報
を送信し、一旦停止
„ マシンB上で手続きは実行され、結果を呼び出したマシンA
上のプロセスに応答
„ 呼び出し結果を受け取ると、マシンA上のプロセスは実行を
再開
プログラマはメッセージ送受信を意識する必要がない
„
遠隔手続き呼び出し(RPC)
遠隔メソッド実行 (RMI)
メッセージ指向ミドルウェア(MOM)
ストリームベース通信
„
3
4
従来の手続き呼び出し (1/2)
遠隔手続き呼び出し(RPC) (2/2)
„ 課題:
„
„ 呼び出し側のプロセスと呼び出される側のプロセス: 異なるマシンの異なるアドレス空間で実行
„ パラメタと返り値: 異なるマシンでやり取り
例) count=read(fd,buf,nbytes); (C言語の例)
1. パラメタ(fd,buf,nbytes)をスタックに(逆順に)積む
2. 呼び出し先からの戻リアドレス(return address)をスタックに積
む
„ クラッシュや障害の対策
5
6
1
従来の手続き呼び出し (2/2)
パラメタ渡し
3. 手続きreadを呼ぶ(手続きが書いてあるアドレスにジャンプ)
4.手続き終了後、返り値countをレジスタに格納し、return
addressをスタックから取り除き、そのアドレスにジャンプ(呼
び出し元に戻る)
5. 呼び出し元は、スタックを元の状態に戻す
„
call-by-value(値渡し)
„
„
呼ばれた手続きにとって、パラメタ変数は単なる局所
変数(値の変更は呼んだ側の手続きに影響しない)
call-by-reference(参照渡し)
„
„
パラメタが格納されているアドレスを渡す
呼ばれた手続きから呼んだ側の変数を変更可能
7
8
RPCの実現方法
„
RPCのアイデア:
„
„
„
リモート手続き呼び出しを、できるだけローカルと同じように見
えるように(透過的に)する
„
リモート計算機上のread()手続きを呼び出す場合
„ ローカル側ではクライアントスタブ(client stub)を呼ぶ
„
„
システムコール・ライブラリコールの例
„
„
クライアントスタブ/サーバスタブ
プログラマは、単にプログラムに(例えば)read()手続きの呼び
出しを記述
リンカはライブラリからread()手続きのルーチンを取り出してオ
ブジェクトコードに追加 (プログラマは手続き呼び出し処理の
詳細は知らなくて良い)
パラメタをメッセージにまとめてリモート計算機に送信し、結果を受け取る
サーバにメッセージが到着すると、サーバ側のOSはそれをサー
バスタブ(server stub)に渡す。
„
リモートからの手続き呼び出し要求に従って、ローカルの手続きを呼ぶ
RPCも同様に実現
9
10
RPCの実行手順
RPCにおけるパラメタ渡し (1/3)
„
RPCでのパラメタ渡し
クライアントスタブがパラメタをメッセージに符号
化して送信し、サーバスタブがそれを復号化して
ローカル手続きに渡す
„ Æ それほど単純ではない
„
11
12
2
RPCにおけるパラメタ渡し (3/3) --マシンタイプの違いの吸収
RPCにおけるパラメタ渡し (2/3)
„
パラメタのメッセージへの符号化 = parameter marshaling(パラメタ・マーシャ
リング)
„
„
マシンのタイプが異なると Æ 文字コード
(ASCII,EBCDIC)やint ,floatなどのデータ表現が異な
る(big endian, little endianなど)
little endianからbig endianへの変換 Æ 上位バイトと
下位バイトの入れ替え
„ もしデータの型が文字列ならばこの変換をおこなっ
てはならない Æ データの型に関する情報も必要
13
14
RPCにおける参照渡し (2/3)
RPCにおける参照渡し (1/3)
„
ポインタなど参照をRPCでどうやって渡すか?
„ ローカルプロセスでのポインタの値: リモート
プロセス上では無意味
„ 一つの解決法: RPCでは全ての参照渡しを禁
止
„ 参照渡しは重要であり、この解決法は望まし
くない
„
もう一つの解決法:
read(fd,buf,nbytes)の例:
„ クライアントスタブは第2パラメタbufは文字配列
へのポインタであること、および、そのサイズを知っ
ている
„ クライアントスタブは配列bufの内容をすべてコピー
してサーバスタブに渡す
„ サーバスタブはbufをローカルメモリに展開し、手続
きを実行し、結果の配列bufをクライアントスタブにコ
ピーして返す
„
多くの場合うまく動作する
„
15
16
RPCにおける参照渡し (3/3)
„
„
パラメタ仕様とスタブ生成 (1/2)
より効率の良い解決法:
„ bufが入力パラメタか出力パラメタかが明らかな場
合 Æ クライアントでの配列のコピーとサーバでのコ
ピーのどちらかを省略可能
„ read()の例の場合: bufは入力パラメタÆ クライア
ントスタブはサーバに内容をコピーして渡す必要が
無い
単純な配列や構造体なら上記でOK
„ 任意の複雑なデータ構造(リスト、ツリーなど)は扱
えない
„
RPCでは手続き呼び出し側と呼び出され側でメッセージ形式
に関して取り決め(プロトコル)が必要
„
„
単純なデータ型(int,char,booleanなど)に関して、その表現に関する
取り決めも必要
メッセージ送受信に関する取り決めも必要
„
„
TCPをつかうか、UDPをつかうか、など
ポインタが指す値を動的にクライアントに要求できれば、全
体をコピーする必要はない
17
18
3
拡張RPCモデル (1/2)
パラメタ仕様とスタブ生成 (2/2)
„
クライアントスタブ/ サーバスタブの実装
„
アプリケーションとのインタフェースに関しても合意する必
要あり
インタフェース=クライアントから呼び出され、サーバに実
装されるべき手続きの集合
インタフェース仕様の記述方法:
„
„
„
非同期RPC(asynchronous RPC)
返り値が不要な手続き呼び出し Æ 手続き終了を待つのは無
駄
„
片方向RPC(one-way RPC)
„
リモート手続きを呼び出した後、返り値を待たずに次の仕
事をする
„
サーバは呼び出しリクエストの受理通知をすぐに返した後、
手続きを実行
„
1.クライアント・サーバを記述したプログラム言語で記述 (プログラム言
語依存)
2.標準化されたインタフェース記述言語(IDL:Interface Description
Language)で記述し、IDL記述からスタブを自動生成 (プログラム
言語非依存)
19
拡張RPCモデル (2/2)
„
20
例:Sun RPC
非同期RPC(asynchronous RPC)
返り値が必要だが、すぐには必要でない場合:
„
保留同期RPC(deferred synchronous RPC)
„
片方向RPCと同様に、クライアントは非同期RPCでサーバ
を呼び出した後、返り値を待たずに処理を続行
„
サーバは、返り値を別の非同期RPCを用いてクライアント
に返す
„
クライアントは割り込みによって返り値の受信を知り、受理
通知をサーバに返す
„
„
Sun RPC (ONC RPC) : RPCの実現方式の一つ
„
„
Sun Microsystems社のOpen Network Computing
グループで開発
多くのUNIXシステムで利用
„
„
„
„
„
NFS, NISなどはSun RPCを使って実装
プログラム番号、バージョン番号、手続き番号の組
で呼び出す手続きを識別
受け渡しできるパラメタは1つのみ
ただし、2つ以上のパラメタを構造体にまとめて渡せる
仕様書 : RFC1831
21
Sun RPCにおけるIDLの記述例
add.x
Sun RPCにおけるIDL
„
Sun RPCにおけるIDL : RPC言語(RPC
language, RPCL)
„
„
„
ファイル名の拡張子: .x
手続きのパラメタのデータ型、返り値の型、手続き
番号、バージョン、プログラム番号などを宣言
パラメタのデータ型はXDR言語(eXternal Data
Representation Language)で記述
„
„
„
22
XDRの符号化・復号化は規格化されており、扱うライブラリ
も整備されている
仕様書: RFC1832
rpcgenコマンドでスタブを自動生成
23
struct intpair {
int a;
int b;
}; /* XDR言語によるパラメタのデータ型宣言 */
program ADD_PROG { /* プログラム宣言 */
version ADD_VERS { /* バージョン宣言 */
int ADD(intpair) = 1; /* 手続きのプロトタイプ及び手続き番
号(=1)宣言*/
} = 1; /* バージョン番号=1 */
} = 0x23451111; /* プログラム番号(=0x2345111) */
24
4
RPCプログラム番号
0x00000000
0x20000000
0x40000000
0x60000000
-
rpcgenの実行例
% rpcgen –a add.x
% ls
Makefile.add Å Makefileの雛形(テンプレート)
add.x
add_clnt.c Å 生成されたクライアントスタブ
add_svc.c Å 生成されたサーバスタブ
add.h Å 共通のヘッダファイル
add_client.c Å クライアント側のサンプルコード
add_server.c
Å サーバ側のサンプルコード
add_xdr.c
Å XDR処理ルーチン
%
0x1FFFFFFF: Defined by Sun
0x3FFFFFFF: User Defined
0x5FFFFFFF: Transient
0xFFFFFFFF: Reserved
25
add_client.cの編集例(1/2)
add_client.cの編集例(2/2)
… (省略) …
void add_prog_1(char *host, int a, int b)
{
CLIENT *clnt; int *result_1;
intpair add_1_arg;
/* add.xで宣言したintpair型構造体 */
… (省略) …
add_1_arg.a=a;
add_1_arg.b=b;
result_1 = add_1(&add_1_arg, clnt); /* クライアントスタブの呼び出し*/
if (result_1 == (int *) NULL) {
clnt_perror (clnt, "call failed");
} else {
printf("result = %d¥n", *result_1);
}
… (省略) …
27
}
add_server.cの編集例
…(省略)…
int *add_1_svc(intpair *argp, struct svc_req *rqstp)
{ /* クライアントから渡されたパラメタはargpに格納 */
static int result;
/*
* insert server code here
*/
/* ここからリモート手続きの処理内容を記述 */
printf("add function called¥n");
printf("parameters: %d, %d¥n",argp->a,argp->b);
result = argp->a + argp->b; /* 整数引数a,bを加算 */
printf("returning: %d¥n",result);
return &result;
/* 結果をクライアントへ返す */
}
26
void main(int argc,char *argv[])
{
char *host;
int a,b;
if (argc != 4) {
printf ("usage: %s server_host num1 num2¥n", argv[0]);
exit (1);
}
host = argv[1];
/* リモートホストの指定 */
a=atoi(argv[2])) ; /* リモート手続きadd_prog_1()への
b=atoi(argv[3])) ; 引数a,bの設定 */
add_prog_1 (host, a, b); /* リモート手続きの呼び出し */
exit (0);
}
28
add_client/add_serverの実行例
(クライアント側)
% ./add_client localhost 1 2
result = 3
%
29
(サーバ側)
% ./add_server
add function called
parameters: 1, 2
returning: 3
30
5
遠隔オブジェクト起動(Remote Object
Invocation)
プロセス間通信
„
プロセス間通信:分散システムの中核
„
„
メッセージパッシングに基づく
„
„
„
„
„
„
きちんと定義されたインタフェースによって外部
から内部構造を隠蔽 Æ インタフェースが同じな
らばオブジェクトの置き換えが容易
ネットワークの下位層で提供される低位のサービス
大規模分散システムの構築 Æ 高位の通信手段が必
要
4つの(高位の)通信モデル
„
オブジェクト指向技術
„
„
遠隔手続き呼び出し(RPC)
遠隔メソッド実行 (RMI)
メッセージ指向ミドルウェア(MOM)
ストリームベース通信
RPCのメカニズムをオブジェクトに拡張:
Remote Object Invocation (遠隔オブジェク
ト起動)
31
32
分散オブジェクト
ソフトウェア部品としてのオブジェクト
„
オブジェクト(Object)の主な特徴
„
„
„
„
データ、及び、それらに対する処理群をまとめて
カプセル化(encapsulate)し、外部から隠蔽
„ データ:オブジェクトの状態(state)
„ 処理:オブジェクトのメソッド(method)
メソッドの集合はインタフェース(interface)として
外部から利用可能に
プロセスはメソッドを起動することによってのみ、
データにアクセス可能
分散システムでのオブジェクトの実装
„
„
インタフェースとその実装を分離
インタフェースはクライアントに、実装はサーバに存在
Æ 分散オブジェクト(Distributed Object)
33
分散オブジェクトの構成 (1/3)
„
分散オブジェクトの構成 (2/3)
クライアントが分散オブジェクトを結合(bind)する
„
34
オブジェクトのインタフェースの実装をクライアント側に
ロード
„ プロキシ(proxy)(RPCにおけるクライアントスタブに
対応)
35
„
実際のオブジェクトはサーバに実装
„
„
インタフェースはクライアント側と同じ
分散オブジェクトにおけるサーバスタブ: スケルト
ン(skeleton)
36
6
分散オブジェクトの構成 (3/3)
オブジェクトレファレンス
„
オブジェクト自体は分散していない
„
„
RPCと分散オブジェクトの違い
„
単一のサーバに実装 Æ遠隔オブジェクト
(remote object)とも呼ばれる
„
„
„
分散オブジェクトにおいては、分散システム全体にわたっ
て有効なオブジェクトレファレンス(object reference)を
持つことが可能
オブジェクトレファレンスを異なるマシン上の異なるプロセ
スへ(メソッドのパラメタとして)渡すことが可能
Æ パラメタの参照渡しが可能
Æ 透過性がRPCより向上
37
38
暗黙的結合と明示的結合
クライアントのオブジェクトへの結合
オブジェクトレファレンスが指すオブジェクト
のメソッドの起動
„
„
暗黙的結合(Implicit Binding)
„
„
結合(binding)によって、該当オブジェクトのイ
ンタフェースを実装するプロキシをローカルプロ
セスのメモリ空間に生成
„
„
クライアントはオブジェクトレファレンスを使って直接リモートメソッドを起動で
きる
„
必要時に自動的に結合が行われる
通常は結合は自動的に行われる
該当オブジェクトの実装を持っているサーバの位置
を知る手段、および、ローカルにプロキシを生成する
手段が必要
39
40
オブジェクトレファレンスの実装
(1/3)
暗黙的結合と明示的結合
明示的結合(Explicit Binding)
„
„
„
クライアントはリモートメソッド起動の前に、結合を行うための
特別な関数を呼ぶ必要がある
その関数の返り値は、ローカルに生成されたプロキシへのポ
インタ
オブジェクトレファレンス
„
„
„
„
41
クライアントが分散オブジェクトを結合するのに十分な情報を含む必
要あり
単純な実装:
„
分散オブジェクトが存在するサーバのネットワークアドレス、オブジェ
クト毎に動的に割り当てられたポート番号、および、オブジェクトの
名前の組
欠点:
„
サーバがクラッシュして、回復後、オブジェクトのポート番号が変わっ
た場合、古いオブジェクトレファレンスは無効
„
オブジェクトを別のサーバに移動できない(サーバのネットワーク
アドレスが変わるので)
42
7
オブジェクトレファレンスの実装
(2/3)
„
オブジェクトレファレンスの実装
(3/3)
„
クライアントとサーバは同じプロトコルを使用
同じトランスポートプロトコル(TCPなど)
„ 同じパラメタ符号化(マーシャリング)プロトコル
„
ロケーションサーバを設けて、オブジェクトとそれが
現在稼動するサーバのアドレスおよびポート番号の
対応を管理
オブジェクトレファレンスはロケーションサーバのア
ドレスと、オブジェクトの大域的な名前(ID)を保持
„
今までの実装での仮定
„
解決法:
„
„
オブジェクトレファレンスに追加情報を加えると、上
記の仮定は不要
„
ただし、ロケーションサーバにスケーラビリティ問題が生じ
る
リモートオブジェクトとの通信プロトコルに関する情報など
„
このアプローチを更に進めると...
„
実装ハンドル(implementation handle)をオブジェクトレファ
レンスに含める
„
43
44
遠隔メソッド起動(RMI)
実装ハンドル
„
実装ハンドル(implementation handle)
= プロキシの完全な実装(バイナリコード)が置い
てある場所のURL
„ クライアントが結合を行うときは、プロキシを動的に
ダウンロード・インストールし、インスタンス化したの
ちに起動
遠隔メソッド起動(Remote Method
Invocation,RMI)
„
„
„
„
クライアントがリモートオブジェクトを結合した後、そのオブ
ジェクトのメソッドをプロキシを通して起動すること
RPCとの本質的な相違点
„ オブジェクトへの大域的な参照(前述)
„ 汎用のスタブを持つ必要が無い
„ オブジェクトに特化したスタブを持つことができる
„
„
利点:クライアントはどんなプロトコルで実装されて
いるかを知らなくて良い
欠点:ダウンロードしたコードを実行するので、セキュ
リティ上の問題がある
45
46
静的RMIと動的RMI
„
動的RMI
RMIをサポートする方法
„
„
„
„
動的RMI
„
IDLなどでインタフェースをあらかじめ記述
Javaなどの言語:スタブの自動生成が可能
前もって定義されたインタフェース記述を利用する
アプローチ Æ 静的起動(static invocation)
„ クライアントの開発時に既にインタフェースが定
義されている必要がある
„ インタフェースが変更になると、クライアントを再
コンパイルする必要あり
実行時に、メソッドの起動を動的に構成 Æ 動的起
動(dynamic invocation)
47
„
一般的な形式
„
„
invoke(object, method, input_params, output_params);
„ object: 分散オブジェクトのID
„ method: メソッド名
„ input_params: メソッドの入力パラメタ群を持つデータ構造
„ output_params: メソッドの出力パラメタ群を持つデータ構造
動的RMIが有用な例
„
„
オブジェクトブラウザ
„ 任意のオブジェクトの情報を表示したりメソッド起動を行ったりする
„ 実行時に任意のインタフェースを扱える必要あり
バッチ処理サービス
„ メソッド起動のリクエストをキューに蓄えておき、順番に実行
48
8
RMIにおけるパラメタ渡し (1/2)
RMIはRPCと異なり、大域的なオブジェクト参照を扱える Æ
RPCよりパラメタ渡し(特に参照渡し)に関する制限は少ない
分散オブジェクトしか存在しないシステムを考えると...
„
„
„
„
任意のオブジェクトを参照渡しで渡せる
渡されたプロセスは必要時に当該オブジェクトを結合すればよい
RMIにおけるパラメタ渡し (2/2)
全てのオブジェクトを分散オブジェクトとして扱うのは非効
率
„
„
„
整数(integer) や論理型( boolean)などの基本型のデータはロー
カルに扱いたい
Æ ローカルオブジェクトへの参照は、参照している値をコピーして
渡す(RPCでの配列の場合と同様)
49
例1 CORBA
„
CORBAインタフェース
CORBA(Common Object Request Broker
Architecture) (詳細は教科書9.1節)
„
„
„
„
50
„
非営利組織OMG(Object Management Group)によ
り標準化
プログラム言語に非依存
クライアントとオブジェクト間の通信: ORB(Object
Request Broker,オブジェクトリクエストブローカー)
と呼ばれるミドルウェア層が処理
ORB間通信プロトコルを標準化(IIOP,Internet
Inter-ORB Protocol) Æ 異なるマシン・実装間で相
互接続可能(開放型分散システム)
インタフェースは標準言語OMG IDL(CORBA
IDL)で記述
„ IDLから多くの言語
(C,C++,Java,Ada,COBOL,Smalltalkなど)
へのマッピング規則あり
„ Javaの場合: JDK付属ツールidljでスタブ
(ORB)を自動生成可能 (Java IDL)
51
OMG IDLの記述例 Hello.idl
52
例2 HORB
module HelloMod { /* モジュール宣言 */
interface Hello { /* インタフェース宣言 */
/* メソッド宣言 */
string getMessage();
oneway void shutdown();
};
};
„
HORB: Javaベースの分散オブジェクト技術
„
他の技術と比較して、透過性が高い
„
„
„
サーバコードは無変更(自動変換)で、クライアントコードは
わずかな変更(オブジェクト結合の部分)で分散化可能
IDLは不要(Javaのクラス定義をそのまま使用)
Java言語に依存
„
„
ただし、Javaの特性によりプラットフォーム非依存
IIOPを用いてCORBAオブジェクトと相互接続可能
Java IDLを用いたスタブ生成およびコード記述方法は以下を参照:
http://www.atmarkit.co.jp/fjava/javafaq/ent/ent05.html
53
54
9
HORB記述例
„
関連技術:XML Webサービス
サーバコード(horbcでスタブ自動生成)
public class Test{
public String greeting(String s){
System.out.println(s);
return “こんにちは、Testです。”;
}
}
クライアントコード(サーバのコンパイルで得られたTest_Proxyクラ
スを用いて結合)
„
public class Client2{
…(省略)…
Test_Proxy test = new
Test_Proxy(“horb://remote_host.co.jp”);
String result = test.greeting(“こんにちは、Clientで
す。”);
System.out.println(result);
…(省略)…
55
}
„
„
„
„
ミドルウェア層の下位プロトコルとして汎用プロトコル
であるHTTPを利用した分散オブジェクト技術
HTTPによるデータ転送のために、データをXMLに符
号化(SOAP:Simple Object Access Protocol)
Webサーバ
SOAP対応クライアント
SOAP/XML over HTTP
HTML over HTTP
Webクライアント
Webサーバ
Webサーバ
SOAP/XML over HTTP
56
演習問題
1.
2.
3.
4.
5.
パラメタ・マーシャリング/アンマーシャリングとは具体的にど
のような処理か説明せよ。
クライアントスタブ/サーバスタブの役割を説明せよ。
RPCを用いたソフトウェアの例を3つ以上挙げよ。
分散オブジェクトを結合するとは具体的にどのような処理か説
明せよ。
RMIにおける参照渡しの実現がRPCに比べて容易である理由
を挙げよ。
57
10