Binary file .DS_Store has changed

--- a/Draft/Draft.tex	Mon Feb 18 14:44:16 2013 +0900
+++ b/Draft/Draft.tex	Mon Feb 18 18:04:07 2013 +0900
@@ -76,7 +76,10 @@
 \section{Alice}
 Aliceを使う際に必要なData SegmentとCode Segmentについて説明を行う。
 \subsection{DataSegment}
-AliceではData Segmentをデータベースとして利用しており、以下のDataSegment API を用いることでData Segmentにデータを追加、削除を適宜行うことができる。
+AliceではData Segmentをデータベースとして利用しており、Key Value Storeで実装されている。
+従来のKey Value StoreのようにKey と Valueが一対になっているのではなく、Key毎にキューを持っていてデータを管理している。
+そのキューに対してData Segment API を用いることでData Segmentにデータを追加、削除を適宜行うことができる。
+
 
 \begin{itemize}
 \item \verb+void put(String key, Value val)+
@@ -86,7 +89,8 @@
 \end{itemize}
 
 
-\verb+put はデータを追加するための API である。
+
+\verb+put+ はデータを追加するための API である。
 % キューというのが何か説明する
 \verb+update+ はデータを置き換えるための API である。 キューの先頭を置き換える特急メッセージのように動作する。
 \verb+peek+ はデータを調べるためのAPIである。目的のData Segment がなければ、Code Segment の待ち合わせ (Blocking) が起きる。
@@ -103,12 +107,17 @@
 \end{center}
 \end{figure}
 
+
+
 \section{水族館ゲーム}
 % 魚の位置が共有されている
 % 複数のディスプレイに異なる視点で表示される
 % 魚とディスプレイが増えてもサービスを維持できることを確認するため
 % このままではスケールしない
-Aliceを用いて水族館ゲームの作成を行った。水族館ゲームとは複数のclientのディスプレイを並べて使用する。アプリケーションを実行するとウインドウが表示され、複数の魚がウインドウの中を泳ぎ始める。魚は画面の端まで移動すると自分の画面上からは消え、隣のプレイヤーの画面の端から出てくるものである。
+Aliceを用いて水族館ゲームの作成を行った。水族館ゲームとは複数の魚の情報をゲームに参加するClinet全体で共有し、複数のディスプレイに異なる視点で表示されるものである。トポロジーはツリー状に構成されている。
+
+
+水族館ゲームを作成した目的は魚とディスプレイが増えてもサービスを維持できることを確認するためである。しかし、現状では魚の数、参加するClinetが増えるとトップノードが処理すべきCode Segmentが増加していくため、このままではスケールしないと思われる。
 
 
 以前水族館ゲームをJava3Dで作成したが、JavaのVersion が1.7になったのに伴いJava3Dが使用不可になった。しかしJavaFXというGUIプラグインが追加されたため、JavaFXで水族館ゲームを書きなおした。(図 \ref{fig:JavaFX})また、描画部分がJava3DからJavaFXに変わっただけであるので、それぞれで魚の情報を共有することが可能である。
@@ -133,15 +142,37 @@
 %\lstinputlisting[label=fig:NullPointerException, caption=実行するとNullPointerExceptionを起こす]{source/NullPointerException.java}
 %\end{table}
 
+
+\section{実験}
+トップノードから子ノードに対してデータの送信し、子ノードは受けとったデータをトップノードに送り返す。この作業にかかる時間を測定し、子ノードの数を増やしていくことで台数が増えた際の時間の変化により、スケールするかどうかを評価する。マシン 48 台,CPU Intel(R) Xeon(R) X5650 @ 2.67GHz, 仮想コア数 4,CPU キャッシュ 12MB。Blade 上の仮想マシン上での測定を行った。
+
+
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics[width=90mm]{pic/result2.pdf}
+\caption{測定結果}
+\label{fig:result2}
+\end{center}
+\end{figure}
+
+\section{考察}
+サービスに参加するClientの数が増加するに連れて、データを受信するまでの時間が増加していく。これはトップノードがData Segmentを子ノードに送信するというCode SegmentがThread Poolが次々に送られてくるが、同時実行できるのはCPU数までなので、Client数が増えるに従ってThread Poolで実行されるのを待つ時間が増えていくのではないかと思われる。
+
+
 % 今後の課題ではなくて、今のAPIの評価を行う
-\section{今後の課題}
-今回の実装は、Java により Code Segment と Data Segment に必要な API を洗い出すためのものであった。この実装でもいくつかの問題が明らかになっている。
-\subsection{API}
-Classを継承したり、Input Data SegmentやOutput Data Segmentの作成にfactory objectを使うのはJavaを使う際の技術できなものであり、AliceのAPI自体はJavaに固有である必要はない。むしろ、JavaのObject指向な記述が全体を煩雑にしている部分もある。updateはData Segmentの競合的な更新に使われるべきではないかと思われる。
-\subsection{Message Pack}
-単純なMessageの転送の場合にもMessage Packのdecode / encodeが必要になるが、overheadにしかならないので、encode / decode 抜きに処理できる方が望ましい。また、Data Segmentの一部修正にData Segmentを再構成を行うのは望ましくない。CeriumではInput DSとOutput DSをswapするAPIがあり、良好な結果が得られているのでAliceにも導入したい。ユーザーが特に記述しなくてもKeyを見て内部で自動的に判断したほうが望ましいと思われるが、何かしらの制御方法も必要だと思われる。
+\section{APIの評価}
+現在、Aliceが提供されているAPIだけで分散プログラムを記述することが可能であったものの、追加、改善したほうがよいAPIがいくつかある。
+
+
+\verb+setKey+ は呼ぶタイミングを気をつけなければ、NullPointerExceptionになる事がわかった。\verb+setKey+ 以降に処理を記述しても実行される前にactiveになってしまう可能性がある。従って\verb+setKey+ の方法を考えなおさなければならない。
+
+
+\verb+peek+ でData Segmentを取得、\verb+put+ でData Segmentの追加を行なっているが、この際にMessage Packでdecode / encodeの操作が毎回行われている。
+他のClientに対してデータの送受信するために行われている場合は仕方ないが、local に対してこれらを行う必要はないので、localに対しての送受信はencode / decode 抜きに処理できるようにするのが望ましい。
+
+\section{Aliceの問題点}
 \subsection{Java}
-Aliceの全てのData SegmentはKVSに格納され、実行時のData SegmentはCode Segmentが activeな時のみメモリ上にある。この最大値は同時にActive Taskの量を見積もれば良い。従って、AliceにGCは必要ない。一方で、KVS上のデータは決してGCの対象にならない。しかし、それではGCに付加をかけてしまう。Alice自体はJavaで実装するのには向いていない。
+Aliceの全てのData SegmentはKVSに格納され、実行時のData SegmentはCode Segmentが activeな時のみメモリ上にある。この最大値は同時にActive Taskの量を見積もれば良い。従って、AliceにGCは必要ない。一方で、KVS上のデータは決してGCの対象にならない。しかし、それではGCに付加をかけてしまう。
 \subsection{Key}
 本実装ではData Segment相互の参照はKey経由となる。分散実装では妥当であるが、並列実装ではすべてのData SegmentをKVSに格納するのは性能的な問題を引き起こす。一方で、分散記述と並列記述がかけ離れてしまうのも好ましくない。また、本来はKVSは持続性を持つべきだと思われる。持続性をもつことで、トラブルで処理が途中で中断された場合であっても途中から処理を再開可能となる。
 \thispagestyle{fancy}