Papers/2018/nozomi-master: paper/nozomi-master.tex comparison

comparison paper/nozomi-master.tex @ 174:f0e9cc7d13f9

minor change

author	Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
date	Mon, 05 Feb 2018 16:38:28 +0900
parents	52a43c1336d9
children	7e7fe5e28ba4

comparison

equal deleted inserted replaced

-:52a43c1336d9
+:f0e9cc7d13f9
 またスケーラビリティーとは、分散ソフトウェアに対して単純にノードを追加するだけで性能を線形的に上昇させることができる性質である。
 しかし、これらをもつ分散プログラムをユーザーが一から記述することは容易ではない。
 なぜなら、並列で動く分散した資源を意識しながら記述するのは容易ではなく、また、どのように分散したノードの選択を行えば良いのか明確ではないからである。
-分散プログラムには以下の３つの要素がある。
+分散プログラムには以下の３つの要素がある\cite{Framework}。
 \begin{itemize}
 \item {ノード内の計算}
 \end{itemize}
 \begin{itemize}
 Aliceは、タスクをCode Segment、データをData Segmentという単位で記述し、Code SegmentはインプットとなるData Segmentが全て揃うと並列に実行される。
 Data Segmentは対になるkeyが存在し、Data Segment Managerというノードごとに存在する独自のデータベースによって管理されている。
 各ノードにはラベル付きのプロキシであるRemote Data Segment Managerを立て、ラベルとkeyを指定してデータをtake/putするプロトコルとなっている。
-%Topologymanagerもここにかく？
+\newpage
+記述の面において、Akkaでは基本的にメッセージをFIFO的に処理するため、複数のインプットを待ち合わせる場合は、待ち合わせの処理をプログラマが各必要があった。
-\newpage
+しかしAliceは複数のインプットを1箇所に記述するるため、そのような煩雑さがない。
-%問題といったら参考文献が必要,わかりづらいとハッキリ書かない
-記述の面において、Akkaではメッセージが集中した場合にそれを処理するパターンマッチが増えてしまう問題や、複数のインプットを待ち合わせる際に記述が煩雑になる問題があった。
-しかしAliceはインプットを明確に記述でき、複数のインプットを持てる。
 プロトコルの設計方針において、AkkaやHazelcastは分散通信の複雜さを抽象度を高めることで隠す方針であるため、ロケーション透過性が高く、プログラマからは処理の流れを把握しにくくなっていた。
-一方でAliceは分散計算のチューニングをメタ計算として行う。これによりメタ計算から分離された処理の流れを明確にすることができる。
+一方でAliceでは明示的に分散性を意識する代わりに、計算を通常計算とそれを支えるメタ計算として分離することで記述の複雑さを回避している。
+これにより処理の流れを明確にし、分散計算のチューニングをしやすくしている。
-Alice の分散ノード間の通信はラベルを用いてリモートノードを選択することによって指定する。
-Akkaでは送り先をドメインで指定しているのと同様である。Alice ではラベルはToplogy managerによって自動的に指定される。
+また、Aliceの分散ノード間の通信はラベルを用いてリモートノードを選択することによって指定する。
+これはAkkaで送り先をドメインで指定しているのと同様である。
-% このように、Aliceのプロトコルの特徴は分散処理の見通しの良さといえる。Alice は Java 上に実装されており、Javaのオブジェクト生成や
+Aliceではラベルの命名をToplogy Managerによって自動的に指定することもできる。
-% 継承により記述されている
-%しかし、現状のAliceのAPIシンタックスは直感的でなく、プログラマが処理の順番やデータの型を考慮して書く必要があった。
-%これではバグを引き起こす可能性が高いため、信頼性を上げるにはよりユーザーフレンドリーなシンタックスで再設計すべきだと考えた。
 \section{トポロジーの構成}
 AkkaではAkka Streamという機能で処理の流れが記述できる。
 N入力1出力、1入力N出力、出力のみ、などが用意されたJunctionsと呼ばれる要素をつなぎ合わせることでトポロジーを記述する。
 一つのkeyに対して複数のDSをputするとFIFO的に処理される。なのでData Segment Managerは通常のデータベースとは異なる。
 \section{DataSegmentManager}
-DS 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} ）。
+Remote DSMは他ノードのLocal DSMに対応するproxyであり、接続しているノードの数だけ存在する(図 \ref{fig:Remote DSM} )。
 他ノードのLocal DSMに書き込みたい場合はRemote DSMに対して書き込めば良い。
 \newpage
 \begin{figure}[h]
 り出すのは無駄である。flipはDSを受け取った形式のまま転送するため無駄なコピーなくDSの保存ができる。
 \begin{itemize}
 \item {\ttfamily void take(String managerKey, String key)}
 \end{itemize}
-takeはDSを読み込むためのAPIである。読み込まれたDSは削除される。要求したDSが存在しなければ、CSの待ち合わせ （Blocking）が起こる。putやupdateによりDSに更新があった場合、takeが直ちに実行される。
+takeはDSを読み込むためのAPIである。読み込まれたDSは削除される。要求したDSが存在しなければ、CSの待ち合わせ (Blocking)が起こる。putやupdateによりDSに更新があった場合、takeが直ちに実行される。
 \begin{itemize}
 \item {\ttfamily void peek(String managerKey, String key)}
 \end{itemize}
 peekもDSを読み込むAPIである。takeとの違いは読み込まれたDSが削除されないことである。
 \newpage
 \section{CodeSegmentの記述方法}
-CSをユーザーが記述する際にはCodeSegmentクラスを継承して記述する(ソースコード \ref{src:StartCodeSegmen
+CSをユーザーが記述する際にはCodeSegmentクラスを継承して記述する(ソースコード \ref{src:StartCodeSegment} , \ref{src:CodeSegment})。
-t} , \ref{src:CodeSegment})。
 継承することによりCode Segmentで使用するData Segment APIを利用する事ができる。
 Alice には、Start CS (ソースコード \ref{src:StartCodeSegment} )というC の main に相当するような最初に
 実行される CS がある。
 \lstinputlisting[label=src:StartCodeSegment, caption=StartCodeSegmentの例]{source/StartCodeSegment.java}
 \lstinputlisting[label=src:CodeSegment, caption=CodeSegmentの例]{source/TestCodeSegment.java}
 \newpage
-ソースコード \ref{src:StartCodeSegment} は、5行目で次に実行させたいCS（ソースコード \ref{src:CodeSegment} ）を作成している。
+ソースコード \ref{src:StartCodeSegment} は、5行目で次に実行させたいCS(ソースコード \ref{src:CodeSegment} )を作成している。
 8行目でOutput DS APIを通してLocal DSMに対してDSをputしている。
 Output DS APIはCSの{\tt ods}というフィールドを用いてアクセスする。
 {\tt ods}は{\tt put}と{\tt update}と{\tt flip}を実行することができる。
 TestCodeSegmentはこの"cnt"というkeyに対して依存関係があり、8行目でputが行われるとTestCodeSegmentは実
 行される。
 仕様の変更を抑えてプログラムの拡張ができるということは、コードを破壊しないため変更以前の信頼性を保てるということである。
 Meta ComputationもCS/DSで作られており、プログラマ側から見えないこれらのCS/DSはMeta CS/Meta DSと呼ばれる。
 現在Aliceには、データの圧縮機能、トポロジーの構成・管理機能、ノードの生存確認機能、ノードの切断・再接続時の処理管理機能などのMeta Computationが用意されている。
+これらの有用性は水族館の例題\cite{Aquarium}やTreeVNCの例題\cite{TreeVNC}\cite{AliceVNC}によって示された。
 \newpage
 \subsection{Aliceの圧縮機能}
 リモートノードに大きなデータを送るために、データを圧縮したい場合がある。
 そこで、Aliceは圧縮をサポートしている。
 しかし、単に圧縮のメソッドを用意したわけではない。
-圧縮データの展開と、圧縮したまま別ノードへの転送を同時に実現したい場合があるため、Meta CSを介すことでDSに圧縮と非圧縮のデータを同時に持てるようにしている（図\ref{fig:compress}）。
+圧縮データの展開と、圧縮したまま別ノードへの転送を同時に実現したい場合があるため、Meta CSを介すことでDSに圧縮と非圧縮のデータを同時に持てるようにしている(図\ref{fig:compress})。
 \begin{figure}[h]
 \begin{center}
 \includegraphics[width=160mm]{images/compress.pdf}
 \end{center}
 1つのDS内にMeta DSとして以下の３つの表現を持たせることでデータに多態性を持たせ、必要に応じた形式でDSを扱う。
 \begin{enumerate}
 \item 一般的なJavaのクラスオブジェクト
-\item MessagePack for Java\cite{}でシリアライズ化されたバイナリオブジェクト
+\item MessagePack for Java\cite{MessagePack}でシリアライズ化されたバイナリオブジェクト
 \item 2を圧縮したバイナリオブジェクト
 \end{enumerate}
 Local DSMにputされた場合は、(1)の一般的なJavaクラスオブジェクトとして追加される。
 Remote DSMにputされた場合は、通信時に(2)のbyteArrayに変換されたバイナリオブジェクトに変換されたDSが追加
 Local/Remote DSMにDSを圧縮して保存したい場合は(3)の圧縮形式を用いる。
 \newpage
 データの圧縮を指定するには、putするDSMの名前の前に"compressed"をつけるだけでよい。
-\ref{src:before},\ref{src:after}は通常のDSと圧縮のDSを扱う際の記述の例である。
+ソースコード\ref{src:before},\ref{src:after}は通常のDSと圧縮のDSを扱う際の記述の例である。
 \lstinputlisting[label=src:before, caption=通常のDSを扱うCSの例]{source/beforeCompress.java}
 \lstinputlisting[label=src:after,caption=圧縮したDSを扱うCSの例]{source/afterCompress.java}
 このようにコードの変更を抑えて圧縮できるため、他の計算部分を変えずにデータ形式が指定できる。
 \subsection{TopologyManager}
 Aliceでは、ノード間の接続管理やトポロジーの構成管理を、Topology ManagerとTopology NodeというMeta Computationが提供している。
 プログラマはトポロジーファイルを用意し、Topology Managerに読み込ませるだけでトポロジーを構成することができる。
-トポロジーファイルはDOT Language\cite{}という言語で記述される。
+トポロジーファイルはDOT Language\cite{dot}という言語で記述される。
-DOT Languageとは、プレーンテキストを用いてデータ構造としてのグラフを表現するためのデータ記述言語の一
+DOT Languageとは、プレーンテキストを用いてデータ構造としてのグラフを表現するためのデータ記述言語の一つである。
-つである。
 ソースコード\ref{src:topologyfile}は3台のノードでリングトポロジーを組むときのトポロジーファイルの例である。
 \lstinputlisting[label=src:topologyfile, caption=トポロジーファイルの例]{source/TopologyFile.dot}
 DOT Languageファイルはdotコマンドを用いてグラフの画像ファイルを生成することができる。そのため、記述したトポロジーが正しいか可視化することが可能である。
-Topology Managerはトポロジーファイルを読み込み、参加を表明したクライアント（以下、Topology Node）に接続するべきクライアントのIPアドレスやポート番号、接続名を送る（図\ref{fig:topologymanager}）。
+Topology Managerはトポロジーファイルを読み込み、参加を表明したクライアント(以下、Topology Node)に接続するべきクライアントのIPアドレスやポート番号、接続名を送る（図\ref{fig:topologymanager}）。
 \newpage
 \begin{figure}[h]
 \begin{center}
 \section{APIの記述の分離}
 2.4で示したように、InputDSを記述するには、一度フィールドでReceiverをcreateして、その後Reveiverに対してsetKeyで待ち合わせるkeyを指定しなければならない。
 このようにインプットの処理が分離されてしまっていては、記述が煩雑な上にコードを読んだ際にどのkeyに対して待ち合わせを行っているのか直感的に分からない。
-さらに、setKeyは明確な記述場所が決まっていないため、そのDSを待ち合わせているCS以外からも呼び出せてしまう\ref{src:StartSetKey}。
+さらに、setKeyは明確な記述場所が決まっていないため、そのDSを待ち合わせているCS以外からも呼び出せてしまう(ソースコード\ref{src:StartSetKey)})。
 \lstinputlisting[label=src:StartSetKey, caption=setKeyを外部から呼び出す例]{source/StartSetKey.java}
 \lstinputlisting[label=src:SetKey]{source/SetKey.java}
 このような書き方をされると、CSだけを見てどのkeyに対して待ち合わせを行っているのかわからないため、setKeyを呼び出しているコードを辿る必要がある。
 setKey移行に処理を記述した場合、その処理が行われない可能性がありThread poolへと送られNullPointerExceptionを引き起こす。
 \lstinputlisting[label=src:NullPointerException,caption=NullPointerExceptionになる可能性がある]{source/ShowDataFailed.java}
-ソースコード\ref{src:NullPointerException}は、for文でsetKeyとids.createをcntの回数呼び、動的にDSの取得数を決めようとしている。しかし、setKeyが最初に呼ばれた際に、DSの取得に成功すると実行可能と判断されてしまう。runの中でinfoの配列の要素だけ中身を表示させようとしてるが、2回目のasClassでNullPointExceptionを引き起こす。
+ソースコード\ref{src:NullPointerException}は、for文でsetKeyとids.createをcntの回数呼び、動的にDSの取得数を決めようとしている。
+しかし、setKeyが最初に呼ばれた際に、DSの取得に成功すると実行可能と判断されてしまう。
+runの中でinfoの配列の要素だけ中身を表示させようとしてるが、2回目のasClassでNullPointExceptionを引き起こす。
+この問題もインプットAPIの記述の分離により引き起こされるエラーである。
 \newpage
 今回の場合、コンストラクタ内をソースコード\ref{src:success}のように記述する必要がある。
 しかし、Aliceでは一つのアプリケーション内にLocalDSMは一つと決まっていたため、テストに必要なノード数分だけアプリケーションを別で立ち上げなければならないという手間があった。
 このためのシェルスクリプトをプログラマが書かなければならないのは本質的な作業ではない。
 より気軽にテストができるよう、同一プログラム内でLocalDSMを複数立ち上げられるようにすべきだと考えた。
 \subsection{TopologyManagerの拡張が困難}
-Aliceではより自由度の高い通信を行うために、TopologyManagerに幾つかの機能を追加すること考えていた。
+Aliceではより自由度の高い通信を行うために、TopologyManagerに幾つかの機能を追加すること考えていた\cite{OverNAT}。
 その一つがNAT越えの機能である。NAT越えは分散アプリケーション構築における課題の1つでもあるが、プログラマにとってその実装は容易ではない。Topology ManagerにNATを越えたノード間通信機能をつけることにより、ネットワークを気にせずに通信が行えるようにしたい。
 図 \ref{fig:nat}はTopologyManagerを用いてNAT越えをするための設計である。
 TopologyManagerはネットワークごと、トポロジーごとに存在するため、いずれの機能も複数のTopologyManagerを立ち上げ、連携させることで実現可能となる。
 今までのAliceでは、1つのノードに対してTopology Managerは１つと決められていた。
 Topology Managerと各ノードのやり取りをするのは、ノードごとに実行されるTopology NodeというMeta Computationである。
-Topology Managerは接続されたnodeの情報（nodeNameとIPアドレスのHashMap）を"nodeTable"というKeyに対応するDSとして保存している。
+Topology Managerは接続されたnodeの情報(nodeNameとIPアドレスのHashMap)を"nodeTable"というKeyに対応するDSとして保存している。
 そしてTopology NodeはTopology Managerから割り当てられたnodeNameを"hostname"というKeyに保存する。
 つまり、接続するTopology Managerが増えればTopoloyNodeに割り当てられるnodeNameも増えるため、今までのように"hostname"という1つのKeyだけでは対応できない。
 １つのノードに複数のTopologyManagerを対応させるには、TopologyNodeが複数のnodeNameを持つ必要がある。
 TopologyNodeが複数のTopologyManagerに対応できるようにしなければならない。
 \section{Christieの基本設計}
 基本的にはAliceと同じ、タスクとデータを細かい単位に分割して依存関係を記述し、入力が揃った順から並列実行するというプログラミング手法を用いる。
 ChristieはAliceと同じくJavaで書かれている。
-しかし将来的に当研究室が開発するGearsOSに取り入れたいため、GearsOSを構成する言語であるContinuation based C(CbC)に互換可能な設計を目指す。
+しかし将来的に当研究室が開発するGearsOS\cite{GearsOS}に取り入れたいため、GearsOSを構成する言語であるContinuation based C(CbC)に互換可能な設計を目指す。
 GearsOSではCodeSegment/DataSegmentと同様の概念としてCodeGear/DataGearという名称を用いているため、Christieでもそれに倣いCodeGear/DataGear(以下、CG/DG)と呼ぶこととする。
 \newpage
-DGはAliceと同様にDataGearManager（以下DGM）が管理する。
+DGはAliceと同様にDataGearManager(以下DGM)が管理する。
-DGMはLocalとRemoteがあり、全てのDGMはCodeGearManager（以下CGM）で管理される。
+DGMはLocalとRemoteがあり、全てのDGMはCodeGearManager(以下CGM)で管理される。
 GearsOSではContextという全てのCG/DGを一括管理するプロセスがあり、AliceのCGMもこのContextに相当する。
-全てのCGMはThreadPoolと他のCGM全てのリストを共有しているため、全てのCG/DGにアクセス可能である（図\ref{fig:christieClass}）。
+全てのCGMはThreadPoolと他のCGM全てのリストを共有しているため、全てのCG/DGにアクセス可能である(図\ref{fig:christieClass})。
 \begin{figure}[h]
 \begin{center}
 \includegraphics[width=130mm]{images/ChristieClass.pdf}
 \end{center}
 ChristieではInput DG の指定にはアノテーションを使う。
 アノテーションとは、クラスやメソッド、パッケージに対して付加情報を記述できるJavaのMeta Computationである。
 先頭に@をつけることで記述でき、オリジナルのアノテーションを定義することもできる。
 AliceではInputの受け皿であるReceiverを作り後からkeyをセットしていたが、
-ChristieではInputのためのDGを作り、その上にアノテーションでKeyを指定する（\ref{src:take}）。
+ChristieではInputのためのDGを作り、その上にアノテーションでKeyを指定する(ソースコード\ref{src:take})。
 \lstinputlisting[label=src:take, caption=Takeの例]{source/christie/InputDG.java}
 アノテーションで指定したInputDGは、CGを生成した際にCodeGear.class内で待ち合わせの処理が行われる。
 Christieのこのインプットアノテーションはフィールドに対してしか記述できないため、InputDGの生成とTake/Peekの指定とkeyの指定を必ず一箇所で書くことが明確に決まっている。
 そのためAliceのように外のCSからのkeyへの干渉をされることがない。
 また、アノテーションの指定はRUNTIMEではできないため、動的なkeyの指定も防ぐことができる。
 このように、アノテーションを用いたことで、Aliceの記述の分離問題が解決された。
-\ref{src:take}の2行目にあるように、InputDGを宣言する際には必ず型の指定が必要となる。
+ソースコード\ref{src:take}の2行目にあるように、InputDGを宣言する際には必ず型の指定が必要となる。
 DataGearは様々な型のデータを扱うためにJavaの総称型で受け取るようにしており、\textless \textgreater 内に指定した型でデータの型を限定できる。
 このように記述することで、Christieでは他の部分を辿らなくてもCGを見るだけでインプットされるデータの型が分かるように可読性を向上させた。
 また、取得してきたDGが指定と違う型であった場合はエラーとなるため、型の整合性を保ちながら信頼性の高いプログラミングが可能となった。
 また、Aliceではkeyと変数名の不一致から可読性が低くなっていた。
 しかしChristieではkeyと変数名が一致しないとエラーとなるため、自然と読みやすいコードが書けるようになっている。
-この部分に関しては、JavaのメタプログラミングAPIであるjavassist\cite{}を用いてアノテーションから変数の自動生成も試みたが、javassistでは変数生成の前に他のどのクラスも生成してはならないという制限があったため、Christieでは実現できなかった。
+この部分に関しては、JavaのメタプログラミングAPIであるJavassist\cite{javassist}を用いてアノテーションから変数の自動生成も試みたが、Javassistでは変数生成の前に他のどのクラスも生成してはならないという制限があったため、Christieでは実現できなかった。
-リモートノードに対してTake/Peekする際は、RemoteTake/RemotePeekのアノテーションを用いる(\ref{src:remotetake})。
+リモートノードに対してTake/Peekする際は、RemoteTake/RemotePeekのアノテーションを用いる(ソースコード\ref{src:remotetake})。
 そのため待ち合わせ先がLocalかRemoteかはアノテーションの違いからひと目でわかるようになった。
 \lstinputlisting[label=src:remotetake, caption=RemoteTakeの例]{source/christie/RemoteInputDG.java}
-なお、圧縮のMeta ComputationはAliceと同様で、指定する際にDGM名の前にcompressedをつける（\ref{src:compresslocal}）。
+なお、圧縮のMeta ComputationはAliceと同様で、指定する際にDGM名の前にcompressedをつける(ソースコード\ref{src:compresslocal})。
 \lstinputlisting[label=src:compresslocal, caption=Localへの圧縮の指定の例]{source/christie/CompressLocal.java}
 LocalからのTAKEではDGM名の指定がないが、それはLocalでの圧縮は基本想定していないためである。
 しかし、Localでの圧縮をしようと思えばRemoteTakeを用いて間接的にすることは可能である。
 \lstinputlisting[label=src:put, caption=Localへputする例]{source/christie/Put.java}
 \lstinputlisting[label=src:remoteput, caption=Remoteへputする例]{source/christie/RemotePut.java}
 \newpage
-flipも同様にDGMに直接DGを渡す(\ref{src:flip})。
+flipも同様にDGMに直接DGを渡す(ソースコード\ref{src:flip})。
 \lstinputlisting[label=src:flip, caption=Remoteへflipする例]{source/christie/Flip.java}
 ChristieではDGMに対して直接putするため、AliceのODSにあたる部分はない。
 ODSを経由するより直接DGMに書き込むような記述のほうが直感的であると考えたためである。
 ソースコード\ref{src:getdata}はgetDataを用いてInputDGからデータを取得する例である。
 \lstinputlisting[label=src:getdata, caption=getDataの例]{source/christie/GetData.java}
 Aliceと違う点は、プログラマが型を指定しなくて良い点である。
-4.2.1で示したように、InputDGを生成する際には型を指定する。
+4.3で示したように、InputDGを生成する際には型を指定する。
 この型は内部で保存され、リモートノードと通信する際も保たれる。
 このようにgetDataするだけでプログラマが指定しなくとも正しい型で取得できるため、プログラマの負担を減らし信頼性を保証することができる。
 \newpage
 ソースコード\ref{src:StartCodeGear}の8行目でそれが行われている。
 createCGMの引数にはリモートノードとソケット通信する際使うポート番号を指定する。
 CGMを生成した際にLocalDGMやリモートと通信を行うためのDaemonも作られる。
 CGに対してアノテーションから待ち合わせを実行する処理はsetupメソッドが行う。
-そのためソースコード\ref{src:StartCodeGear}の13行目、\ref{src:TestCodeGear}の10行目のように、newしたCGをCGMのsetupメソッドに渡す必要がある。
+そのためソースコード\ref{src:StartCodeGear}の13行目、ソースコード\ref{src:TestCodeGear}の10行目のように、newしたCGをCGMのsetupメソッドに渡す必要がある。
 AliceではnewすればCGが待ちに入ったが、Christieでは一度CGをnewしないとアノテーションから待ち合わせを行う処理ができないため、newの後にsetupを行う。
 そのため、CGの生成には必ずCGMが必要になる。
 runでCGMを受け渡すのはこのためである。
 なお、StartCGはインプットを持たないため、setupを行う必要がなく、newされた時点でrunが実行される。
 \section{DataGearManagerの複数立ち上げ}
 AliceではLocalDGMがstaticで書かれていたため複数のLocalDGMを立ち上げることができなかった。
 しかしChristieではCGMを２つ生成すればLocalDGMも２つ作られる。
-複数のLocalDGM同士のやりとりも、Remoteへの接続と同じようにRemoteDGMをproxyとして立ち上げアクセスする（図\ref{fig:remoteDGM}）。
+複数のLocalDGM同士のやりとりも、Remoteへの接続と同じようにRemoteDGMをproxyとして立ち上げアクセスする(図\ref{fig:remoteDGM})。
 \begin{figure}[h]
 \begin{center}
 \includegraphics[width=130mm]{images/DGM.pdf}
 \end{center}
 \label{fig:remoteDGM}
 \end{figure}
 \newpage
-ソースコード\ref{multilocal}は、LocalDSMを2つ立ち上げ、お互いをリモートに見立てて通信する例である。
+ソースコード\ref{src:multilocal}は、LocalDSMを2つ立ち上げ、お互いをリモートに見立てて通信する例である。
 11行目にあるように、RemoteDGMを立ち上げるにはCGMが持つcreateRemoteDGMメソッドを用いる。
 引数にはRemoteDGM名と接続するリモートノードのIPアドレス、ポート番号を渡している。
 \lstinputlisting[label=src:multilocal, caption=LocalDGMを2つ作る例]{source/christie/MultiLocal.java}
 \end{figure}
 プログラマはmainでCGMとStartCGを生成する。
 CGMと同時にLocalDGMは作られる。
 CGが生成され、setupメソッドが呼ばれるとアノテーションからTAKEコマンドが作られ実行される。
-CGは生成したインプットコマンドの総数を初期値としたカウンタを持っており、コマンドが解決される（InputDGが揃う）たびにカウンタは減っていき、0になるとrun内の処理がThreadPoolへ送られる。
+CGは生成したインプットコマンドの総数を初期値としたカウンタを持っており、コマンドが解決される(InputDGが揃う)たびにカウンタは減っていき、0になるとrun内の処理がThreadPoolへ送られる。
 \newpage
 図\ref{fig:remotePutSequence}は、LocalDGMにTakeを行うが、LocalDGM内にDGがなかったためにPutの待ち合わせをするときの処理の流れである。
 \begin{figure}[h]
 \begin{center}
 \includegraphics[width=160mm]{images/RemotePutSequence.pdf}
 \end{center}
 \caption{RemoteDGMにPutしたときのフロー}
+\label{fig:remotePutSequence}
 \end{figure}
 LocalまたはリモードノードからPUTコマンドが実行された際、もしwaitListにPutしたDGを待っているコマンドがあれば実行される。
 \newpage
 REPLYを受け取るとRemoteDGMはwaitListに入っていたコマンドを解決する。
 \chapter{再設計への考察}
 InputDGの指定において、CGにDGを宣言するというのは、DGをそのままflipできるようにするためであった。
 逆に言えばそれ以外でDataGear型でプログラマが利用することは少ない。
-そのため、DGをアノテーションから生成し完全にメタレイヤーに移すことで、DGの宣言のないより分かりやすい記述が可能だと考える。
+そのため、DGを宣言せずにアノテーションから生成し完全にメタレイヤーに移すことで、より分かりやすい記述が可能だと考える。
-flipする場合は、keyを指定するだけにしたほうが良い。
+flipする場合は、keyを指定するだけで良い。
 また、put/flipする際にDGM名を直接指定する書き方も、まだひと目でアウトプットしている部分が分かるようなシンタックスではないため、改善の余地がある。
 DGMは一種のデータベースであると述べたが、現状のDGMはデータベースに必要なトランザクションを持っていない。
 当研究室で開発しているJungleデータベースはトランザクションを持っており、更にマージ可能な差分管理システムを持っている。
-そのためJungleデータベースとの統合することで、DGMへの操作を信頼性高くできるようにしたほうが望ましい。
+そのためJungleデータベースとの統合することで、DGMへの操作を信頼性高くすることが望ましい。
-現在はノードごとにDGMとDGのkeyが与えられているが、URLのような大域で使えるkeyを用意することで
+また、現在はノードごとにDGMとDGのkeyが与えられているが、将来的にはURLのような大域で使えるkeyを用意することでより手軽なRemoteDGMへのアクセスを提供できると考えられる。
 \chapter{結論}
 \section{まとめ}
 本研究では、まず分散フレームワークに必要な要件を洗い出し、Akka、Hazelcastと比較しながら分散フレームワークAliceが分散性を意識して記述できる特徴をもつことを示した。
 また、Aliceの持つCode Segment/Data Segmentの計算モデルや記述方法、Meta Computationについてを説明し、AliceでNAT越えを実現するための手法を示した。
 CG/DGのプログラミングモデルなどの基本的にはAliceと同じであるが、アノテーションの処理がどれほどのオーバーヘッドに繋がっているか現時点では不明である。
 そのため、Aliceと同等の速度性能を持っているか、コードの量や複雑度は抑えられているかなどを分散処理の例題を用いて測定する必要がある。
 \subsection*{GearsOSへの移行}
 GearsOSはまだ開発途中であったため、本論文の作成時点ではChristieのような分散機能を実装することが叶わなかった。
-GearsOSではモデル検査機構akasha\cite{}があるため、待ちに入っているkeyのputし忘れなどをコンパイルの段階で見つけることができる。
+GearsOSではモデル検査機構akasya\cite{akasya}があるため、待ちに入っているkeyのputし忘れなどをコンパイルの段階で見つけることができる。
 GearsOS上で分散プログラミングができればより信頼性の高いプログラミングが期待できるため、将来的にはChristieをGearsOSの分散機構として取り込みたい。
 GearsOSにChristieを移行するには、GearsOSにJavaのアノテーションに相当するMeta Computationを実装する必要がある。
 そしてChristieでは実現できなかったアノテーションからの変数の自動生成が行えれば更にプログラミングしやすいAPIになると考えられる。
 定義したアノテーションの仕様例がソースコード\ref{src:takeAno}、\ref{src:remotetakeAno}である。
 \lstinputlisting[label=src:takeAno, caption=Takeアノテーションの使用例]{source/christie/InputDG.java}
 \lstinputlisting[label=src:remotetakeAno, caption=RemoteTakeアノテーションの使用例]{source/christie/RemoteInputDG.java}
-アノテーションを使う際、()内に記述する値が\ref{src:take}のvalueや\ref{src:remotetake}のdsmNameといったキーに保存される。
+アノテーションを使う際、()内に記述する値がソースコード\ref{src:take}のvalueやソースコード\ref{src:remotetake}のdsmNameといったキーに保存される。
 通常キーに対して値を入れる場合は、ソースコード\ref{src:remotetakeAno}のようにkey=の形で記述しなければならないが、Takeのようにキーが1つの場合、キー名をvalueにすることでその記述を省略することができる。
 setupメソッド内では生成されたフィールドに対してアノテーションを含めた情報を処理している。
 これにはJavaのreflectionAPIが使用されている。
 reflectionAPIでは対象となるクラスのフィールドやメソッド、それに対するアノテーションやアノテーションが保持するキーにアクセスすることができる。
 ソースコード\ref{src:setup}はsetupメソッド内でreflectionAPIを用いてアノテーションからTakeコマンドを作成する部分である。
 \lstinputlisting[label=src:setup, caption=reflectionAPIでフィールドの情報を取得]{source/christie/Setup.java}
-フィールドから取得したDGとアノテーションから取得したkeyからインプットコマンド（TAKE/PEEK）を生成し、DGMへ送って実行する。
+フィールドから取得したDGとアノテーションから取得したkeyからインプットコマンド(TAKE/PEEK)を生成し、DGMへ送って実行する。
 \chapter{謝辞}
 本研究の遂行、また本論文の作成にあたり、ご多忙にも関わらず終始懇切なる御指導と御
 教授を賜わりました河野真治准教授に深く感謝したします。

Mercurial > hg > Papers > 2018 > nozomi-master

comparison paper/nozomi-master.tex @ 174:f0e9cc7d13f9