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

comparison paper/nozomi-master.tex @ 156:bc9be2d40d0d

add requiremants

author	Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
date	Tue, 30 Jan 2018 23:41:54 +0900
parents	573db146fa93
children	d620f126a383

comparison

equal deleted inserted replaced

-:573db146fa93
+:bc9be2d40d0d
 %TopologyNodeとnodenameの説明もう少し
 \chapter{Aliceの問題点}
 Aliceを拡張していく中でいくつかの問題点が明らかになり、これらを解決するにはAlice自体を再設計する必要があるとわかった。
 \section{直感的でないAPI}
 このような書き方をされると、CSだけを見てどのkeyに対して待ち合わせを行っているのかわからないため、setKeyを呼び出しているコードを辿る必要がある。
 可読性の低いコードはプログラマの負担となるため、CSが何を待ち合わせているのかそのCSを見ただけで理解できるようにAPIを改善すべきである。
-\newpage
+\section{setKeyは最後に呼ばなければならない}
+setKeyメソッドをコンストラクタで呼ぶ際、setKeyメソッドを必ず最後に呼ばなければならない。
+CSは内部で実行に必要なDSを数えている。DSの取得に成功するとこの値が、デクリメントされ、0になると必要なDSが全て揃ったことと判断されThread poolへ送られる。
+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を引き起こす。
+\newpage
+今回の場合、コンストラクタ内をソースコード\ref{src:success}のように記述する必要がある。
+\lstinputlisting[label=src:success,caption=NullPointerExceptionにならない記述]{source/ShowData.java}
+このように記述の順序を考えながらプログラミングしなければならない設計では、バグを引き起こし信頼性を損なうことに繋がる。より自然に扱えるAPI設計にするべきだと考える。
 \section{動的なsetKey}
 setKeyはCSのコンストラクタで指定することが多い。
 このとき、指定するkeyは引数などから動的に受け取り、セットすることができる。
 しかし、その使い方では、putする部分など、該当するkeyを扱う全てコードを変更しなければならない。
 しかし、inputDSで指定するのはkeyのみであり、そのデータの型までは分からない。
 そのため、DSの型を知るにはputしている部分まで辿る必要がある。
 辿ってもflipされている可能性もあるため、最初にそのDSをputしている部分を見つけるのは困難である。
 従って、待ち合わせているkeyにどのような型のデータが対応しているのかをそのCSを見ただけで分かるようにするべきと考える。
+\newpage
 \section{key名と変数名の不一致}
 2.4のCodeSegmentの例題である通り、key名とそのkeyで待ち合わせたDSを受け取るReceiver名は異なることがある。
 もしプログラマが適当に命名してしまえば後々混乱を招くため、待ち合わせるkey名とinput DS の変数名一致を強制させたい。
 今後DSにより多様な形式を同時に持たせることになれば、さらにその判別の処理が増えることになる。
 Alice自体の拡張・デバッグをしやすくするためにも、DSがどの型を持っているのかをひと目で分かるようにしたい。
-\newpage
 \section{LocalDataSegmentManagerを複数持てない}
 Aliceでは1つのノードにつき１つしかLocalDSMを立ち上げられない作りになっている。
 そのために以下のような問題が発生した。
 \subsection{TopologyManagerの拡張が困難}
 Aliceではより自由度の高い通信を行うために、TopologyManagerに幾つかの機能を追加すること考えていた。
 その一つがNAT越えの機能である。NAT越えは分散アプリケーション構築における課題の1つでもあるが、プログラマにとってその実装は容易ではない。Topology ManagerにNATを越えたノード間通信機能をつけることにより、ネットワークを気にせずに通信が行えるようにしたい。
-\newpage
 図 \ref{fig:nat}はTopologyManagerを用いてNAT越えをするための設計である。
 \begin{figure}[h]
 \begin{center}
 \end{center}
 \caption{複数のTopologyManagerによるNAT越えの実現}
 \label{fig:nat}
 \end{figure}
+\newpage
 また、別トポロジーで立ち上げたアプリケーション同士を接続する機能も追加したいと考えていた。
 TreeTopologyのVNCアプリとStarTopologyのチャットアプリを連携したいという要望が生まれたためである。
 別トポロジーのアプリケーションが接続可能になれば、VNC画面のスナップショットをChat上に載せたり、VNC上にChatの内容をコメントとして流すといった拡張が容易になる(図 \ref{fig:vncandchat})。
-\newpage
 \begin{figure}[h]
 \begin{center}
 \includegraphics[width=180mm]{images/vncandchat.pdf}
 \end{center}
 \caption{別トポロジーのアプリケーションの接続}
 そしてTopology NodeはTopology Managerから割り当てられたnodeNameを"hostname"というKeyに保存する。
 つまり、接続するTopology Managerが増えればTopoloyNodeに割り当てられるnodeNameも増えるため、今までのように"hostname"という1つのKeyだけでは対応できない。
 １つのノードに複数の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=100mm]{images/somehostname.pdf}
+\includegraphics[width=120mm]{images/somehostname.pdf}
 \end{center}
 \caption{複数のTopologyManagerに複数のLocalDSMが対応}
 \label{fig:somehostname}
 \end{figure}
+\newpage
 それぞれのTopology Managerに対応するLocalDSMを作り、それぞれに対応したnodeNameを格納することで、DSMを切り替えるだけでTopologyNodeの仕様は変えずに複数のTopology Managerに対応できるという設計である。
 しかし、現在のAliceのコードではDSMを管理するclassがstatic classであったため、複数のLocal DSMを持つことはできなかった。
 staticを取り除こうとしたところ、Aliceの大部分のコードを修正する必要があることがわかった。
 よって、再設計の際にはstatic classのない実装を行い、DSM切り替えによる方式を実現したい。
 \chapter{分散フレームワークChristieの設計}
+\section{Christieの必要条件}
 3章でのAliceの問題点を踏まえ、新たにフレームワークを作り直すべきだと考えた。
 本章では、新たに作った分散フレームワークChristieの設計を説明する。
+Christieに必要な要件は以下のように考える。
+\begin{itemize}
+\item {\ttfamily create/setKeyのような煩雑なAPIをシンプルにし可読性を上げる}
+\end{itemize}
+\begin{itemize}
+\item {\ttfamily プログラマが型を推測しなくとも整合性がとれるように型を解決し、信頼性を上げる}
+\end{itemize}
+\begin{itemize}
+\item {\ttfamily staticなLocalDSMをなくし、複数のインスタンスを同時に立ち上げられるようにすることで拡張性を上げる}
+\end{itemize}
 \section{Christieの基本設計}
 基本的にはAliceと同じ、タスクとデータを細かい単位に分割して依存関係を記述し、入力が揃った順から並列実行するというプログラミング手法を用いる。
 DGはAliceと同様にDataGearManager（以下DGM）が管理する。
 DGMはLocalとRemoteがあり、全てのDGMはCodeGearManager（以下CGM）で管理される。
 GearsOSではContextという全てのCG/DGを一括管理するプロセスがあり、AliceのCGMもこのContextに相当する。
+全てのCGMはThreadPoolと他のCGM全てのリストを共有しているため、全てのCG/DGにアクセス可能である。
 CGを記述する際はAlice同様CodeGear.classを継承する。
 CodeGearは
 void run(CodeGearManager cgm)を持つclassであり、プログラマはrunメソッド内に処理を記述する。
 インプットで指定したkeyに対応したDGが全て揃ったとき、runに書かれた処理が実行される。
 ChristieのAPIにはrunの引数で受け取ったCGMを経由しアクセスする。
 GearsOSではCG間でContextを受け渡すことによってCGはDGにアクセスするため、Christieでもその記述方法を採用した。
+%Clas図
 \newpage
 \section{APIの改善}
 \subsection{TAKE/PEEK}
 InputAPIにはAliceと同じくTakeとPeekを用意した。
-ChristieではInput DG の指定にはAnnotationを使う。
+ChristieではInput DG の指定にはアノテーションを使う。
-Annotationとは、Javaのクラスやメソッド、パッケージに対して付加情報を記述できる機能である。
+アノテーションとは、クラスやメソッド、パッケージに対して付加情報を記述できるJavaのMeta Computationである。
-先頭に@をつけることで記述でき、オリジナルのAnnotationを定義することもできる。
+先頭に@をつけることで記述でき、オリジナルのアノテーションを定義することもできる。
 AliceではInputの受け皿であるReceiverを作り後からkeyをセットしていたが、
-ChristieではInputのためのDGを作り、その上にAnnotationでKeyを指定する（\ref{src:take}）。
+ChristieではInputのためのDGを作り、その上にアノテーションでKeyを指定する（\ref{src:take}）。
 \lstinputlisting[label=src:take, caption=Takeの例]{source/christie/InputDG.java}
-Annotationで指定したInputDGは、CGを生成した際にCodeGear.class内で待ち合わせの処理が行われる。
+アノテーションで指定したInputDGは、CGを生成した際にCodeGear.class内で待ち合わせの処理が行われる。
 これにはJavaのreflectionAPIを利用している。
-Annotationの指定はRUNTIMEではできないため、動的なkeyの指定も防ぐことができる。
+アノテーションの指定はRUNTIMEではできないため、動的なkeyの指定も防ぐことができる。
 \ref{src:take}の2行目にあるように、InputDGを宣言する際には必ず型の指定が必要となる。
-DataGearは様々な型のデータを扱うためにJavaの総称型で受け取るようにしており、<>内に指定した型でデータの型を限定できる。
+DataGearは様々な型のデータを扱うためにJavaの総称型で受け取るようにしており、\textless \textgreater 内に指定した型でデータの型を限定できる。
 このように記述することで、Christieでは他の部分を辿らなくてもCGを見るだけでインプットされるデータの型が分かるように可読性を向上させた。
 また、取得してきたDGが指定と違う型であった場合はエラーとなるため、型の整合性を保ちながら信頼性の高いプログラミングが可能となった。
 また、Aliceではkeyと変数名の不一致から可読性が低くなっていた。
 しかしChristieではkeyと変数名が一致しないとエラーとなるため、自然と読みやすいコードが書けるようになっている。
-この部分に関しては、JavaのメタプログラミングAPIであるjavassist\cite{}を用いてAnnotationから変数の自動生成も試みたが、javassistでは変数生成の前に他のどのクラスも生成してはならないという制限があったため、Christieでは実現できなかった。
+この部分に関しては、JavaのメタプログラミングAPIであるjavassist\cite{}を用いてアノテーションから変数の自動生成も試みたが、javassistでは変数生成の前に他のどのクラスも生成してはならないという制限があったため、Christieでは実現できなかった。
-リモートノードに対してTake/Peekする際は、RemoteTake/RemotePeekのAnnotationを用いる(\ref{src:remotetake})。
+リモートノードに対してTake/Peekする際は、RemoteTake/RemotePeekのアノテーションを用いる(\ref{src:remotetake})。
-そのため待ち合わせ先がLocalかRemoteかはAnnotationの違いからひと目でわかるようになった。
+そのため待ち合わせ先がLocalかRemoteかはアノテーションの違いからひと目でわかるようになった。
 \lstinputlisting[label=src:remotetake, caption=RemoteTakeの例]{source/christie/RemoteInputDG.java}
 \newpage
 StartCGを記述する際にはcreateCGMメソッドでCGMを生成してコンストラクタに渡す必要がある。
 ソースコード\ref{src:StartCodeGear}の8行目でそれが行われている。
 createCGMの引数にはリモートノードとソケット通信する際使うポート番号を指定する。
 CGMを生成した際にLocalDGMやリモートと通信を行うためのDaemonも作られる。
-CGの待ち合わせ処理はsetupメソッドが行う。
+CGに対してアノテーションから待ち合わせを実行する処理はsetupメソッドが行う。
 そのためソースコード\ref{src:StartCodeGear}の13行目、\ref{src:TestCodeGear}の10行目のように、newしたCGをCGMのsetupメソッドに渡す必要がある。
-AliceではnewすればCGが待ちに入ったが、Christieでは一度CGをnewしないとAnnotationから待ち合わせを行う処理ができないため、newの後にsetupを行う。
+AliceではnewすればCGが待ちに入ったが、Christieでは一度CGをnewしないとアノテーションから待ち合わせを行う処理ができないため、newの後にsetupを行う。
 そのため、CGの生成には必ずCGMが必要になる。
 runでCGMを受け渡すのはこのためである。
+なお、StartCGはインプットを持たないため、setupを行う必要がなく、newされた時点でrunが実行されuる。
+%ここにCG/DGのフロー？
 \newpage
 \section{DataGearManagerの複数立ち上げ}
 \chapter{Christieの評価}
-\section{Akka}
+\section{Aliceとの分散性能測定}
-\section{Corba}
-\section{Erlang}
+\section{他フレームワークとの比較}
-\section{Hazelcast}
+\subsection{Akka}
+\subsection{Corba}
+\subsection{Erlang}
+\subsection{Hazelcast}
 \chapter{まとめ}
 \chapter{今後の課題}
+\section{TopologyManagerの実装}
+Aliceと同じく、静的・動的なトポロジー管理のできるTopologyManagerの実装が必要である。
+Christieでは複数のLocalDSMが立ち上げ可能なため、TopologyManagerでのNAT超えも実装し実用性があるかを検証する
+また、通信の信頼性を保証するために、TopologyManagerがダウンした際に新たなTopologyManagerを立ち上げる機能もあるべきだと考える。
+\section{検証機構の導入？}
+\section{GearsOSへの移行}
+GearsOSはまだ開発途中であったため、本論文の作成時点ではChristieのような分散機能を実装することが叶わなかった。
+GearsOSにChristieを移行するには、GearsOSにJavaのアノテーションに相当するMeta Computationを実装する必要がある。
+そしてChristieでは実現できなかったアノテーションからの変数の自動生成が行えれば更にプログラミングしやすいAPIになると考えられる。
+\chapter{付録}
+\section{独自のアノテーション定義}
+Christieのアノテーションの実装方法と、そのアノテーションからtakeを実行する部分を解説する。
+ソースコード\ref{src:take}、\ref{src:remotetake}がChristie独自のアノテーションの定義である。
+\lstinputlisting[label=src:take, caption=Takeの実装]{source/christie/TakeAnnotation.java}
+\lstinputlisting[label=src:remotetake, caption=RemoteTakeの実装]{source/christie/RemoteTakeAnnotation.java}
+@Targetや@Retentionはアノテーション定義のためのアノテーション、メタアノテーションである。
+@Targetには、フィールドやメソッド、コンストラクタなど、このアノテーションの付加対象となる構文要素が何かを記述する。
+@Retentionには、SOURCE・CLASS・RUNTIMEが選択でき、アノテーションで付加された情報がどの段階まで保持されるかを定義する。reflectionAPIを利用するにはRUNTIMEでなければならないため、Christieのアノテーションの@Retentionは全てRUNTIMEである。
+定義したアノテーションの仕様例がソースコード\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:remotetakeAno}のようにkey=の形で記述しなければならないが、Takeのようにキーが1つの場合、キー名をvalueにすることでその記述を省略することができる。
+setupメソッド内では生成されたフィールドに対してアノテーションを含めた情報を処理している（ソースコード\ref{src:setup}）。
+\lstinputlisting[label=src:setup, caption=reflectionAPIでフィールドの情報を取得]{source/christie/Setup.java}
+これにはJavaのreflectionAPIが使用されている。
+reflectionAPIでは対象となるクラスのフィールドやメソッド、それに対するアノテーションも取得できる。
+フィールドから取得したDGとアノテーションから取得したkeyからインプットコマンド（TAKE/PEEK）を生成し、DGMへ送って実行する。
+このとき要求したデータがDGM内にない場合はwaitListに入る。
+PUTコマンドが実行された際、もしwaitListに同じkeyのDGを待っているコマンドがあれば実行される。
+CGは生成したインプットコマンドの総数を初期値としたカウンタを持っており、コマンドが解決されるたびにカウンタは減っていき、0になった時、CGがThreadPoolへ送られる。
 \chapter{謝辞}
 本研究の遂行、また本論文の作成にあたり、ご多忙にも関わらず終始懇切なる御指導と御
 教授を賜わりました河野真治准教授に深く感謝したします。
-そして、数々の貴重な御助言と技術的指導を戴いた伊波立樹さん、並びに並列信頼研究室
+そして、数々の貴重な御助言と技術的指導を戴いた伊波立樹さん、他フレームワークの調査に協力してくださった清水隆博さん、赤堀貴一さん、浜瀬裕暉さん、大城由也さん、並びに信頼研究室の皆様に感謝いたします。
-の皆様、本研究を遂行するにあたり参考にさせていただいた先行研究のAlice, Federated
+先行研究であるAlice, Federated Linda, Jungle, TreeVNCがなければ本研究はありませんでした。 これら先行研究の設計や実装に関わった全ての先輩方に感謝いたします。
-Linda, Jungle, TreeVNC の設計・実装に関わった全ての方々に感謝いたします。
+また、本フレームワークの名前の由来となったクリスティー式戦車の生みの親、ジョン・W・クリスティーに敬意を評します。
-また、本フレームワークの名前の由来となったクリスティー式戦車の生みの親、ジョン・
-W・クリスティーに敬意を評します。
+最後に、日々の研究生活を支えてくださった米須智子さん、菱田正和さん、情報工学科の方々、そして家族に心より感謝いたします。
-最後に、日々の研究生活を支えてくださった米須智子さん、情報工学科の方々、そし
-て家族に心より感謝いたします。
 %参考文献
 \nocite{*}
 \bibliographystyle{junsrt}
-\bibliography{reference}
+%\bibliography{reference}
 %発表履歴
 \addcontentsline{toc}{chapter}{発表履歴}
 %\input{history.tex}

Mercurial > hg > Papers > 2018 > nozomi-master

comparison paper/nozomi-master.tex @ 156:bc9be2d40d0d