--- a/paper-last/prosym.tex	Mon Nov 30 18:35:42 2015 +0900
+++ b/paper-last/prosym.tex	Tue Dec 01 00:07:29 2015 +0900
@@ -35,7 +35,7 @@
 \title{分散フレームワークAliceのPC画面配信システムへの応用}
 \affiliate{IE}{琉球大学工学部情報工学科}
 \author{照屋 のぞみ}{Nozomi Teruya}{IE}
-\author{河野 真治}{Shinji Kono, kono@ie.u-ryukyu.ac.jp}{IE}
+\author{河野 真治}{Shinji Kono}{IE}[kono@ie.u-ryukyu.ac.jp]
 
 \begin{abstract}
 当研究室ではデータを Data Segment、タスクを Code Segment という単位で分割して記述する手法を提唱しており、それに基づく並列分散フレームワークAliceを開発している。
@@ -52,7 +52,7 @@
 
 % Body %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \section{研究背景と目的}
-当研究室ではデータをData Segment、タスクをCode Segmentという単位で記述する分散フレームワークAlice\cite{senkokenkyu} の開発を行っている。
+当研究室ではデータをData Segment、タスクをCode Segmentという単位で記述する分散フレームワークAlice\cite{senkokenkyu}\cite{senkokenkyu2} の開発を行っている。
 Aliceではスケーラブルな分散プログラムを信頼性高く記述できる環境を実現する。
 ここで言う信頼性とは、定められた環境下で安定して仕様に従った動作を行うことを指す。
 
@@ -61,12 +61,11 @@
 プログラマはコアな仕様の変更を抑えつつプログラムの挙動変更ができるため、信頼性の高い分散アプリケーションの記述が可能となる。
 
 本研究では、Alice上に実用的な分散アプリケーションの例題である画面共有システムTreeVNC \cite{treeVNC} を構築する。
-画面変更の差分を木構造にそって配布する分散システムで、差分は数MByteに達するので圧縮を行う必要がある。
-ノード間の転送では複製を可能な限り避ける必要がある。表示時には伸長したデータを取り扱うことになる。
-差分データはData Segementに対応するが、圧縮やゼロコピー転送の機能が必要なる。
-これらの機能はTreeVNCではad-hocに実装されているが、
-Aliceでは、これをMeta Computationとして実装する。
-TreeVNCとの比較を行うことでAlice の実用性を示すと共にAlice のMeta Computationの役割と有効性を示す。
+TreeVNCは画面変更の差分を木構造にそって配布する分散システムで、差分は数MByteに達するので圧縮を行う必要がある。そして表示時には伸長したデータを取り扱わなければならない。
+また、データのノード間の転送では複製を可能な限り避ける必要がある。
+差分データはAliceのData Segementに対応するため、Data Segmentを扱うAliceの機能として圧縮やゼロコピー転送の機能が必要なる。
+これらの機能はTreeVNCではad-hocに実装されているが、AliceではこれをMeta Computationとして実装する。
+そして、TreeVNCとの比較を行うことでAlice の実用性を示すと共にAlice のMeta Computationの役割と有効性を示す。
 
 \section{分散フレームワークAlice}
 \subsection{Code Segment と Data Segment}
@@ -86,16 +85,17 @@
 AliceはJavaで実装されており、DSはJava Objectに相当する。CSはRunnableなObject(void run()を持つObject)に相当する。
 プログラマがCSを記述する際は、CodeSegmentクラスを継承する。
 
-DSは数値や文字列などの基本的なデータの集まりを指し、Aliceが内部にもつデータベースによって管理されている。このデータベースをAliceではDS Manager（以下DSM）と呼ぶ。
+DSは数値や文字列などの基本的なデータの集まりを指し、Aliceが内部にもつデータベースによって管理されている。このデータベースをAliceではDS Managerと呼ぶ。
 
-CSは複数のData Segment Managerを持っている。それぞれのManagerにString型のkeyを指定してData Segmentにアクセスする。
+CSは複数のDS Managerを持っている。DSには対になるString型のkeyが存在し、それぞれのManagerにkeyを指定してDSにアクセスする。
 一つのkeyに対して複数のDSをputするとFIFO的に処理される。なのでData Segment Managerは通常のデータベースとは異なる。
 
-\subsection{DataSegmentManager}
+\subsection{Data Segment Manager}
 
-DSMにはLocal DSMとRemote DSMが存在する。Local DSMは各ノード固有のデータベースである。
+DS Manager（以下DSM）にはLocal DSMとRemote DSMが存在する。Local DSMは各ノード固有のデータベースである。
 Remote DSMは他ノードのLocal DSMに対応するproxyであり、接続しているノードの数だけ存在する（図 \ref{fig:Remote DSM} ）。
 他ノードのLocal DSMに書き込みたい場合はRemote DSMに対して書き込めば良い。
+
 Remote DSMを立ち上げるには、DataSegmentクラスが提供するconnectメソッドを用いる。
 接続したいノードのipアドレスとport番号、そして任意のManager名を指定することで立ちあげられる。その後はManager名を指定してData Segment APIを用いてDSのやり取りを行うため、プログラマはManager名さえ意識すればLocalへの操作もRemoteへの操作も同じ様に扱える。
 
@@ -152,18 +152,17 @@
 TestCodeSegmentはこの"cnt"というkeyに対して依存関係があり、8行目でputが行われるとTestCodeSegmentは実行される。
 
 
+CSのInput DSは、CSの作成時に指定する必要がある。指定はCommandType(PEEKかTAKE)、DSM名、そしてkey よって行われる。
+Input DS API はCSの{\tt ids}というフィールドを用いてアクセスする。
+Output DSは、{\tt ods}が提供するput/updateメソッドをそのまま呼べばよかったが、Input DSの場合{\tt ids}にpeek/takeメソッドはなく、create/setKeyメソッド内でCommandTypeを指定して実行する。
+
 ソースコード\ref{src:CodeSegment}は、0から9までインクリメントする例題である。
-CSのInput Data Segement はCSの作成時に指定する必要がある。指定はCommandType(PEEKかTAKE)、DSMを指定する文字列("local","remote")、それから、
-key よって行われる。
-Input DS APIがもつcreateメソッドを使うことでInput DSを格納する受け皿(Receiver)を作る。
+2行目では、Input DS APIがもつcreateメソッドでInput DSを格納する受け皿(Receiver)を作っている。
+引数には{\tt PEEK}または{\tt TAKE}を指定する。
 \begin{itemize}
 \item {\ttfamily Receiver create(CommandType type)}
 \end{itemize}
 
-引数にはCommandTypeが取られ、指定できるCommandTypeは{\tt PEEK}または{\tt TAKE}である。
-Input DS API はCSの{\tt ids}というフィールドを用いてアクセスする。
-Output DSは、{\tt ods}が提供するput/updateメソッドをそのまま呼べばよかったが、Input DSの場合{\tt ids}にpeek/takeメソッドはなく、create/setKeyメソッド内でCommandTypeを指定して実行する。
-
 4行目から6行目はコンストラクタである。コンストラクタはオブジェクト指向のプログラミング言語で新たなオブジェクトを生成する際に呼び出されて内容の初期化を行う関数である。
 
 % TestCodeSegmentのコンストラクタが呼ばれた際には、
@@ -172,7 +171,7 @@
 % \item 5行目にあるTestCodeSegmentのコンストラクタのTAKEが実行される。
 % \end{enumerate}
 
-5行目はInput DS APIがもつsetKeyメソッドによりLocal DSMからDSを取得している。
+5行目は、2行目のcreateで作られたReceiverが提供するsetKeyメソッドを用いてLocal DSMからDSを取得している。
 \begin{itemize}
 \item \verb+void setKey(String managerKey, String key)+
 \end{itemize}
@@ -198,8 +197,22 @@
 AliceではMeta Computationとして分散環境の構築等の機能を提供するため、プログラマはCSを記述する際にトポロジー構成や切断、再接続という状況を予め想定した処理にする必要はない。
 プログラマは目的の処理だけ記述し、切断や再接続が起こった場合の処理をMeta Computationとして指定する。
 このようにプログラムすることで、通常処理と例外処理を分離することができるため、仕様の変更を抑えたシンプルなプログラムを記述できる。
+
+Meta Computationは、CSの処理を支えるMeta CSと、Meta CSに管理されるMeta DSとしても考えられる。
+図\ref{fig:metaCS}は、AliceのMeta CS/Meta DSの接続関係の例である。
+プログラマ側はCSとDSの依存関係を記述するが、その裏ではMeta CSやMeta DSが間に接続されて処理を行っている。
+
+\begin{figure}[h]
+    \begin{center}
+        \includegraphics[width=70mm]{images/metaCS.pdf}
+    \end{center}
+    \caption{CS/DSの間にMetaCS/MetaDSが接続される}
+    \label{fig:metaCS}
+\end{figure}
+
 現在Aliceには、動的・静的トポロジーの管理構成機能、ノードとの接続状態確認機能、切断・再接続時の処理を指定できる機能など、分散環境の実現に必要なさまざまなMeta Computationが用意されている。
 
+　
 
 \textbf{Topology Manager}
 
@@ -231,6 +244,8 @@
 現在Topology Managerでは動的なトポロジータイプとして二分木に対応している。
 
 
+　
+
 \textbf{KeepAlive}
 
 ノード間通信はRemote DSMに対してputやtakeを行うことでのみ発生する。
@@ -242,32 +257,9 @@
 
 また、トポロジーからノードが切断された際にトポロジーを再構成する機能もTopology Managerに用意した。
 例えばツリートポロジーでノードが切断された場合、そのノードの子ノードは全体のトポロジーから分断されてしまう。
-ノードは切断を検知するとただちにTopology Managerに再接続すべきノード情報を要求し、木を構成し直す(図\ref{fig:topfix1} 〜 \ref{fig:topfix3})。
+ノードは切断を検知するとただちにTopology Managerに再接続すべきノード情報を要求し、木を構成し直す。
+
 \newpage
-\begin{figure}[h]
-\begin{center}
-\includegraphics[width=70mm]{images/TopologyFix.pdf}
-\end{center}
-\caption{切断ノードの検知}
-\label{fig:topfix1}
-\end{figure}
-\begin{figure}[h]
-\begin{center}
-\includegraphics[width=70mm]{images/TopologyFix2.pdf}
-\end{center}
-\caption{接続すべきノード情報の送信}
-\label{fig:topfix2}
-\end{figure}
-\begin{figure}[h]
-\begin{center}
-\includegraphics[width=70mm]{images/TopologyFix3.pdf}
-\end{center}
-\caption{再構成の完了}
-\label{fig:topfix3}
-\end{figure}
-\newpage
-
-
 
 \textbf{切断・再接続時の処理}
 
@@ -324,7 +316,7 @@
 圧縮状態のまま子ノードに送信ができれば、解凍・再圧縮するオーバーヘッドを無くすことができる。
 
 そこで、１つのData Segmentに対し複数の表現を持たせ、必要に応じた形式でDSを扱うことを可能にした。
-DSのMeta Computationに相当するReceiveDataクラスに、次の3種類の表現を同時に持つことができるようにしたことで、データの多態性を実現した。
+Meta DSに相当するReceiveData.classに、次の3種類の表現を同時に持つことができるようにしたことで、データの多態性を実現した。
 
 \begin{enumerate}
   \item 一般的なJavaのクラスオブジェクト
@@ -341,6 +333,7 @@
 {\tt val}に(1) 一般的なJavaのクラスオブジェクト の表現でデータ本体が保存される。
 {\tt messagePack}には(2) シリアライズ化されたバイナリオブジェクトが保存される。
 そして、{\tt zMessagePack}には(3) 圧縮されたバイナリオブジェクトが保存される。
+このようにDSが複数の表現を同時に保持することで、DSが圧縮表現を持っている場合に再圧縮する必要はない。
 
 \begin{table}[html]
 \lstinputlisting[label=src:ReceiveData, caption=データを表現するクラス]{source/ReceiveData.java}
@@ -364,18 +357,13 @@
 ノードは圧縮されたDSを受け取った後、そのまま子ノードにflipメソッドで転送すれば圧縮状態のまま送信されるので、送信の際の再圧縮がなくなる。
 
 
-画面表示の際はReceiveData.class内のasClassメソッド(ソースコード\ref {src:asClass} )を使うことで適切な形式でデータを取得できる。
+画面表示の際はReceiveData.class内のasClassメソッドを使うことで適切な形式でデータを取得できる。
 asClassメソッドはDSを目的の型にcastするためのメソッドである。
 AliceVNCで圧縮形式を指定してDSを送信すると、それを受け取るDSMは圧縮形式のみを持ったDSとして保存する。
 そしてasClassメソッドが呼ばれて初めて、メソッド内で解凍してcastが行われDSが複数の表現を同時に持つようになる。
 これによりDSの表現を必要になったときに作成できるため、プログラマはどんな形式でDSを受け取ってもDSを編集可能な形式として扱うことができる。
 また、複数表現は必要なときにしか作成されないため、メモリ使用量も必要最低限に抑えることができる。
 
-
-\begin{table}[html]
-\lstinputlisting[label=src:asClass, caption=asClassの処理]{source/asClass.java}
-\end{table}
-
 \subsection{Aliceの通信プロトコルの変更}
 5.2で述べたように、Remoteからputされたデータは必ずシリアライズ化されておりbyteArrayで表現される。
 しかし、データの表現に圧縮したbyteArrayを追加したため、RemoteからputされたbyteArrayが圧縮されているのかそうでないのかを判別がつかなくなった。
@@ -386,7 +374,7 @@
 
 \section{評価と考察}
 TreeVNCをAlice上で構築するために必要な機能をAliceのMeta Computationとして実装した。
-それにより、AliceVNCが簡潔な記述でTreeVNCと同等の性能を出せれば、実用的な分散アプリケーションの実装においてAliceのMeta Computationは有用であるといえる。
+これにより、AliceVNCが簡潔な記述でTreeVNCと同等の性能を出せれば、実用的な分散アプリケーションの実装においてAliceのMeta Computationは有用であるといえる。
 そこで、TreeVNCとAliceVNCの性能評価としてメッセージ伝達速度の比較を、コードの評価としてコード量とその複雑度の比較を行った。
 
 また、AliceのMeta Computationの価値を明確にするため、他言語・フレームワークとの比較を行った。
@@ -395,24 +383,22 @@
 TreeVNC/AliceVNCにおいて、配信する画像データは構成した木を伝ってノードに伝搬され、接続する人数が増える毎に木の段数は増えていく。
 そこで、木の段数ごとにメッセージの到達にどれぐらい時間がかかっているかを計測した。
 
+　
+
 \textbf{実験環境}
 
 講義内で学生に協力してもらい、最大17名の接続がある中でTreeVNC、AliceVNC(圧縮・転送機能あり)、AliceVNC(圧縮・転送機能なし)の木の段数1〜3の測定を行った。
 
+　
+
 \textbf{実験内容}
 
 ルートノードから画面データを子ノードに伝搬する際に、計測用のヘッダをつけたパケットを子ノードに送信する。
-各子ノードはパケットを受け取り自身のViewerに画面データを表示すると同時に、計測用ヘッダ部分のみのDSを作成し、親ノードに送り返す（図 \ref{fig:mesure}） 。
+各子ノードはパケットを受け取り自身のViewerに画面データを表示すると同時に、計測用ヘッダ部分のみのDSを作成し、親ノードに送り返す。
 計測用DSは木を伝ってルートノードまで送り返され、ルートノードは受け取った計測用DSから到達時間を計算する。
-\begin{figure}[h]
-    \begin{center}
-        \includegraphics[width=70mm]{images/delay.pdf}
-    \end{center}
-    \caption{各ノードごとに到達時間を測定}
-    \label{fig:mesure}
-\end{figure}
 
 計測用のヘッダは以下の要素で構成されている。
+\newpage
 \begin{table}[htbp]
 \caption{計測用ヘッダの変数名の説明}
 \label{tb:mesure}
@@ -434,28 +420,21 @@
 今回、TreeVNCとAliceVNC(圧縮・転送機能あり)では圧縮形式の画面データのサイズを、AliceVNC(圧縮・転送機能なし)ではMessegePack形式でのサイズをdataSizeにセットする。
 depthは各ノードに到達するごとにインクリメントされる。
 
-計算方法をソースコード \ref{src:mesurement}に示す。
-到達時間は、計測用DSを受け取った時刻とDSのtime（送信した時刻）の差をとる。
+到達時間の計算方法は、計測用DSを受け取った時刻とDSのtime（送信した時刻）の差をとる。
 この到達時間は画面データがノードまで到達した時間と計測DSをルートまで送り返す時間を含めているが、送り返す時間は誤差として考える。
 また、depthは各ノードに到達するごとにインクリメントされるため、送り返す際もインクリメントされる。そのため、木の段数を計算するにはdepthを1/2した値となる。
 
-\begin{table}[html]
-\lstinputlisting[label=src:Mesurement, caption=到達時間・木の段数の計測方法]{source/mesurement.java}
-\end{table}
+　
 
 \textbf{実験結果}  
 
-3段目の測定結果の散布図を示す（図\ref{fig:TreeVNC_delay} 〜 \ref{fig:AliceVNC_notcompress_delay}）。
+3段目の測定結果の散布図を示す（図\ref{fig:TreeVNC_delay} 〜 \ref{fig:AliceVNC_compress_delay}）。
 X軸が画面データのサイズ(byte)、Y軸が計算した到達時間(ms)である。
 実験時間の都合上、AliceVNC（圧縮・転送機能あり）の計測時間が他より短くなってしまったためプロットされた点の数が少なくなっている。
 また、それぞれの図で処理に10000ms以上かかっている点の集合が見られるが、これは今回の実験において3段目にPCのスペック上処理が遅いノードが1台あったためである。そのため比較においてこの点集合は無視する。
 
 どの図も同様の傾向があり、画面データのサイズが小さいうちは処理時間も5ms程度だが、50000byte以上から比例して処理時間も遅くなっている。このことからAliceVNCはTreeVNCと同等の処理性能があることがわかる。
 
-また、AliceVNCを圧縮機能の有無でデータサイズ比較すると、圧縮機能のないAliceVNCはデータサイズがほとんど1000byte以上なのに対し、圧縮機能のあるAliceVNCではTreeVNC同様10byte程度のサイズに抑えるので圧縮も成功している。
-
-さらに転送機能の有無で比較した場合、転送機能がないAliceVNCでは木の段数に関係なく1000ms近く到達に時間がかかってしまっているが、転送機能のあるAliceVNCではデータサイズが大きくなっても100ms程度に抑えられている。これは転送機能が余計なコピーを防いでいるためだと考えられる。
-このことから、圧縮・転送のMeta Computationは分散通信において有用であると言える。
 \newpage
 \begin{figure}[h]
     \begin{center}
@@ -482,6 +461,11 @@
 \end{figure}
 \newpage
 
+
+また、AliceVNCを圧縮機能の有無でデータサイズ比較すると、圧縮機能のないAliceVNCはデータサイズがほとんど1000byte以上なのに対し、圧縮機能のあるAliceVNCではTreeVNC同様10byte程度のサイズに抑えるので圧縮も成功している。
+
+さらに転送機能の有無で比較した場合、転送機能がないAliceVNCでは木の段数に関係なく1000ms近く到達に時間がかかってしまっているが、転送機能のあるAliceVNCではデータサイズが大きくなっても100ms程度に抑えられている。これは転送機能が余計なコピーを防いでいるためだと考えられる。
+このことから、圧縮・転送のMeta Computationは分散通信において有用であると言える。
 \subsection{コードの比較}
 \textbf{コード量}
 
@@ -511,7 +495,7 @@
 \end{center}
 \end{table}
 
-
+　
 \textbf{コードの複雑度}
 
 コード量の比較で述べたように、TreeVNCはTightVNCからの変更が多い。
@@ -585,12 +569,12 @@
 分散通信部分を子アクターに分離し、親アクターは子アクターのExceptionが発生した時に再起動や終了といった処理を指定できる。
 さらにRouterという子アクターへのメッセージの流れを制御するアクターや、Dispatcherというアクターへのスレッドの割当を管理する機能をAkkaが提供している。
 このように処理を階層化し複雑な処理をフレームワーク側が提供する仕組みはAliceのMeta Computationと共通している。
-相違点としては、AliceのMeta Computationでは圧縮機能のようにデータに対するMeta Computationも扱っている点が挙げられる。
+相違点としては、AliceのMeta DSのようにデータの多態性を実現する機能はAkkaにはない。
 
 
 \section{まとめ}
 並列分散フレームワークAliceでは、スケーラブルかつ信頼性の高いプログラムを記述する環境を実現するため、CS/DSの計算モデルとMeta Computationによる実装の階層化を採用している。
-Aliceが実用的な分散アプリケーションを記述するために必要なMeta Computationとして、動的なトポロジー管理・構成機能や多態性を持つデータを扱う機能、データを無駄なコピーをすることなく転送する機能などを実装した。
+Aliceが実用的な分散アプリケーションを記述するために必要なMeta Computationとして、多態性を持つデータを扱う機能や無駄なコピーなくデータを転送する機能を実装した。
 そしてMeta Computationを用いて分散アプリケーションTreeVNCをAlice上で実装し性能評価を行った。
 その結果、TreeVNCで使用される基本機能はAliceでも実現でき、同等の性能を出すことができるということが分かった。
 またコードの観点からTreeVNCとAliceVNCを比較した結果、Aliceが仕様の変更を抑えたシンプルな記述を実現し、信頼性の高い実用的な分散アプリケーションを構築するに有用であることが確認された。