Binary file paper/jsst-kazz.pdf has changed

--- a/paper/jsst-kazz.tex	Fri Aug 27 22:44:15 2010 +0900
+++ b/paper/jsst-kazz.tex	Fri Aug 27 23:29:49 2010 +0900
@@ -202,6 +202,28 @@
 
 update() の引数は、 out() と同じく update(id,data) のように、 id と data を渡す。
 
+\subsection{wait\_rd() の問題点}\label{subsection:problemofwaitrd}
+
+Linda には、 rd API の他に、 wait\_rd という API が存在する。wait\_rd はた
+だちに reply を返す rd とは違って、タプルの情報が更新されるまで、サーバー
+側で reply が保留される。この API を用いることで、必要な座標情報が更新さ
+れたときのみに通信を行うことができる。
+しかし、 wait\_rd を受け付けたときのタプルデータは返されないため、最新の
+情報を得ることが出来ないというバグが、ゲームのクライアントを作成するとき
+に発生した。
+
+これを回避するために、 wait\_rd の結果が次のループで返されなかったときは、
+rd を用いて現在のタプルの情報を取得するようにした。しかしこれは、2重で
+rd の API を使っており、場合によっては無駄な通信を伴なう。また、クライア
+ントの受信側で、 rd と wait\_rd のどちらが最新のデータか判別する無駄な条
+件分岐が発生するため、場当たり的な対応でしかない。
+
+これを解決するためには、タプルのバージョンをサーバー側で記録するようにす
+るか、タイムスタンプを用いてタプルを管理するといった方法が挙げられる。
+
+Linda にこのような API を実装する予定はないが、 Linda を踏まえて次に本研
+究室で設計する分散データベースでは、参考にして設計しなおす予定である。
+
 \section{Meta Engine を用いたサーバーの設計}
 \subsection{ツリー型トポロジーを用いた負荷分散}\label{subsection:treetopology}
 今回の例題には、ツリー型トポロジー Federated Linda を用いることにした。
@@ -237,6 +259,25 @@
 があり、画面に表示されない(すなわち、必要のない)データも操作がされるたび
 に通信する必要があった。
 
+\subsection{Meta Engine の問題点}\label{subsection:problemofmetaengine}
+具体的に Meta Engine とは、サーバーが他サーバーとどのような接続を行い、
+どのタプルを監視し、どこに伝搬するかというのを記述するものである。
+
+Federated Linda は Java を用いて実装しており、その上に実装されている
+Meta Engine ももちろん Java で記述している。処理は関数でシンプルに記述で
+きるとよいが、 Java では関数のみを記述することはできないので、 interface
+を実装したクラスを作成することで処理を記述する必要がある。
+
+また、タプルの伝搬を行うために Federated Linda サーバーの接続一つごとに
+専用のタプルを決め、そこを in によって監視するのだが、その記述を
+Callback 関数のように記述すると、コードの難読化が進んでしまう。
+
+さらに、他サーバーと接続する処理を記述し、そのサーバーからのデータを受信
+するタプルと、相手への伝搬先のタプルを対応付けする処理を毎回記述する必要
+があるため、新しいトポロジーを構築しようとしたときにコードの記述量が増え
+てしまう。これを解決するためには、 Meta Engine とタプルスペースの間にそ
+れらの伝搬のシステムを管理する機構を準備する必要がある。
+
 \section{評価}
 \subsection{update API の検証}\label{subsection:updateverification}
 update() API を \ref{subsection:update} で設計した通りに実装した。