--- a/paper/kazz-jssst.tex	Mon Aug 08 18:21:52 2011 +0900
+++ b/paper/kazz-jssst.tex	Mon Aug 08 21:51:08 2011 +0900
@@ -121,13 +121,28 @@
 タプルスペースとは別のプロセスとして、サーバー上に存在していた。しかし、
 別のプロセスであるため、タプルスペースへのアクセスには同一サーバー上であっ
 ても、ソケット通信を用いていた。
-
+%
 そこで、本研究室では、 Meta Engine と呼ばれるプログラムを提案し実装して
 きた。 Meta Engine は、 タプルスペースと同一プロセス上に組み込まれた
 Protocol Engine である。(図\ref{fig:fedlinda})すなわち、タプルスペースと
 同じメモリ空間にあるため、ソケット通信を用いることなく直接 Linda の API
 を使用して、タプルスペースにアクセスすることが出来る。
 
+\subsection{Federated Linda の問題点}\label{"fedlinda2"}
+大きく分けて分散アプリケーションは、次の3つのパートで構成することができる。
+\begin{enumerate}
+\item {\bf Configuration} 各ノードの接続やルーティングを行う。
+\item {\bf ProtocolEngine} Database へアクセスし、他のノードにデータを伝搬する。
+\item {\bf Database} 通信した内容や計算結果などの各種データの保存領域。
+\end{enumerate}
+しかし、 FederatedLinda を利用したプログラマーが記述できる部分は ProtocolEngine だけであるため、 Configuration に関するコードをそこに記述しなくてはならない。そのため、各ノード間の接続やルーティングを利用者が管理する必要が出てくる。
+%
+また、 FederatedLinda の ProtocolEngine には、次の2つの実行方法がある。
+\begin{enumerate}
+\item {\bf Polling base} メインループで定期的に ProtocolEngine を実行し、 TupleSpace からデータを取得し、確認する。
+\item {\bf Callback function base} とある Tuple が更新される度にその Tuple に設定された Callback function が実行される。
+\end{enumerate}
+Polling base の場合は、通信が行われる都度、記述した Tuple の内容をチェックするため、負荷が大きくなる。そのため、 Callback function base を用いて記述する方が効率はよくなる。しかし、 Callback function 同士の繋がりがツリー状に構成されるため、利用者がそのツリー同士の接続管理を行わなくてはならない。また、 Callback function 間のデータの共有も難しい。 Callback function で記述されたコード群をシーケンシャルに読むことも難しくなる。
 
 \section{まとめと今後の課題}