Binary file yokou.dvi has changed

--- a/yokou.tex	Wed Feb 25 20:54:47 2009 +0900
+++ b/yokou.tex	Thu Feb 26 01:37:38 2009 +0900
@@ -24,19 +24,38 @@
 \maketitle
 \thispagestyle{fancy}
 
-\section{はじめに}
-分散プログラミングが多数開発されている近年、プログラム作成時にクラスタ上のノードやネットワークの動的な変化、故障、性能の多様性を考慮する必要があり、またそれを踏まえた上でのスケーラビリティを確保することが必要とされてきている。
-スケーラビリティとはリソースや負荷の増大に対してアプリケーション自体は変更することなく実行する事が出来る事を示す。
-本稿は分散プログラムに本研究室が提案しているFederated Lindaを用い、スケーラビリティなデバッグを行う為に通常のタプル通信の他にメタな通信を行うプロトコルエンジンの設計と実装について検討する。
+\section{スケーラビリティをデバッグする}
+分散アプリケーションが多数開発されている近年、
+ノードやネットワークの動的な変化、故障、性能の多様性を考慮した
+フレームワークが必要である。
+分散環境ではスケーラビリティを確保すること重要である。ここでの
+スケーラビリティとはノードの規模の増大にも関わらず、
+アプリケーションの性能を維持できることを指す。
+分散アルゴリズムの作成には、論理的なプログラムの正しさだけでなく、
+スケーラビリティのデバッグを可能にする必要がある。
+つまり、デバッガ自体をスケーラブルに作る必要がある。
+そのため、分散
+フレームワークとして本研究室が提案しているFederated Lindaに、
+スケーラビリティなデバッグを行う為のメタな通信を行うプロトコルエンジン
+を設計し実装した。
 
-\section{分散プログラムの問題点}
-デバッグを行う際に通常の通信を用いて行うのでは、本来の通信に影響を及ぼす恐れがある。よって、デバックプロトコル自身がスケーラビリティでなければいけない。つまり、サーバーの台数が変動した時に、デバッグプロトコルを別途用意する事なく同じ様に変動しなければならない。
+分散プログラムの
+デバッグを行う際には通信は必須であるが、その通信によって
+本来の通信に影響を及ぼす恐れがある。
+ここでは、スケーラビリティには若干問題があるが、
+本来の通信に影響を与えないように、一つのトークンをリング上に
+流す方法を提案する。本論文ではPCクラスタ上で実際の通信を行ない、100台程度の
+分散プログラムでの評価を行なった。
 
 \section{Federated Linda}
-Federated Lindaとは、複数のタプル空間を相互に接続する事によって分散プログラムを実現するモデルである。Lindaとは同じ構造ではあるが、Lindaが一つのタプル空間を共有するのに対し、Federated Lindaはタプル空間通しでin/outを行う。
-クライアントのアクセス数が増えたとしても、タプルスペース等の数を増やし処理を分散させる事により、スケーラビリティを保つ。
-
-本稿では、Linda ServerとProtocol Engineが一体化した実装を検討する。
+Federated Lindaとは、複数のタプル空間を相互に
+結ぶプロトコルエンジンによって
+接続する分散プログラミングモデルである。
+Lindaと同じAPIを持つが、
+Lindaが一つのタプル空間を共有するのに対し、
+Federated Lindaは複数のタプル空間を個別に持つ。
+クライアントのアクセス数に対応して、
+タプルスペースの数を増やし処理を分散させる事により、スケーラビリティを保つ。
 
 \subsection{Federated Linda Protocol}
 Federated Lindaは以下の様にして通信を行う。
@@ -48,15 +67,18 @@
 
 \item public PSXReply in(int id)
 
-タプルスペース番号より引数で指定したidのタプルの受け取りを要求する。返り値はPSXReplyで用いるユニークな番号となる。
+タプルスペース番号より引数で指定したidのタプルの受け取りを要求する。
+受け取りは、返値のPSXReplyをチェックすることにより非同期に行なう。
+in では待ち合わせは行なわれない。Call back 形式でタプルを受け取る
+ことも出来る。
 
 \item public PSXReply out(int id, ByteBuffer data)
 
-引数で指定したidでデータを送信する。dataはBytebufferでなければならない。
+引数で指定したidでByteBuffer内のデータを送信する。
 
 \item public int sync(long mtimeout) 
 
-接続しているLinda Serverとタプルの送受信を行う。
+接続しているLinda Serverとタプルの送受信のポーリングを行う。
 
 \end{itemize}
 
@@ -88,7 +110,9 @@
 \end{verbatim}
 
 \section{Meta Protocol Engine}
-type3ではスケーラビリティを実現する為にLinda Serverに直接Protocol Engineを実装する。このEngineをMemta Protocol Engineと呼ぶ。（図\ref{mpe}）
+デバッグ用の通信はLinda Server内部に直接アクセス出来なければ
+ならない。これをLinda Server内のMeta Protocol Engine に
+よって実現する(図\ref{mpe})。
 
 \begin{figure}[htbp]
 \begin{center}
@@ -98,25 +122,52 @@
 \end{center}
 \end{figure}
 
-通常のFederatedLindaと同様in/out出来るプロトコルを持ち、Protocol Engineと違う所はサーバー自身に直接アクセスして、データを取得する事が出来る事である。
-Linda Serverのメインループにメソッドを追加する事により、Serverが立ち上がると同時にMeta Protocol Engineを起動する事が出来る。
+Meta Engine は、
+通常のFederatedLindaと同様のin/out APIを持つ。
+Meta Engine では、\verb+sync()+が、属するLinda Server
+自体のポーリングを行なう。\verb+sync()+の間は、
+通信は行なわれず タプル空間は変化しない。
+Meta Engine は安全にタプル空間にアクセス出来る。
+Meta Engine のプログラムは、
+Linda Serverのメインループで指定することが出来、
+Server 毎に独自の動作をさせることが可能である。
 
-Metaでの通信例）３台のLinda Server間のデータをやり取りする場合（図\ref{ringthree}）
+3台のLinda Server間でMeta Engineがデータをやり取りする場合
+のUMLシーケンス図は
+図\ref{ringthree}のようになる。
 
 \begin{figure}[htbp]
 \begin{center}
 \includegraphics[scale=0.2]{img/meta_ring_three.eps}
-\caption{３台間のUML}
+\caption{3台間の通信}
 \label{ringthree}
 \end{center}
 \end{figure}
 
 \section{測定}
-本稿ではSnapShotを取得するため、また通信パケットを一つにし、分散通信に影響を最低限にするために、Ringで性能を評価する。
-Meta Protocol Engineでの通信テスト、3~100までの台数でデータが1周（図\ref{metaring}）および1000周（図\ref{metaring1000}）した時に掛かった時間を測定する。
+本稿では
+分散通信に影響を最低限にするために、Ringで性能を評価する。
+Ring では通信パケットは一つのみであり、デバッグ対象への
+影響が小さい。しかし、スナップショットや一時停止などの
+デバッグ操作をするためには、全ノードを周回する必要がある。
+これはo(n)であり、十分にスケーラビリティがあるとは言えない。
+しかし、もっとも影響が少ない方法なので、どの程度まで使える
+かを測定することには意味がある。
 
-測定環境はクラスタ（cls001~cls180）でTorqueを用いる。
-出来得るならば、180台までの測定を行いたかったが、使えないクラスタの台数が不安定に変動するので、安定して動作する100台までしか測定出来なかった。
+ここでは、通信パケットの大きさを変えて、
+3〜100までの台数でデータが1周(図\ref{metaring})する時間、
+および1000周(図\ref{metaring1000})した時に掛かった時間を測定する。
+前者では接続の手間を含む通信時間、後者では通信のみの時間を
+計ることが出来る。
+
+実験は、
+琉球大学
+情報工学科のクラスタ上(Core Duo 2GHz,メモリ1GB)で、
+クラスタジョブ管理システム
+Torqueを用いて行なった。
+ネットワークはAlaxalA Gigabit Ethernet Switchで構成されている。
+クラスタ自体は180台あるが、
+安定して動作する100台までを使用して測定を行なった。
 
 \begin{figure}[htbp]
 \begin{center}
@@ -134,20 +185,21 @@
 \end{center}
 \end{figure}
 
-X軸が台数、Y軸がミリ秒、ラインが通信するデータサイズを表す。
+X軸が台数、Y軸がミリ秒、ラインの色が通信するデータサイズを表す。
 
 両図から見てわかる通り、データの量にはあまり依存する事はなくほぼ同じラインを形作っている。
-データを1周のみした場合は１サイクルあたり約14000ms、一台あたり約140ms掛かっている計算になり、
-それに対し1000周した際に掛かった時間は、１サイクルおよそ60ms、一台につき約0.6msとなっている。
-これは、１周のみだと通信の際のopen/closeの時間に相当し、1000周だと、実際に通信にかかる時間に相当するものと考えられる。
-これより、Metaでの通信は実際にデバッグに使用するのに対応出来る時間だと考えられる。
+データを1周のみした場合は1サイクルあたり約14000ms、一台あたり約140ms掛かっている計算になり、
+それに対し1000周した際に掛かった時間は、1サイクルおよそ60ms、一台につき約0.6msとなっている。
+これより、一度、接続してしまえば、
+Meta Engine での通信は実際に100台程度のデバッグに使用するのに十分な性能を
+持っていることが確認出来た。
 
-\section{終わりに}
-本稿ではデバッグを行う為に通常通信とは他に、Metaで通信するMeta Protocol Engineを提案した。
-
-その結果、別途デバッグ用Protocol Engineを用意する事なくLinda間で通信が出来るため、よりスケーラブルなデバッグ環境が実現出来る事が分かった。
-今後の問題としては、同クラスタ上で別のRing通信や他のMetaLinda通信等があった場合に、デバッグプログラムと干渉する事はないか、
-本Meta Protocol Engineで実際にデバッグタプルを通信した場合に通常の通信との干渉するかどうかなどが、挙げられる。
+\section{まとめと課題}
+本稿ではデバッグを行う為に通常通信とは他に、Metaで通信するMeta Protocol Engineを実装し評価した。
+今回は、スナップショットなどの実際のデバッグ機能を実装することは出来なかった。
+通信の実験においても、
+同クラスタ上で別のRing通信や他のMetaLinda通信等があった場合の干渉の程度
+などを測定する必要があると考えられる。
 
 \thispagestyle{fancy}
 \begin{thebibliography}{9}