|
0
|
1 \chapter{実装}
|
|
|
2
|
|
|
3 ここではFederated Linda の実装について説明する。実装したのは type2 であ
|
|
|
4 る。
|
|
|
5
|
|
|
6 \section{type2の実装}
|
|
|
7
|
|
|
8 Federated Linda は本研究室で開発された非同期型Linda\cite{linda}をベー
|
|
|
9 スに開発した。type 2 では Linda Server と Protocol Engine は別プロセスと
|
|
|
10 して実装する。Protocol Engine では Linda Server との通信を クライアントに
|
|
|
11 提供されている Linda API を用いて行う。
|
|
|
12
|
|
|
13 タプルのIDは、{\tt 16bit}の整数値を用いている。タプルのデータは任意の文字列であ
|
|
|
14 る。Linda Server は C で記述されており、クライアントは C, Perl, Python,
|
|
|
15 Ruby にて記述可能。以下、Linda Server と クライアントへ提供している
|
|
|
16 Linda API の説明をし、分散プログラムの主要素である Local Access,
|
|
|
17 Protocol Engine, Link Configuration の実装について説明する。
|
|
|
18
|
|
|
19 \subsection{Linda Server}
|
|
|
20
|
|
|
21 Linda Server は C で記述している。タプルスペースはメモリ上のキューとして
|
|
|
22 実装されている。タプルスペースには1から65535までのIDが割り当てられており、
|
|
|
23 タプルは指定されたIDへのキューへ格納される。
|
|
|
24
|
|
|
25 %% タプルの図は入れる？
|
|
|
26
|
|
|
27 %% in/rd の非同期の説明
|
|
|
28 非同期型 Linda Server の特徴として、タプルを要求するコマンド (in, read,
|
|
|
29 wait\_read) などを実行する際のコマンド実行の保留が挙げられる。クライアン
|
|
|
30 トからタプルを要求するコマンドを受け取ると、Linda Server は指定されたID
|
|
|
31 にタプルがあるかどうかを調べる。ある場合にはそのコマンドを即実行するが、
|
|
|
32 無い 場合には、コマンド実行の保留を行う。その後、そのIDへタプルが書き込
|
|
|
33 まれた( out された) 時に 保留されたコマンドを実行する。(図\ref{async-in}
|
|
|
34 参照)。このコマンド実行の保留により、コマンド実行の待ちやクライアントが
|
|
|
35 Linda Server へタプルの有無を問い合わせたりすることなく、非同期通信を行
|
|
|
36 うことができる。
|
|
|
37
|
|
|
38 \begin{figure}[htp]
|
|
|
39 \begin{center}
|
|
|
40 \includegraphics[width=13cm]{fig/async-in.eps}
|
|
|
41 \caption{タプルがない場合の in コマンドの実行}
|
|
|
42 \label{async-in}
|
|
|
43 \end{center}
|
|
|
44 \end{figure}
|
|
|
45
|
|
|
46 プログラムは {\tt ldserv} という名前で提供されている。
|
|
|
47 起動方法は以下の通りである。``-p''オプションでポート番号を指定している。
|
|
|
48
|
|
|
49 %% ldserv の起動方法など
|
|
|
50 \begin{verbatim}
|
|
|
51 $ ldserv -p 10000
|
|
|
52 \end{verbatim}
|
|
|
53
|
|
|
54 %% もうちょい説明が欲しぃ
|
|
|
55
|
|
|
56 \subsection{Federated Linda API} %% Local Access に入れてもいい？？
|
|
|
57
|
|
|
58 Federated Linda の通信は非同期に行われる。in, read, out などのコマンドの関数
|
|
|
59 を呼び出した時点では通信は行われず、それらのコマンドを一時的にキュー
|
|
|
60 ({\tt COMMAND}キュー)へ蓄える。蓄えたコマンドは、タプルやコマンドの送受信を行
|
|
|
61 う関数({\tt sync()})が呼ばれた時点で一斉に各 Linda Server へ送信される。このと
|
|
|
62 き、Linda Server から送信されたタプルの受信も行う。受信されたタプルは
|
|
|
63 {\tt REPLY}キューへ蓄えられ、データを取りだす関数({\tt reply()})で取り出される。
|
|
|
64 {\tt COMMAND} キューと {\tt REPLY} キューは API により隠蔽されており、直接は見えない。
|
|
|
65
|
|
|
66 Federated Linda ではクライアントプログラムへの API として C, Perl,
|
|
|
67 Python, Ruby で実装したインターフェースを提供している。クライアントプロ
|
|
|
68 グラムはこれらの中から好きな言語を選んで記述することになる。提供している
|
|
|
69 API は、C言語とその他のスクリプト言語との間で若干の違いがある。スクリプ
|
|
|
70 ト言語ではオブジェクト指向を意識して実装したため、このような違いが出てい
|
|
|
71 る。
|
|
|
72
|
|
|
73 C言語とスクリプト言語に分けて API の説明を行う。
|
|
|
74
|
|
|
75 \subsubsection{C言語のAPI}
|
|
|
76
|
|
|
77 C言語で提供している主な関数群は以下の通りである。
|
|
|
78
|
|
|
79 %% CのAPIの説明
|
|
|
80 \begin{itemize}
|
|
|
81 \item {\tt open\_linda(hostname,port)}\\
|
|
|
82 Linda Server へ接続する。引数としてホスト名({\tt hostname})とポート番号
|
|
|
83 ({\tt port})をとる。返り値はタプルスペースの番号
|
|
|
84 \item {\tt psx\_in(ts\_id,tuple\_id)}\\
|
|
|
85 指定したIDのタプルの受け取り要求をするコマンド {\tt in} を {\tt COMMAND}キュー
|
|
|
86 へ入れる。引数としてコマンドを送るタプルスペースの番号({\tt ts\_id})と受け
|
|
|
87 取るタプルのID({\tt tuple\_id})をとる。返り値として{\tt psx\_reply()}でタプル
|
|
|
88 を取り出すときに用いるユニークな番号が返る。受け取ったタプルは、タ
|
|
|
89 プルスペース上からは削除される。
|
|
|
90 \item {\tt psx\_rd(ts\_id,tuple\_id)}\\
|
|
|
91 指定したIDのタプルの受け取り要求をするコマンド {\tt read} を{\tt COMMAND}キュー
|
|
|
92 へ入れる。引数としてコマンドを送るタプルスペースの番号({\tt ts\_id})と受け
|
|
|
93 取るタプルのID({\tt tuple\_id})をとる。返り値として{\tt psx\_reply()}でタプル
|
|
|
94 を取り出すときに用いるユニークな番号が返る。受け取ったタプルは、タ
|
|
|
95 プルスペース上に残る。
|
|
|
96 \item {\tt psx\_wait\_rd(ts\_id,tuple\_id)}\\
|
|
|
97 {\tt psx\_rd()}と似ているが、タプルスペース上での挙動に違いがある。タプル
|
|
|
98 スペースにタプルがあった場合、現在あるタプルではなく、新規に{\tt out}され
|
|
|
99 たタプルに対して{\tt read}を行う。それ以外は同じ挙動である。
|
|
|
100 \item {\tt psx\_out(ts\_id, tuple\_id, data)}\\
|
|
|
101 指定したIDのタプルの書き込み要求をするコマンド {\tt out} を{\tt COMMAND}キュー
|
|
|
102 へ入れる。引数としてコマンドを送るタプルスペースの番号({\tt ts\_id})と書き
|
|
|
103 込むタプルのID({\tt tuple\_id})をとる。
|
|
|
104 \item {\tt psx\_ck(ts\_id,tuple\_id)}\\
|
|
|
105 指定したIDのタプルの有無の確認をするコマンド {\tt check} を{\tt COMMAND}キュー
|
|
|
106 へ入れる。引数としてコマンドを送るタプルスペースの番号({\tt ts\_id})と受け
|
|
|
107 取るタプルのID({\tt tuple\_id})をとる。返り値として{\tt psx\_reply()}でタプル
|
|
|
108 を取り出すときに用いるユニークな番号が返る。タプルのデータ部分には
|
|
|
109 タプルスペース上にあるタプルのサイズが入る。指定したIDのタプルが無
|
|
|
110 ければ {\tt 0} となる。
|
|
|
111 \item {\tt psx\_sync\_n()}\\
|
|
|
112 接続している全Linda Server とタプルの送受信を行う。{\tt COMMAND}キューに
|
|
|
113 溜まったコマンドを送信し、Linda Server からのタプルを {\tt REPLY} キュー
|
|
|
114 へ入れる
|
|
|
115 \item {\tt psx\_reply(uid)}\\
|
|
|
116 {\tt REPLY}キューにあるタプルを取りだす。取り出す際に、{\tt in},
|
|
|
117 {\tt read}コマンドが返した番号を引数としてとる。返り値はタプル。取り出したタプルからデー
|
|
|
118 タやタプル情報(IDやデータサイズ)を取り出す関数群も用意している。
|
|
|
119 \end{itemize}
|
|
|
120
|
|
|
121 まず {\tt open\_linda} を用いて Linda Server へ接続する。この時返る値が Linda
|
|
|
122 Server の ID になる(Tuple Space ID)。この値とタプルのIDを用いて{\tt psx\_in,
|
|
|
123 psx\_rd, psx\_out}などのコマンドを発行する。{\tt psx\_in} や {\tt psx\_rd, psx\_ck}
|
|
|
124 はユニークな番号を返す。この番号は {\tt psx\_reply} の引数として使用し、どの
|
|
|
125 {\tt psx\_in, psx\_rd}の返答を取り出すかを指定するためのものである。通信は
|
|
|
126 {\tt psx\_sync\_n}でのみ発生する。
|
|
|
127 %まず open\_linda を用いて Linda Server へ接続する。この時返る値が Linda
|
|
|
128 % ^^^^^ こういうのは {\tt } とか \verb+...+ みたいなのを使って
|
|
|
129 % type writer font にする
|
|
|
130
|
|
|
131 これらのAPIを用いた通信はポーリング型の形を取る。具体的なポーリングベー
|
|
|
132 スのプログラミング例は Local Access の説明で述べる。
|
|
|
133
|
|
|
134 \subsubsection{Perl, Python, Ruby の API}
|
|
|
135
|
|
|
136 %% Perl, Python, Ruby で提供したクラスなどの説明
|
|
|
137
|
|
|
138 Perl, Python, Ruby は C の API を拡張して実装している。提供しているモジュー
|
|
|
139 ルは{\tt FederatedLinda, Linda, Reply}というクラスで構成されている(図
|
|
|
140 \ref{LWLClass}参照)。各スクリプト言語で同じ名前を用いて実装している。
|
|
|
141
|
|
|
142
|
|
|
143 %% FederatedLinda クラスや Reply クラスを、図を入れて説明
|
|
|
144
|
|
|
145 \begin{figure}[htbp]
|
|
|
146 \begin{center}
|
|
|
147 \includegraphics[width=15cm]{fig/flinda-class-dig.eps}
|
|
|
148 \caption{Perl, Python, Ruby で拡張したLinda API のクラス図}
|
|
|
149 \label{LWLClass}
|
|
|
150 \end{center}
|
|
|
151 \end{figure}
|
|
|
152
|
|
|
153 %% 各クラスの説明。
|
|
|
154 %% FederatedLinda.open() で Linda インスタンス生成、
|
|
|
155 %% Linda.in(), Linda.rd() で Reply インスタンスが返るとか
|
|
|
156 %% FederatedLinda.sync() で通信
|
|
|
157
|
|
|
158 \begin{itemize}
|
|
|
159 \item {\tt FederatedLinda} - {\tt open} や {\tt sync} など、通信やその接
|
|
|
160 続切断を行うクラス。１プロセスに１インスタンスのみ生成される。
|
|
|
161 \begin{description}
|
|
|
162 \item[~{\tt open(hostname, port)}]{\tt Linda} インスタンスを返す。引数としてホスト名
|
|
|
163 ポート番号を取る。
|
|
|
164 \item[~{\tt sync()}] 接続している全Linda Serverと通信を行う。
|
|
|
165 \end{description}
|
|
|
166 \item {\tt Linda} -
|
|
|
167 インスタンスを生成する際に Linda Server と接続する。メンバとしてタ
|
|
|
168 プルスペースのIDを保持する({\tt tsid})
|
|
|
169 \begin{description}
|
|
|
170 \item[~{\tt In(tid)}]{\tt in} コマンドを発行する。引数としてタプルID({\tt
|
|
|
171 tid})を取る。返
|
|
|
172 り値は、その応答となる{\tt Reply}のインスタンス。
|
|
|
173 \item[~{\tt Rd(tid)}]{\tt read }コマンドを発行する。引数としてタプル
|
|
|
174 ID({\tt tid})を取る。返り値は、その応答となる{\tt Reply}のインスタンス。
|
|
|
175 \item[~{\tt WaitRd(tid)}]{\tt wait\_rd} コマンドを発行する。引数としてタプ
|
|
|
176 ルID({\tt tid})を取る。返り値は、その応答となる{\tt Reply}のインスタンス。
|
|
|
177 \item[~{\tt Out(tid, data)}]{\tt out}コマンドを発行する。引数としてタプル
|
|
|
178 {\tt ID(tid)}と送信するデータを取る。
|
|
|
179 \item[~{\tt Ck(tid)}]{\tt check} コマンドを発行する。引数としてタプル
|
|
|
180 ID({\tt tid})を取る。返り値は、その応答となる{\tt Reply}のインスタンス。
|
|
|
181 \item[~{\tt getid()}]タプルID 65535 の値を取得する。この値はLinda Server内部で
|
|
|
182 クライアント数をカウントした値である。
|
|
|
183 \item[~{\tt close()}]Linda Server との接続を閉じる。
|
|
|
184 \end{description}
|
|
|
185 \item {\tt Reply} -
|
|
|
186 Linda Server から受け取ったタプルを取得するためのクラス。
|
|
|
187 \begin{description}
|
|
|
188 \item[~{\tt reply()}]受け取ったタプルを取得する。タプルをまだ受け取っていなかっ
|
|
|
189 たら{\tt null(None)}を返す。
|
|
|
190 \end{description}
|
|
|
191 \end{itemize}
|
|
|
192
|
|
|
193 Linda Server への接続は {\tt FederatedLinda} インスタンスの {\tt open} メソッドを使
|
|
|
194 う。引数として接続したいLinda Serverのホスト名とポート番号を取る。{\tt open}は
|
|
|
195 {\tt Linda}インスタンスが返す。また、Linda Serverとの通信は{\tt sync}メソッドで行う。
|
|
|
196 {\tt in, read, out}などのコマンドは、{\tt Linda}インスタンスのメンバ関数から行う。
|
|
|
197 {\tt in, read}などのタプルを受け取るコマンドは、{\tt Reply}インスタンスを返す。Linda
|
|
|
198 Serverからのタプルを取り出したいときは、{\tt Reply}の{\tt reply}メソッドを用いる。
|
|
|
199
|
|
|
200 %% 次の「Federated Linda を用いたプログラミング」に入れてもいいかも？
|
|
|
201 \section{Local Access to Protocol}
|
|
|
202
|
|
|
203 %% Client プログラムでの Linda API の使いかた
|
|
|
204 %% Protocol Engine の使い分け方(タプルIDの切り替え)
|
|
|
205 %% 非同期な Linda API の有効的な使いかた。??
|
|
|
206 %% ポーリング型のプログラミングを強調
|
|
|
207
|
|
|
208 ``Local Access''はプロトコルへアクセスするAPIである。APIの内容は先に説明
|
|
|
209 したので、ここではクライアントプログラムにおける Linda API を用いたプロ
|
|
|
210 グラミングについて説明する。まず最初に、Linda API を使ったクライアントの
|
|
|
211 ポーリング型のプログラミングについて説明する。次に、タプルスペースを
|
|
|
212 介した Protocol Engine へのアクセスについて、その利便性について説明する。
|
|
|
213
|
|
|
214 \subsection{ポーリング型のプログラミングスタイル}
|
|
|
215
|
|
|
216 Federated Linda の通信は非同期に行われる。これはポーリング型のプログ
|
|
|
217 ラミングスタイルで記述されることが期待されているということでもある。
|
|
|
218 Linda API を用いるプログラムではメインループが一度回ると、{\tt sync()}が一回呼
|
|
|
219 ばれるようなプログラミングスタイルになる。これは、通信が起こる回数を減ら
|
|
|
220 すことと、通信箇所を明確にすることを目的としている。
|
|
|
221
|
|
|
222 以下にPerlで記述したプログラミング例を挙げる。
|
|
|
223
|
|
|
224 \begin{center}
|
|
|
225 \begin{itembox}[l]{ポーリング型のプログラミング例}
|
|
|
226 \begin{verbatim}
|
|
|
227 # Linda Server と接続する
|
|
|
228 $linda = FederatedLinda->open($hostname, $portnumber);
|
|
|
229 # タプルスペースの TUPLE_ID へタプルの取得を要求する
|
|
|
230 $rep = $linda->in($TUPLE_ID);
|
|
|
231 # メインループ
|
|
|
232 while (1) {
|
|
|
233 #
|
|
|
234 # 通信以外の処理
|
|
|
235 #
|
|
|
236 if (($data = $rep->reply()) > 0) { # 応答が来ていたら
|
|
|
237 # 繰り返しIDに対してタプルの取得要求を出す
|
|
|
238 $rep = $linda->in($TUPLE_ID);
|
|
|
239
|
|
|
240 #
|
|
|
241 # 受け取ったデータの処理を記述
|
|
|
242 #
|
|
|
243 print $data;
|
|
|
244 }
|
|
|
245 # コマンドやタプルの一斉送受信
|
|
|
246 FederatedLinda->sync();
|
|
|
247 }
|
|
|
248 \end{verbatim}
|
|
|
249 \end{itembox}
|
|
|
250 \end{center}
|
|
|
251
|
|
|
252 この例は {\tt \$TUPLE\_ID} で指定されたタプルスペースのタプルを取得し、標準出
|
|
|
253 力へ書き出すプログラムである。基本的な流れは以下のようになっている。まず
|
|
|
254 Linda Server へ接続する。次に、使用するタプルスペースへ {\tt in} する。
|
|
|
255 この {\tt in }
|
|
|
256 はその後の {\tt sync()} が実行されるまで Linda Server へは送信されない。メイン
|
|
|
257 ループ内は３つのパートに分かれる。まずは``通信以外の処理''では、クライア
|
|
|
258 ントの処理を行う。ここでデータのin, read, out 等を実行してもよい。次に
|
|
|
259 {\tt reply()} で in/read した時の応答が受け取ったかを確認。受け取っていたなら
|
|
|
260 ({\tt if} 内が実行され)受け取ったデータの処理を行う。そして最後に{\tt sync()}を呼
|
|
|
261 んで通信を行う。
|
|
|
262
|
|
|
263 この例は基本的なプログラミングである。しかし、メインループ内で {\tt sync()} は
|
|
|
264 一度だけ呼ぶ事、{\tt reply()} でデータの受信を確認する事など、ポーリングを意識
|
|
|
265 したプログラミングの特徴を表している。
|
|
|
266
|
|
|
267 また、{\tt reply()} のデータ取り出し時や {\tt sync()} の通信時で``待ち''に入る事はな
|
|
|
268 い。よって、通信以外の処理が待たされることはないが、逆に通信以外の処理で
|
|
|
269 ``待ち''が入ると、通信が滞る。通信以外の処理においても``待ち''が入らない
|
|
|
270 ようなスタイルを取る必要がある。
|
|
|
271
|
|
|
272 \subsection{Protocol Engine へのアクセス}
|
|
|
273
|
|
|
274 クライアントプログラムは使用する Protocol Engine とはタプルスペースを介
|
|
|
275 してデータをやり取りする。データのやり取りは Linda をベースにした in,
|
|
|
276 read, out という分かりやすいモデルになっている。
|
|
|
277
|
|
|
278 Protocol Engine への依存は低い。実際、タプルIDを各プロトコル毎に割り当て
|
|
|
279 ることにより、使用するプロトコルを切替えるということもできる。この場合、
|
|
|
280 in, read, out などのコマンドで指定する タプルID を変更するだけでいい。
|
|
|
281
|
|
|
282 以下に例を挙げる(図\ref{select_protocol}参照)。
|
|
|
283
|
|
|
284 \begin{figure}[htp]
|
|
|
285 \begin{center}
|
|
|
286 \includegraphics[width=8cm]{fig/select_protocol.eps}
|
|
|
287 \caption{使用するプロトコルの切替え}
|
|
|
288 \label{select_protocol}
|
|
|
289 \end{center}
|
|
|
290 \end{figure}
|
|
|
291
|
|
|
292 この図の場合、タプルIDの 10000 番を Distance Vector 型 Routing Protocol
|
|
|
293 に、タプルID 10001 番を Broad Cast Protocol に割り当てている。クライアン
|
|
|
294 トプログラム(Client Application)は、in, read, out するときの引数として渡す
|
|
|
295 タプルIDを 10000 すると Distance Vector 型 Routing Protocol を用いたデー
|
|
|
296 タ転送を行い、 10001 すると全タプルスペースへ Broad Cast することになる。
|
|
|
297
|
|
|
298 プロトコルへのアクセスは in, read, out などの単純なコマンドで行われるの
|
|
|
299 で分かりやすい。また、プロトコル切替えが容易であるので、多数のプロトコル
|
|
|
300 を用いたプログラムを記述しやすい。
|
|
|
301
|
|
|
302 \section{Protocol Engine}
|
|
|
303
|
|
|
304 %% プロトコルエンジンの書きかた
|
|
|
305 %% Replyを受け取ってから、再び同じタプルIDにin/rdするとか
|
|
|
306 %% プログラミングのパターンなどをソース(擬似？)を入れて説明
|
|
|
307 %% 複数のタプルスペースへのアクセスをどう制御するか？とか
|
|
|
308
|
|
|
309 type 2 では Protocol Engine は Linda API を用いて実装する。よって実装の
|
|
|
310 スタイル自体は Local Access to Protocol にて説明した通りである。そしてそ
|
|
|
311 の API を用いて分散アルゴリズムを実装する。分散アルゴリズムは多種多様あ
|
|
|
312 り、またその実装方法も多い。しかし、タプルのやり取りの部分はやタプルIDの
|
|
|
313 使いかたなどは共通しているので、その部分を説明する。
|
|
|
314
|
|
|
315 以下にマルチキャストを行うプロトコルのメインループの例を挙げる。
|
|
|
316
|
|
|
317 この例では、{\tt \$TUPLE\_ID\_CONNECT, \$TUPLE\_ID\_SEND,
|
|
|
318 \$TUPLE\_ID\_RECV} の３つのタプルIDを使用している。また、接続先の Linda
|
|
|
319 Server を配列を用いて管理している。
|
|
|
320
|
|
|
321 {\tt \$TUPLE\_ID\_CONNECT}に投入されたタプルは新しく接続する Linda Server の
|
|
|
322 ホスト名とポート番号が入っており、{\tt getTuplespace()} 内 で
|
|
|
323 {\tt FederatedLinda->open()} している。
|
|
|
324
|
|
|
325 {\tt \$TUPLE\_ID\_SEND}に投入されたタプルは、マルチキャストしたいデータを含
|
|
|
326 んでいる。よって、自分が接続している全Linda Server の{\tt \$TUPLE\_ID\_RECV}
|
|
|
327 へタプルを投入する。クライアントは、データを送りたいときは
|
|
|
328 {\tt \$TUPLE\_ID\_SEND}へタプルを{\tt out}し、受け取りたいときは、
|
|
|
329 {\tt \$TUPLE\_ID\_RECV}へ{\tt in}する。
|
|
|
330
|
|
|
331 \begin{center}
|
|
|
332 \begin{itembox}[l]{マルチキャストのプロトコルの例}
|
|
|
333 \begin{verbatim}
|
|
|
334 @tuplespaces # マルチキャストする相手の Linda インスタンス
|
|
|
335 $linda # 自分が担当する Linda
|
|
|
336 # メインループ
|
|
|
337 while (1) {
|
|
|
338 # 接続に変更があった場合の処理
|
|
|
339 if (($data = $ConnectRep->reply()) > 0) {
|
|
|
340 $ConnectRep = $linda->in($TUPLE_ID_CONNECT);
|
|
|
341 # $dataから接続相手を得て、@tuplespaces へ加える
|
|
|
342 @tuplespaces = (@tuplespaces, getTuplespace($data));
|
|
|
343 }
|
|
|
344 # マルチキャスト
|
|
|
345 if (($data = $MultiCastRep->reply()) > 0) {
|
|
|
346 # 繰り返しIDに対してタプルの取得要求を出す
|
|
|
347 $MultiCastRep = $linda->in($TUPLE_ID_MULTICAST);
|
|
|
348 # 全タプルスペースへデータを送信
|
|
|
349 foreach $t (@tuplespaces) {
|
|
|
350 $t->out($TUPLE_ID_RECV, $data);
|
|
|
351 }
|
|
|
352 }
|
|
|
353 FederatedLinda->sync();
|
|
|
354 }
|
|
|
355 \end{verbatim}
|
|
|
356 \end{itembox}
|
|
|
357 \end{center}
|
|
|
358
|
|
|
359 この例では 自分が担当する Linda Server の二つのタプルID(
|
|
|
360 {\tt \$TUPLE\_ID\_CONNECT, \$TUPLE\_ID\_SEND})に {\tt in} をしており、それぞれの
|
|
|
361 タプルIDで取り扱われるデータを分けている。また、クライアントのデータ送信・
|
|
|
362 受信をそれぞれ {\tt \$TUPLE\_ID\_SEND, \$TUPLE\_ID\_RECV} へ割り当てている。
|
|
|
363 このようにタプルID毎に取り扱うデータを決めておき、そのIDからのデータを受
|
|
|
364 け取ったら、対応する処理を行うということができる。当然タプルのデータ部に
|
|
|
365 プロトコル独自のヘッダなどを入れて、それで行う処理を選択することもできる。
|
|
|
366 しかしその場合はデータ自身がその Protocol Engine に依存するので、他の
|
|
|
367 Protocol Engine では使えなくなる。
|
|
|
368
|
|
|
369 よって、様々な Protocol Engine で使われるデータなどは、その処理の選択は
|
|
|
370 タプルID毎に行うといいだろう。そうでない場合は同一タプルIDを使うとう手段
|
|
|
371 もある。
|
|
|
372
|
|
|
373 \section{Link Configuration}
|
|
|
374
|
|
|
375 %% タプルスペースとの接続について
|
|
|
376 %% コネクションをどう管理するか。
|
|
|
377 %% トポロジ生成について。XMLによる生成。Graffle
|
|
|
378
|
|
|
379 Linda Server 間は Protocol Engine で接続される。その接続の形を規定するの
|
|
|
380 が Link Configuration である。Link Configuration ではタプルスペース間を
|
|
|
381 どのように接続するかを XML で記述しており、それを基にネットワークを構築
|
|
|
382 する。
|
|
|
383
|
|
|
384 図\ref{linkconfig_xml}では Configurator というプロセスが 接続状態を表し
|
|
|
385 た XML を Linda Server へ投入し、そのXMLを元にトポロジを構築している。
|
|
|
386 このXMLを投入するプロセスはクライアントプログラムでも Protocol Engine で
|
|
|
387 もよい。
|
|
|
388
|
|
|
389 \begin{figure}[htp]
|
|
|
390 \begin{center}
|
|
|
391 \includegraphics[width=13cm]{fig/lc.eps}
|
|
|
392 \caption{Configuratorによるトポロジ形成}
|
|
|
393 \label{linkconfig_xml}
|
|
|
394 \end{center}
|
|
|
395 \end{figure}
|
|
|
396
|
|
|
397 Link Configuration では、取り扱う XML のパーサとトポロジの接続の状態を
|
|
|
398 表したデータ構造、接続を行う関数などをプロトコルとして Protocol Engine
|
|
|
399 へ組み込めるように、モジュールとして提供している。以下ではその説明を行う。
|
|
|
400
|
|
|
401
|
|
|
402 \subsection{トポロジを表すXML}
|
|
|
403
|
|
|
404 まず、トポロジを規定するXMLについて説明する。このXMLの形式は独自に定めた
|
|
|
405 ものである。
|
|
|
406
|
|
|
407 以下に挙げる例は、ノード数 ４ で、Ring トポロジを表した XML である。この
|
|
|
408 例を用いて XML の形式を説明する。
|
|
|
409
|
|
|
410 \begin{center}
|
|
|
411 \begin{itembox}[l]{Ring トポロジを表す XML例}
|
|
|
412 \begin{verbatim}
|
|
|
413 <graph name = "Ring">
|
|
|
414 <node label = "lindaA" tsid = "localhost:10000">
|
|
|
415 <destination label = "lindaC"/>
|
|
|
416 <destination label = "lindaB"/>
|
|
|
417 </node>
|
|
|
418 <node label = "lindaB" tsid = "localhost:10002">
|
|
|
419 <destination label = "lindaD"/>
|
|
|
420 <destination label = "lindaA"/>
|
|
|
421 </node>
|
|
|
422 <node label = "lindaC" tsid = "localhost:10003">
|
|
|
423 <destination label = "lindaD"/>
|
|
|
424 <destination label = "lindaA"/>
|
|
|
425 </node>
|
|
|
426 <node label = "lindaD" tsid = "localhost:10004">
|
|
|
427 <destination label = "lindaB"/>
|
|
|
428 <destination label = "lindaC"/>
|
|
|
429 </node>
|
|
|
430 </graph>
|
|
|
431 \end{verbatim}
|
|
|
432 \end{itembox}
|
|
|
433 \end{center}
|
|
|
434
|
|
|
435 各タグの説明をする。
|
|
|
436
|
|
|
437 \begin{itemize}
|
|
|
438 \item {\tt graph} - トポロジを表すルートタグ
|
|
|
439 \begin{description}
|
|
|
440 \item [~{\tt name}] - トポロジの名前などを表す。任意
|
|
|
441 \end{description}
|
|
|
442 \item {\tt node} - Linda Server を表すタグ。子要素として、接続先を表した
|
|
|
443 {\tt desitination} タグを持つ。
|
|
|
444 \begin{description}
|
|
|
445 \item [~{\tt label}] - ノードに付けられたラベル。この属性を元に接続状況を調べる。
|
|
|
446 \item [~{\tt tsid}] - Linda Server のタプルスペースID。どのタプルスペースがこのノー
|
|
|
447 ドを担当するかを表す。
|
|
|
448 \end{description}
|
|
|
449 \item {\tt destination} - 接続先を表すタグ。
|
|
|
450 \begin{description}
|
|
|
451 \item [~{\tt label}] - 接続先のラベル。XML内のどの {\tt node} タグに対応するかを表す。
|
|
|
452 \end{description}
|
|
|
453 \end{itemize}
|
|
|
454
|
|
|
455 このXMLは非常に単純な構造をしている。まずルートタグの下には各 Linda
|
|
|
456 Server を表す {\tt node} タグがある。この {\tt node} タグには各々個別の名
|
|
|
457 前({\tt lable}属性)が付けられている。また、そのノードを担当する Linda
|
|
|
458 Server のタプルスペースID({\tt tsid}属性)が付いている。接続状況などは
|
|
|
459 {\tt lable} を用いて表される。{\tt node} タグは子として {\tt
|
|
|
460 destination} タグを持つ。{\tt destination} タグは、{\tt node} がどのノー
|
|
|
461 ドと接続するかを表している。あて先は {\tt lable}属性を用いて表される。
|
|
|
462 {\tt node} タグで定義されていない {\tt lable} や、親の {\tt lable} を指定
|
|
|
463 することはできない。{\tt destination} はあて先を表しており、単方向グラフ
|
|
|
464 になっている。
|
|
|
465
|
|
|
466 このXMLは Protocol Engine が解析することになる。Protocol Engine に組み込
|
|
|
467 むパーサと自身が接続する相手先を取得するモジュールを提供している。次では
|
|
|
468 その説明を行う。
|
|
|
469
|
|
|
470 \subsection{接続を行うモジュール}
|
|
|
471
|
|
|
472 Link Configuration では Link Configuration の XML を変換するパーサと、変
|
|
|
473 換されたデータ構造を表すクラスを提供している。図\ref{LinkConfig-class}に
|
|
|
474 そのクラス図を示す。
|
|
|
475
|
|
|
476 \begin{figure}[htb]
|
|
|
477 \begin{center}
|
|
|
478 \includegraphics[width=13cm]{fig/LinkConfig-class-dig.eps}
|
|
|
479 \end{center}
|
|
|
480 \caption{LinkConfiguration のクラス図}
|
|
|
481 \label{LinkConfig-class}
|
|
|
482 \end{figure}
|
|
|
483
|
|
|
484 提供するクラスは、{\tt LinkConfigParser, LinkConfiguration, NodeInfo} の３つで
|
|
|
485 ある。これらのメンバとメソッドの説明を以下に示す。
|
|
|
486
|
|
|
487 \begin{itemize}
|
|
|
488 \item {\tt LinkConfigParser} - XMLを解析し、その結果である {\tt
|
|
|
489 LinkConfiguration} インスタンスを返す
|
|
|
490 \begin{description}
|
|
|
491 \item [~{\tt parseLinkConfig(tsid, xmltext)}] - XMLを解析する。引数として自分のタ
|
|
|
492 プルスペース ID({\tt tsid})、解析するXML({\tt xmltext})を取る。解析結果
|
|
|
493 の {\tt LinkConfiguration} インスタンスを返す。
|
|
|
494 \end{description}
|
|
|
495 \item {\tt LinkConfiguration} - 各ノードの接続を表すクラス。
|
|
|
496 \begin{description}
|
|
|
497 \item [~{\tt tsid}] - タプルスペースID
|
|
|
498 \item [~{\tt lable}] - 自分が担当するタプルスペースのラベル
|
|
|
499 \item [~{\tt linklist}] - XMLで示された全ノードの接続をハッシュとして保持。キーと
|
|
|
500 してラベルを使用。値は {\tt NodeInfo} インスタンス。
|
|
|
501 \item [~{\tt getDstlist(label)}] - 引数で渡したラベルのノードが接続する相
|
|
|
502 手のラベルの配列を取得
|
|
|
503 \end{description}
|
|
|
504 \item {\tt NodeInfo} - ノードを表すクラス
|
|
|
505 \begin{description}
|
|
|
506 \item [~{\tt tsid}] - ノードを担当するタプルスペースのID
|
|
|
507 \item [~{\tt lable}] - ノードのラベル
|
|
|
508 \item [~{\tt dstlist}] - ノードが接続するノードのラベルのリスト
|
|
|
509 \end{description}
|
|
|
510 \end{itemize}
|
|
|
511
|
|
|
512 これらのクラスを使い、XMLより自分が接続する相手先のタプルスペースIDの一
|
|
|
513 覧を取得し、{\tt FederatedLinda.open} を行うことになる。{\tt Linda} クラスの管理は各
|
|
|
514 プログラムに任せる。また、{\tt LinkConfiguration} インスタンスを複数持つことに
|
|
|
515 より、一つの Protocol Engine で別々のトポロジに参加することも可能である。
|
|
|
516
|
|
|
517 %% 足りない部分(動的に接続を管理)にも触れる >> できれば作りたい
|
|
|
518
|
