# HG changeset patch # User Nozomi Teruya # Date 1517156163 -32400 # Node ID 9c1b9562f44138a6533979f4329959c9447204cf # Parent 3c425e8911cf2d796d7ecc7dd9e959d8d8fb6c73 add chapter4 diff -r 3c425e8911cf -r 9c1b9562f441 paper/nozomi-master.pdf Binary file paper/nozomi-master.pdf has changed diff -r 3c425e8911cf -r 9c1b9562f441 paper/nozomi-master.tex --- a/paper/nozomi-master.tex Sun Jan 28 18:23:56 2018 +0900 +++ b/paper/nozomi-master.tex Mon Jan 29 01:16:03 2018 +0900 @@ -38,28 +38,27 @@ \newcommand\tabref[1]{表 \ref{tab:#1}} \newcommand{\tblcaption}[1]{\def\@captype{table}\caption{#1}} -\lstset{ - frame=single, - keepspaces=true, - stringstyle={\ttfamily}, - commentstyle={\ttfamily}, - identifierstyle={\ttfamily}, - keywordstyle={\ttfamily}, - basicstyle={\ttfamily}, - breaklines=true, - xleftmargin=0zw, - xrightmargin=0zw, - framerule=.2pt, - columns=[l]{fullflexible}, - numbers=left, - stepnumber=1, - numberstyle={\scriptsize}, - numbersep=1em, - language={}, - tabsize=4, - lineskip=-0.5zw, - escapechar={@}, +\lstset{% + language={Java},%使用言語 + basicstyle={\small},%書体 + commentstyle={\small\itshape},%コメントの書体 + keywordstyle={\small\bfseries},%キーワードの書体 + %identifierstyle={\small},% + %ndkeywordstyle={\small},% + stringstyle={\small},%文字列の書体 + frame={trlb},%外枠 + breaklines=true,%改行 + columns=[l]{fullflexible},% + xrightmargin=0zw,% + xleftmargin=3zw,% + numbers=left,%行番号の表示 + numberstyle={\scriptsize},%行番号の書体 + numbersep=1zw,% + stepnumber=1, + lineskip=-0.5ex,% + captionpos=b,%キャプションの位置 } + \def\lstlistingname{リスト} \def\lstlistlistingname{リスト目次} @@ -199,8 +198,9 @@ Start CSはどのDSにも依存しない。つまりInput DSを持たない。 このCSをmainメソッド内でnewし、executeメソッドを呼ぶことで実行を開始させることができる。 - \lstinputlisting[label=src:StartCodeSegment, caption=StartCodeSegmentの例]{source/StartCodeSegment.java} - \lstinputlisting[label=src:CodeSegment, caption=CodeSegmentの例]{source/TestCodeSegment.java} + +\lstinputlisting[label=src:StartCodeSegment, caption=StartCodeSegmentの例]{source/StartCodeSegment.java} +\lstinputlisting[label=src:CodeSegment, caption=CodeSegmentの例]{source/TestCodeSegment.java} \newpage @@ -371,14 +371,24 @@ 辿ってもflipされている可能性もあるため、最初にそのDSをputしている部分を見つけるのは困難である。 従って、待ち合わせているkeyにどのような型のデータが対応しているのかをそのCSを見ただけで分かるようにするべきと考える。 -% ここでMessagePackの話入れる？ - \section{key名と変数名の不一致} 2.4のCodeSegmentの例題である通り、key名とそのkeyで待ち合わせたDSを受け取るReceiver名は異なることがある。 もしプログラマが適当に命名してしまえば後々混乱を招くため、待ち合わせるkey名とinput DS の変数名一致を強制させたい。 +\section{DataSegmentの明瞭性} +2.5.1で示したように、Aliceに圧縮のMeta Computationを実装した際、DS内に複数の型を同時に持たせるようにした。 + + +しかしこれでは、DSが今どの形式を持っているのか、どの状態にあるのかがわかりづらい。 +また、DSがbyteArray型を受け取った場合、データであるObject型として渡されたものなのか、MessagePackや圧縮で変換されたものなのかを判別する処理を入れなければならなかった。 +今後DSにより多様な形式を同時に持たせることになれば、さらにその判別の処理が増えることになる。 + + +Alice自体の拡張・デバッグをしやすくするためにも、DSがどの型を持っているのかをひと目で分かるようにしたい。 + + \section{LocalDataSegmentManagerを複数持てない} Aliceでは1つのノードにつき１つしかLocalDSMを立ち上げられない作りになっている。 そのために以下のような問題が発生した。 @@ -394,23 +404,28 @@ Aliceではより自由度の高い通信を行うために、TopologyManagerに幾つかの機能を追加すること考えていた。 その一つがNAT越えの機能である。NAT越えは分散アプリケーション構築における課題の1つでもあるが、プログラマにとってその実装は容易ではない。Topology ManagerにNATを越えたノード間通信機能をつけることにより、ネットワークを気にせずに通信が行えるようにしたい。 + 図 \ref{fig:nat}はTopologyManagerを用いてNAT越えをするための設計である。 + + \begin{figure}[h] \begin{center} -\includegraphics[width=105mm]{images/nat.pdf} +\includegraphics[width=140mm]{images/nat.pdf} \end{center} \caption{複数のTopologyManagerによるNAT越えの実現} \label{fig:nat} \end{figure} +\newpage + また、別トポロジーで立ち上げたアプリケーション同士を接続する機能も追加したいと考えていた。 TreeTopologyのVNCアプリとStarTopologyのチャットアプリを連携したいという要望が生まれたためである。 別トポロジーのアプリケーションが接続可能になれば、VNC画面のスナップショットをChat上に載せたり、VNC上にChatの内容をコメントとして流すといった拡張が容易になる(図 \ref{fig:vncandchat})。 \begin{figure}[h] \begin{center} -\includegraphics[width=105mm]{images/vncandchat.pdf} +\includegraphics[width=130mm]{images/vncandchat.pdf} \end{center} \caption{別トポロジーのアプリケーションの接続} \label{fig:vncandchat} @@ -426,10 +441,12 @@ １つのノードに複数のTopologyManagerを対応させるには、TopologyNodeが複数のnodeNameを持つ必要がある。 TopologyNodeが複数のTopologyManagerに対応できるようにしなければならない。 +\newpage + そこで、Meta Computationとして、通常のLocal DSMとは別にTopology ManagerごとのMeta Local DSMを立ち上げる方法が考えられる(図 \ref{fig:somehostname})。 \begin{figure}[h] \begin{center} -\includegraphics[width=105mm]{images/somehostname.pdf} +\includegraphics[width=90mm]{images/somehostname.pdf} \end{center} \caption{複数のTopologyManagerに複数のLocalDSMが対応} \label{fig:somehostname} @@ -451,39 +468,79 @@ 本章では、新たに作った分散フレームワークChristieの設計を説明する。 \section{Christieの基本設計} -ChristieはJavaで書かれている。 -将来的に当研究室が開発するGearsOSに取り入れたいため、GearsOSを構成する言語であるContinuation based C(CbC)に互換可能な設計を目指す。 +基本的にはAliceと同じ、タスクとデータを細かい単位に分割して依存関係を記述し、入力が揃った順から並列実行するというプログラミング手法を用いる。 + + +ChristieはAliceと同じくJavaで書かれている。 +しかし将来的に当研究室が開発するGearsOSに取り入れたいため、GearsOSを構成する言語であるContinuation based C(CbC)に互換可能な設計を目指す。 GearsOSではCodeSegment/DataSegmentと同様の概念としてCodeGear/DataGearという名称を用いているため、Christieでもそれに倣いCodeGear/DataGear(以下、CG/DG)と呼ぶこととする。 -%DataGearManager -%CodeGearManagerがそれを持ち歩く。CGMはGearsでいうContextで、全てにアクセスできる。 -%run(cgm)でCGMを持ち歩く。Gearsもそうだから。 -%CodeGearをextends -%StartCodeGearでCGMをつくる。CGを作るときはsetup。 + +DGはAliceと同様にDataGearManager（以下DGM）が管理する。 +DGMはLocalとRemoteがあり、全てのDGMはCodeGearManager（以下CGM）で管理される。 +GearsOSではContextという全てのCG/DGを一括管理するプロセスがあり、AliceのCGMもこのContextに相当する。 + + +CGを記述する際はAlice同様CodeGear.classを継承する。 +CodeGearはvoid run(CodeGearManager cgm)を持つclassであり、プログラマはrunメソッド内に処理を記述する。 +インプットで指定したkeyに対応したDGが全て揃ったとき、runに書かれた処理が実行される。 +ChristieのAPIにはrunの引数で受け取ったCGMを経由しアクセスする。 +GearsOSではCG間でContextを受け渡すことによってCGはDGにアクセスするため、Christieでもその記述方法を採用した。 + \section{APIの改善} -%take/peekはAnnotationを使う。待ち合わせはJavaのreflectionAPIを用いたメタがよろしくやってくれる。 -%keyと変数名の食い違いも防止する。ここはJavassistでやろうとしたけどむりだった。 -%DataGearを宣言するとき型も書くのでどんなデータがくるのかわかりやすい。違う型のデータがきたらエラーを吐く -%LocalかRemoteかはAnnotationが違うのでわかりやすい +\subsection{TAKE/PEEK} +ChristieではInput DG の指定にはAnnotationを使う。 +Annotationとは、Javaのクラスやメソッド、パッケージに対して付加情報を記述できる機能である。 +先頭に@をつけることで記述でき、オリジナルのAnnotationを定義することもできる。 + +AliceではInputの受け皿であるReceiverを作り後からkeyをセットしていたが、 +ChristieではInputのためのDGを作り、その上にAnnotationでKeyを指定する（\ref{src:take}）。 + +\lstinputlisting[label=src:take, caption=TAKEの例]{source/christie/InputDG.java} + + +Annotationで指定したInputDGは、CGを生成した際にCodeGear.class内で待ち合わせの処理が行われる。 +これにはJavaのreflectionAPIを利用している。 + +\ref{src:take}の2行目にあるように、InputDGを宣言する際には必ず型の指定が必要となる。 +そのため、Christieでは他の部分を辿らなくてもCGを見るだけでインプットされるデータの型が分かる。 +また、取得してきたDGが指定と違う型であった場合エラーとなるため、型の整合性を保ちながら信頼性の高いプログラミングが可能となった。 + +%Aliceではkeyと変数名の不一致から可読性が低くなっていた。しかし +%JavaのメタプログラミングAPIであるjavassistを用いてAnnotationから変数の自動生成も試みたが、javassistでは ため、実現できなかった。 + +%リモートノードに対してTAKEする際は、REMOTETAKEのAnnotationを用いる。 +%LocalかRemoteかはAnnotationが違うためひと目でわかる +%例 + +%なお、圧縮を指定する際はAlice同様dgm名の前にcompressedをつける。Localでの圧縮は基本想定していない。しかし、RemoteTakeで間接的にすることは可能である。 + +\subsection{PUT/FLIP} %odsはない。dsmを指定して直接putする。 -%getDataで正しい型でとれる。 + +\subsection{getData()} +%asClassに相当 +%InputDGで指定した型は内部で保存され、通信先でも保存される。getDataで正しい型でとれる。 \section{CodeGearの記述方法} +%以下のコードはLocalDSMにputした \lstinputlisting[label=src:StartCodeGear, caption=StartCodeGearの例]{source/christie/StartTest.java} \lstinputlisting[label=src:TestCodeGear, caption=CodeGearの例]{source/christie/TestCodeGear.java} +%CGを作るときはsetup。AliceではnewすればCGが待ちに入ったが、Annotationの処理を挟むには一度newしておかなければならないため、Christieではnewの後setupをして待ち合わせの処理を行う。 \section{DataGearManagerの複数立ち上げ} -%Remoteへの接続 +%CGMを２つつくればLocalが２つ作られる。Remoteへの接続と同じようにすれば良い \section{DataGearの拡張} - +%別のclassに分けている。DataGearを継承したMessagePackDataGearと、それを更に継承したCompressedDataGearを用意した。 +%そのため、どの形式をもっているかクラスを見るだけでわかるようになった \chapter{Christieの評価} \section{Akka}