Mercurial > hg > Papers > 2015 > nozomi-prosym
annotate paper-last/prosym.tex @ 10:5774c70506ae
last-update of paper
| author | Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp> |
|---|---|
| date | Tue, 01 Dec 2015 00:07:29 +0900 |
| parents | 8de971cb8ad8 |
| children |
| rev | line source |
|---|---|
| 4 | 1 % withpage: ページ番号をつける (著者確認用) |
| 2 % english: 英語原稿用フォーマット | |
| 3 \documentclass[techrep, ,dvipdfmx]{ipsjprosym} | |
| 4 %\documentclass[withpage,english]{ipsjprosym} | |
| 5 | |
| 6 \usepackage[dvipdfmx,hiresbb]{graphicx} | |
| 7 \usepackage{listings} | |
| 8 \usepackage{url} | |
| 9 \lstset{% | |
| 10 language={Java},%使用言語 | |
| 11 basicstyle={\small},%書体 | |
| 12 commentstyle={\small\itshape},%コメントの書体 | |
| 13 keywordstyle={\small\bfseries},%キーワードの書体 | |
| 14 %identifierstyle={\small},% | |
| 15 %ndkeywordstyle={\small},% | |
| 16 stringstyle={\small},%文字列の書体 | |
| 17 frame={trlb},%外枠 | |
| 18 breaklines=true,%改行 | |
| 19 columns=[l]{fullflexible},% | |
| 20 xrightmargin=0zw,% | |
| 21 xleftmargin=3zw,% | |
| 22 numbers=left,%行番号の表示 | |
| 23 numberstyle={\scriptsize},%行番号の書体 | |
| 24 numbersep=1zw,% | |
| 25 stepnumber=1, | |
| 26 lineskip=-0.5ex,% | |
| 27 captionpos=b,%キャプションの位置 | |
| 28 } | |
| 29 \renewcommand{\lstlistingname}{Code} | |
| 30 \input{dummy.tex} %% Font | |
| 31 | |
| 32 \begin{document} | |
| 33 | |
| 34 % Title, Author %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% | |
| 35 \title{分散フレームワークAliceのPC画面配信システムへの応用} | |
| 8 | 36 \affiliate{IE}{琉球大学工学部情報工学科} |
| 37 \author{照屋 のぞみ}{Nozomi Teruya}{IE} | |
|
10
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
38 \author{河野 真治}{Shinji Kono}{IE}[kono@ie.u-ryukyu.ac.jp] |
| 4 | 39 |
| 40 \begin{abstract} | |
| 6 | 41 当研究室ではデータを Data Segment、タスクを Code Segment という単位で分割して記述する手法を提唱しており、それに基づく並列分散フレームワークAliceを開発している。 |
| 42 Aliceが実用的な分散アプリケーションの記述能力を有することを確認するために、画面共有システムTreeVNCをAlice上で構築した。 | |
| 43 TreeVNCをAliceで実装するにあたり必要となった圧縮機能等をAliceが提供するMeta Computationとして実装した。 | |
| 44 そして記述したアプリケーションの性能とコードを比較したことで、Aliceが実用的な分散アプリケーションをシンプルな記述で実現でき、仕様の変更を抑えた信頼性の高いプログラミングが可能だということを確認した。 | |
| 4 | 45 \end{abstract} |
| 46 | |
| 47 \begin{jkeyword} | |
| 48 並列分散フレームワーク | |
| 49 \end{jkeyword} | |
| 50 | |
| 51 \maketitle | |
| 52 | |
| 53 % Body %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% | |
| 54 \section{研究背景と目的} | |
|
10
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
55 当研究室ではデータをData Segment、タスクをCode Segmentという単位で記述する分散フレームワークAlice\cite{senkokenkyu}\cite{senkokenkyu2} の開発を行っている。 |
| 4 | 56 Aliceではスケーラブルな分散プログラムを信頼性高く記述できる環境を実現する。 |
| 57 ここで言う信頼性とは、定められた環境下で安定して仕様に従った動作を行うことを指す。 | |
| 58 | |
| 59 Aliceでは、処理をComputationとMeta Computationに階層化し、コアな仕様と複雑な例外処理に分離する。 | |
| 60 そして分散環境の構築に必要な処理をMeta Computationとして提供する。 | |
| 61 プログラマはコアな仕様の変更を抑えつつプログラムの挙動変更ができるため、信頼性の高い分散アプリケーションの記述が可能となる。 | |
| 62 | |
| 63 本研究では、Alice上に実用的な分散アプリケーションの例題である画面共有システムTreeVNC \cite{treeVNC} を構築する。 | |
|
10
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
64 TreeVNCは画面変更の差分を木構造にそって配布する分散システムで、差分は数MByteに達するので圧縮を行う必要がある。そして表示時には伸長したデータを取り扱わなければならない。 |
|
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
65 また、データのノード間の転送では複製を可能な限り避ける必要がある。 |
|
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
66 差分データはAliceのData Segementに対応するため、Data Segmentを扱うAliceの機能として圧縮やゼロコピー転送の機能が必要なる。 |
|
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
67 これらの機能はTreeVNCではad-hocに実装されているが、AliceではこれをMeta Computationとして実装する。 |
|
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
68 そして、TreeVNCとの比較を行うことでAlice の実用性を示すと共にAlice のMeta Computationの役割と有効性を示す。 |
| 4 | 69 |
| 70 \section{分散フレームワークAlice} | |
| 71 \subsection{Code Segment と Data Segment} | |
| 72 AliceではCode Segment（以下CS）とData Segment（以下DS）の依存関係を記述することでプログラミングを行う。 | |
| 8 | 73 CSは実行に必要なDSが全て揃うと実行される。CSを実行するために必要な入力されるDSのことをInputDS、CSが計算を行った後に出力されるDSのことをOutput DSと呼ぶ。 |
| 4 | 74 データの依存関係にないCSは並列実行が可能である（図 \ref{fig:CS} ）。 |
| 75 CSの実行においてDSが他のCSから変更を受けることはない。そのためAliceではデータが他から変更され整合性がとれなくなることはない。 | |
| 76 | |
| 77 \begin{figure}[htbp] | |
| 78 \begin{center} | |
| 79 \includegraphics[width=70mm]{images/dsandcs2.pdf} | |
| 80 \end{center} | |
| 81 \caption{CodeSegmentの依存関係 } | |
| 82 \label{fig:CS} | |
| 83 \end{figure} | |
| 84 | |
| 9 | 85 AliceはJavaで実装されており、DSはJava Objectに相当する。CSはRunnableなObject(void run()を持つObject)に相当する。 |
| 86 プログラマがCSを記述する際は、CodeSegmentクラスを継承する。 | |
| 87 | |
|
10
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
88 DSは数値や文字列などの基本的なデータの集まりを指し、Aliceが内部にもつデータベースによって管理されている。このデータベースをAliceではDS Managerと呼ぶ。 |
| 9 | 89 |
|
10
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
90 CSは複数のDS Managerを持っている。DSには対になるString型のkeyが存在し、それぞれのManagerにkeyを指定してDSにアクセスする。 |
| 9 | 91 一つのkeyに対して複数のDSをputするとFIFO的に処理される。なのでData Segment Managerは通常のデータベースとは異なる。 |
| 4 | 92 |
|
10
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
93 \subsection{Data Segment Manager} |
| 4 | 94 |
|
10
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
95 DS Manager（以下DSM）にはLocal DSMとRemote DSMが存在する。Local DSMは各ノード固有のデータベースである。 |
| 8 | 96 Remote DSMは他ノードのLocal DSMに対応するproxyであり、接続しているノードの数だけ存在する（図 \ref{fig:Remote DSM} ）。 |
| 4 | 97 他ノードのLocal DSMに書き込みたい場合はRemote DSMに対して書き込めば良い。 |
|
10
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
98 |
| 7 | 99 Remote DSMを立ち上げるには、DataSegmentクラスが提供するconnectメソッドを用いる。 |
| 100 接続したいノードのipアドレスとport番号、そして任意のManager名を指定することで立ちあげられる。その後はManager名を指定してData Segment APIを用いてDSのやり取りを行うため、プログラマはManager名さえ意識すればLocalへの操作もRemoteへの操作も同じ様に扱える。 | |
| 101 | |
| 4 | 102 \begin{figure}[h] |
| 103 \begin{center} | |
| 104 \includegraphics[width=70mm]{images/remote_datasegment.pdf} | |
| 105 \end{center} | |
| 106 \caption{Remote DSMは他のノードのLocal DSMのproxy } | |
| 8 | 107 \label{fig:Remote DSM} |
| 4 | 108 \end{figure} |
| 109 | |
| 110 | |
| 111 \subsection{Data Segment API} | |
| 112 DSの保存・取得にはAliceが提供するAPIを用いる。 | |
| 113 putとupdateはOutput DS APIと呼ばれ、DSをDSMに保存する際に用いる。 | |
| 114 peekとtakeはInput DS APIと呼ばれ、DSをDSMから取得する際に使用する。 | |
| 115 | |
| 116 \begin{itemize} | |
| 117 \item {\ttfamily void put(String managerKey, String key, Object val)} | |
| 118 \end{itemize} | |
| 8 | 119 DSをDSMに追加するためのAPIである。第一引数はLocal DSMかRemote DSMかといったManager名を指定する。そして第二引数で指定されたkeyに対応するDSとして第三引数の値を追加する。 |
| 4 | 120 \begin{itemize} |
| 121 \item {\ttfamily void update(String managerKey, String key, Object val)} | |
| 122 \end{itemize} | |
| 123 updateもDSをDSMに追加するためのAPIである。putとの違いは、queueの先頭のDSを削除してからDSを追加することである。そのためAPI実行前後でqueueの中にあるDSの個数は変わらない。 | |
| 124 | |
| 125 \begin{itemize} | |
| 126 \item {\ttfamily void take(String managerKey, String key)} | |
| 127 \end{itemize} | |
| 128 takeはDSを読み込むためのAPIである。読み込まれたDSは削除される。要求したDSが存在しなければ、CSの待ち合わせ （Blocking）が起こる。putやupdateによりDSに更新があった場合、takeが直ちに実行される。 | |
| 129 | |
| 130 \begin{itemize} | |
| 131 \item {\ttfamily void peek(String managerKey, String key)} | |
| 132 \end{itemize} | |
| 133 peekもDSを読み込むAPIである。takeとの違いは読み込まれたDSが削除されないことである。 | |
| 134 | |
| 6 | 135 |
| 4 | 136 \subsection{Code Segmentの記述方法} |
| 7 | 137 CSをユーザーが記述する際にはCodeSegmentクラスを継承して記述する(ソースコード \ref{src:StartCodeSegment} , \ref{src:CodeSegment})。 |
| 4 | 138 継承することによりCode Segmentで使用するData Segment APIを利用する事ができる。 |
| 139 | |
| 140 \begin{table}[html] | |
| 141 \lstinputlisting[label=src:StartCodeSegment, caption=StartCodeSegmentの例]{source/StartCodeSegment.java} | |
| 142 \lstinputlisting[label=src:CodeSegment, caption=CodeSegmentの例]{source/TestCodeSegment.java} | |
| 143 \end{table} | |
| 144 | |
| 145 Alice には、Start CS (ソースコード \ref{src:StartCodeSegment} )というC の main に相当するような最初に実行される CS がある。 | |
| 146 Start CSはどのDSにも依存しない。つまりInput DSを持たない。 | |
| 147 このCSをmainメソッド内でnewし、executeメソッドを呼ぶことで実行を開始させることができる。 | |
| 148 | |
| 149 ソースコード \ref{src:StartCodeSegment} は、5行目で次に実行させたいCS（ソースコード \ref{src:CodeSegment} ）を作成している。8行目でOutput DS APIを通してLocal DSMに対してDSをputしている。 | |
| 150 Output DS APIはCSの{\tt ods}というフィールドを用いてアクセスする。 | |
| 151 {\tt ods}は{\tt put}と{\tt update}を実行することができる。 | |
| 152 TestCodeSegmentはこの"cnt"というkeyに対して依存関係があり、8行目でputが行われるとTestCodeSegmentは実行される。 | |
| 153 | |
| 154 | |
|
10
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
155 CSのInput DSは、CSの作成時に指定する必要がある。指定はCommandType(PEEKかTAKE)、DSM名、そしてkey よって行われる。 |
|
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
156 Input DS API はCSの{\tt ids}というフィールドを用いてアクセスする。 |
|
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
157 Output DSは、{\tt ods}が提供するput/updateメソッドをそのまま呼べばよかったが、Input DSの場合{\tt ids}にpeek/takeメソッドはなく、create/setKeyメソッド内でCommandTypeを指定して実行する。 |
|
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
158 |
|
5
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
159 ソースコード\ref{src:CodeSegment}は、0から9までインクリメントする例題である。 |
|
10
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
160 2行目では、Input DS APIがもつcreateメソッドでInput DSを格納する受け皿(Receiver)を作っている。 |
|
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
161 引数には{\tt PEEK}または{\tt TAKE}を指定する。 |
| 4 | 162 \begin{itemize} |
| 163 \item {\ttfamily Receiver create(CommandType type)} | |
| 164 \end{itemize} | |
| 165 | |
| 166 4行目から6行目はコンストラクタである。コンストラクタはオブジェクト指向のプログラミング言語で新たなオブジェクトを生成する際に呼び出されて内容の初期化を行う関数である。 | |
| 167 | |
| 9 | 168 % TestCodeSegmentのコンストラクタが呼ばれた際には、 |
| 169 % \begin{enumerate} | |
| 170 % \item CSが持つフィールド変数 {\tt Receiver input}に{\tt ids.create(CommandType.TAKE)}が行われ、{\tt input}が初期化される。 | |
| 171 % \item 5行目にあるTestCodeSegmentのコンストラクタのTAKEが実行される。 | |
| 172 % \end{enumerate} | |
| 4 | 173 |
|
10
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
174 5行目は、2行目のcreateで作られたReceiverが提供するsetKeyメソッドを用いてLocal DSMからDSを取得している。 |
| 4 | 175 \begin{itemize} |
| 176 \item \verb+void setKey(String managerKey, String key)+ | |
| 177 \end{itemize} | |
| 178 setKeyメソッドはpeek/takeの実行を行う。どのDSMのどのkeyに対してpeekまたはtakeコマンドを実行させるかを指定できる。コマンドの結果がレスポンスとして届き次第CSは実行される。 | |
| 179 | |
| 9 | 180 実行されるrunメソッドの内容は |
| 4 | 181 \begin{enumerate} |
| 182 \item 10行目で取得されたDSをInteger型に変換してcountに代入する。 | |
| 183 \item 12行目でcountをインクリメントする。 | |
| 184 \item 16行目で次に実行されるCSが作られる。（この時点で次のCSはInput DSの待ち状態に入る） | |
| 185 \item 17行目でcountをLocal DSMにputする。Input DSが揃い待ち状態が解決されたため、次のCSが実行される。 | |
| 186 \item 13行目が終了条件であり、countの値が10になれば終了する。 | |
| 187 \end{enumerate} | |
| 188 となっている。 | |
| 189 | |
| 190 \section{Meta Computation} | |
| 191 Aliceでは、計算の本質的な処理をComputation、Computationとは直接関係ないが別のレベルでそれを支える処理をMeta Computationとして分けて考える。 | |
| 192 AliceのComputationは、keyによりDSを待ち合わせ、DSが揃ったCSを並列に実行する処理と捉えられる。 | |
| 193 それに対して、AliceのMeta Computation は、Remoteノードとの通信時のトポロジーの構成や切断・再接続の処理と言える。 | |
| 194 つまりトポロジーの構成はAliceのComputationを支えているComputationとみなすことができる。 | |
| 195 | |
| 7 | 196 Aliceの機能を追加するということはプログラマ側が使うMeta Computationを追加すると言い換えられる。 |
| 197 AliceではMeta Computationとして分散環境の構築等の機能を提供するため、プログラマはCSを記述する際にトポロジー構成や切断、再接続という状況を予め想定した処理にする必要はない。 | |
| 198 プログラマは目的の処理だけ記述し、切断や再接続が起こった場合の処理をMeta Computationとして指定する。 | |
| 4 | 199 このようにプログラムすることで、通常処理と例外処理を分離することができるため、仕様の変更を抑えたシンプルなプログラムを記述できる。 |
|
10
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
200 |
|
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
201 Meta Computationは、CSの処理を支えるMeta CSと、Meta CSに管理されるMeta DSとしても考えられる。 |
|
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
202 図\ref{fig:metaCS}は、AliceのMeta CS/Meta DSの接続関係の例である。 |
|
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
203 プログラマ側はCSとDSの依存関係を記述するが、その裏ではMeta CSやMeta DSが間に接続されて処理を行っている。 |
|
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
204 |
|
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
205 \begin{figure}[h] |
|
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
206 \begin{center} |
|
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
207 \includegraphics[width=70mm]{images/metaCS.pdf} |
|
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
208 \end{center} |
|
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
209 \caption{CS/DSの間にMetaCS/MetaDSが接続される} |
|
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
210 \label{fig:metaCS} |
|
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
211 \end{figure} |
|
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
212 |
| 6 | 213 現在Aliceには、動的・静的トポロジーの管理構成機能、ノードとの接続状態確認機能、切断・再接続時の処理を指定できる機能など、分散環境の実現に必要なさまざまなMeta Computationが用意されている。 |
| 4 | 214 |
|
10
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
215 |
|
5
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
216 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
217 \textbf{Topology Manager} |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
218 |
| 8 | 219 Aliceでは、ノード間の接続管理やトポロジーの構成管理を、Topology ManagerというMeta Computationが提供している。このTopology ManagerもCS/DSを用いて実装されている。 |
| 7 | 220 プログラマはトポロジーファイルを用意し、Topology Managerに読み込ませるだけでトポロジーを構成することができる。 |
|
5
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
221 トポロジーファイルはDOT Language\cite{dot}という言語で記述される。 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
222 DOT Languageとは、プレーンテキストを用いてデータ構造としてのグラフを表現するためのデータ記述言語の一つである。 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
223 ソースコード\ref{src:topologyfile}は3台のノードでリングトポロジーを組むときのトポロジーファイルの例である。 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
224 \begin{table}[html] |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
225 \lstinputlisting[label=src:topologyfile, caption=トポロジーファイルの例]{source/TopologyFile.dot} |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
226 \end{table} |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
227 また、DOT Languageファイルはdotコマンドを用いてグラフの画像ファイルを生成することができる。そのため、記述したトポロジーが正しいか可視化することが可能である。 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
228 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
229 Topology Managerはトポロジーファイルを読み込み、参加を表明したクライアント（以下、Topology Node）に接続するべきクライアントのIPアドレスやポート番号、接続名を送る（図\ref{fig:topologymanager}）。 |
| 8 | 230 また、トポロジーファイルでlavelとして指定した名前はRemote DSMの名前としてTopology Nodeに渡される。 |
|
5
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
231 そのため、Topology NodeはTopology ManagerのIPアドレスさえ知っていれば自分の接続すべきノードのデータを受け取り、ノード間での正しい接続を実現できる。 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
232 \begin{figure}[h] |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
233 \begin{center} |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
234 \includegraphics[width=60mm]{images/topologymanager.pdf} |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
235 \end{center} |
| 8 | 236 \caption{Topology Managerが記述に従いトポロジーを構成} |
|
5
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
237 \label{fig:topologymanager} |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
238 \end{figure} |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
239 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
240 また、実際の分散アプリケーションでは参加するノードの数が予め決まっているとは限らない。 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
241 そのためTopology Managerは動的トポロジーにも対応している。 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
242 トポロジーの種類を選択してTopology Managerを立ち上げれば、あとは新しいTopology Nodeが参加表明するたびに、Topology ManagerからTopology Nodeに対して接続すべきTopology Nodeの情報がputされ接続処理が順次行われる。 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
243 そしてTopology Managerが持つトポロジー情報が更新される。 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
244 現在Topology Managerでは動的なトポロジータイプとして二分木に対応している。 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
245 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
246 |
|
10
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
247 |
|
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
248 |
|
5
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
249 \textbf{KeepAlive} |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
250 |
| 8 | 251 ノード間通信はRemote DSMに対してputやtakeを行うことでのみ発生する。 |
| 6 | 252 アプリケーション次第では長時間通信が行われない可能性があり、その間にノード間接続が切れた場合、次の通信が行われるまで切断を発見することができない。 |
| 253 また、接続状態ではあるが応答に時間がかかる場合もある。 | |
| 254 | |
| 255 これらの問題を検知するために、KeepAliveという定期的にheart beatを送信し生存確認を行うMeta Computationがある。この機能もCS/DSを用いて実装されている。 | |
| 8 | 256 一定時間内にノードからの応答がない場合、KeepAliveにより、そのノードのRemote DSMが切断される。 |
| 6 | 257 |
| 258 また、トポロジーからノードが切断された際にトポロジーを再構成する機能もTopology Managerに用意した。 | |
| 259 例えばツリートポロジーでノードが切断された場合、そのノードの子ノードは全体のトポロジーから分断されてしまう。 | |
|
10
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
260 ノードは切断を検知するとただちにTopology Managerに再接続すべきノード情報を要求し、木を構成し直す。 |
|
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
261 |
| 6 | 262 \newpage |
| 263 | |
|
5
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
264 \textbf{切断・再接続時の処理} |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
265 |
| 6 | 266 MMORPGでは、試合の最中にサーバーからユーザーが切断された場合、自動的にユーザーが操作するキャラクターをゲームの開始時の位置に戻すという処理が実行される。 |
| 267 同様に、Aliceを用いたアプリケーションでもノードの切断時に対する処理を用意したい場合がある。 | |
| 7 | 268 そこで、Aliceが切断を検知した際に任意のCSを実行できる機能(ClosedEventManager)を追加した。プログラマは切断の際に実行したいCSを書き、ClosedEventManagerに登録しておけば良い(ソースコード\ref{src:closedEvent})。 |
| 6 | 269 \begin{table}[html] |
| 270 \lstinputlisting[label=src:closedEvent, caption=切断時に実行されるCSの登録方法]{source/RegisterEvent.java} | |
| 271 \end{table} | |
| 272 | |
| 273 また、再接続してきたノードに対し通常の処理とは別の処理を行わせたい場合がある。そのため、切断時と同様に再接続してきたノードに任意のCSを実行できるMeta Computationも用意した。 | |
| 274 | |
|
5
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
275 |
| 4 | 276 \section{AliceVNC} |
| 277 AliceのMeta Computationが実用的なアプリケーションの記述において有用であることを確認する。 | |
| 278 そのために、TreeVNCをAliceを用いて実装したAliceVNCの作成を行った。 | |
| 279 | |
| 280 TreeVNCとは、当研究室で開発を行っている授業向け画面共有システムである。 | |
| 281 オープンソースのVNCであるTightVNC \cite{tightVNC} をもとに作られている。 | |
| 282 授業でVNCを使う場合、１つのコンピュータに多人数が同時につながるため、性能が大幅に落ちてしまう。 | |
|
5
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
283 この問題をノード同士を接続させ、木構造を構成することで負荷分散を行い解決したものがTreeVNCである。 |
| 8 | 284 図 \ref{fig:TreeVNC}はAliceVNCを実現するための構成である。leftとrightのRemote DSMを用意し子ノードと接続することで木構造を実現する。 |
|
5
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
285 |
| 4 | 286 \begin{figure}[h] |
| 287 \begin{center} | |
| 288 \includegraphics[width=80mm]{images/TreeVNC.pdf} | |
| 289 \end{center} | |
| 290 \caption{AliceVNC の構造} | |
| 291 \label{fig:TreeVNC} | |
| 292 \end{figure} | |
| 293 | |
| 6 | 294 TreeVNCは通信処理部分や画面データの処理部分が１つのコード内で記述され、大変複雑になっている。しかし、Aliceで記述すればMeta Computationにより本質的な処理とそれを支える通信処理部分で分離できる。 |
| 295 TreeVNCでは3章で述べた動的なトポロジーの構成、切断ノードの発見、再接続・トポロジーの再構成といった通信処理のMeta Computationが活用できる。そのため、TightVNCからの修正の少ない、見通しの良い記述で構成可能と期待される。 | |
| 296 | |
| 297 | |
| 4 | 298 \section{Aliceの新機能} |
| 6 | 299 実用的なアプリケーションであるTreeVNCをAlice上で実装することで、Aliceに必要なMeta Computationを洗い出した。 |
| 4 | 300 \subsection{転送機能} |
| 7 | 301 Input DSをRecieverに取得したあと、プログラマはRecieverから値を任意の型で取り出し、値を操作した後putメソッドで再度別クラスに変換されOutput DSとして出力する。 |
| 6 | 302 しかし、Input DSとして取得したデータ形式のまま子ノードにOutput DSとして出力する場合、一度Recieverから取り出し再変換する操作は無駄である。 |
| 4 | 303 |
| 304 そこで、Input DSとして受け取ったDSをそのままOutput DSとして転送する機能をput/updateとは別にflipメソッドをData Segment APIに実装した。 | |
| 305 Input DSであるReceiverを展開せずにflipメソッドに引数として渡すことで、展開のオーバーヘッドをなくしている。 | |
| 306 TreeVNCでは親ノードから受け取った画面データをそのまま子ノードに配信するため、Meta Computationとして転送機能が有用である。 | |
| 307 | |
| 308 \subsection{Data Segmentの表現の追加（圧縮機能）} | |
| 309 TreeVNCでは画面配信の際、データを圧縮してノード間通信を行っている。 | |
| 310 そのため、AliceVNCにも圧縮されたデータ形式を扱える機能が必要だと考えた。 | |
| 311 しかし、ただデータを圧縮する機構を追加すればいいわけではない。 | |
| 312 | |
| 313 AliceVNCでは、ノードは受け取った画面データを描画すると同時に、子ノードのRemote DSMに送信する。 | |
| 314 ノードはDSを受信するとそれを一度解凍して画面を表示し、再圧縮して子ノードに送信する。 | |
| 315 しかし、受け取ったデータを自分の子ノードに対して送信する際には、解凍する必要はない。 | |
| 316 圧縮状態のまま子ノードに送信ができれば、解凍・再圧縮するオーバーヘッドを無くすことができる。 | |
| 317 | |
| 7 | 318 そこで、１つのData Segmentに対し複数の表現を持たせ、必要に応じた形式でDSを扱うことを可能にした。 |
|
10
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
319 Meta DSに相当するReceiveData.classに、次の3種類の表現を同時に持つことができるようにしたことで、データの多態性を実現した。 |
| 4 | 320 |
| 321 \begin{enumerate} | |
| 322 \item 一般的なJavaのクラスオブジェクト | |
| 7 | 323 \item MessagePack for Java\cite{MessagePack}でシリアライズ化されたバイナリオブジェクト |
| 4 | 324 \item 2を圧縮したバイナリオブジェクト |
| 325 \end{enumerate} | |
| 326 | |
| 8 | 327 Local DSMにputされた場合は、(1)の一般的なJavaクラスオブジェクトとして追加される。 |
| 328 Remote DSMにputされた場合は、通信時に(2)のbyteArrayに変換されたバイナリオブジェクトに変換されたDSが追加される。 | |
| 7 | 329 この2つの形式は従来のAliceが持っていた表現である。 |
| 8 | 330 今回、Remote DSMに圧縮形式での通信を行いたいため、(3)の圧縮表現を追加した。 |
| 7 | 331 |
| 332 ソースコード \ref{src:ReceiveData} はReceiveData.classが持つ表現である。 | |
| 333 {\tt val}に(1) 一般的なJavaのクラスオブジェクト の表現でデータ本体が保存される。 | |
| 334 {\tt messagePack}には(2) シリアライズ化されたバイナリオブジェクトが保存される。 | |
| 4 | 335 そして、{\tt zMessagePack}には(3) 圧縮されたバイナリオブジェクトが保存される。 |
|
10
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
336 このようにDSが複数の表現を同時に保持することで、DSが圧縮表現を持っている場合に再圧縮する必要はない。 |
| 4 | 337 |
| 338 \begin{table}[html] | |
| 339 \lstinputlisting[label=src:ReceiveData, caption=データを表現するクラス]{source/ReceiveData.java} | |
| 340 \end{table} | |
| 341 | |
| 8 | 342 また、圧縮表現を持つDSを扱うDSMとしてRemote DSMにCompressed Data Segment Managerを追加した。 |
| 4 | 343 Compressed DSMの内部では、put/updateが呼ばれた際にReceiveData.classが圧縮表現を持っていればそれを使用し、持っていなければその時点で圧縮表現を作ってput/updateを行う。 |
| 344 | |
| 8 | 345 ソースコード \ref{src:before} はRemote DSMに対しInt型のデータをputする記述である。 |
| 6 | 346 この通信を圧縮形式のDSで行いたい場合、ソースコード \ref{src:after} のように指定するDSM名の先頭に"compressed"をつければCompressed DSM内部の圧縮Meta Computationが走り圧縮形式に変換されたDSとなって通信が行われる。 |
| 4 | 347 |
| 348 \begin{table}[html] | |
| 349 \lstinputlisting[label=src:before, caption=通常のDSを扱うCSの例]{source/beforeCompress.java} | |
| 350 \end{table} | |
| 351 | |
| 352 \begin{table}[html] | |
| 353 \lstinputlisting[label=src:after,caption=圧縮したDSを扱うCSの例]{source/afterCompress.java} | |
| 354 \end{table} | |
| 355 | |
| 6 | 356 これによりユーザは指定するDSMを変えるだけで、他の計算部分を変えずに圧縮表現をDS内で持つことができる。 |
|
5
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
357 ノードは圧縮されたDSを受け取った後、そのまま子ノードにflipメソッドで転送すれば圧縮状態のまま送信されるので、送信の際の再圧縮がなくなる。 |
| 6 | 358 |
| 359 | |
|
10
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
360 画面表示の際はReceiveData.class内のasClassメソッドを使うことで適切な形式でデータを取得できる。 |
| 7 | 361 asClassメソッドはDSを目的の型にcastするためのメソッドである。 |
| 6 | 362 AliceVNCで圧縮形式を指定してDSを送信すると、それを受け取るDSMは圧縮形式のみを持ったDSとして保存する。 |
| 7 | 363 そしてasClassメソッドが呼ばれて初めて、メソッド内で解凍してcastが行われDSが複数の表現を同時に持つようになる。 |
| 364 これによりDSの表現を必要になったときに作成できるため、プログラマはどんな形式でDSを受け取ってもDSを編集可能な形式として扱うことができる。 | |
| 6 | 365 また、複数表現は必要なときにしか作成されないため、メモリ使用量も必要最低限に抑えることができる。 |
| 366 | |
| 4 | 367 \subsection{Aliceの通信プロトコルの変更} |
| 7 | 368 5.2で述べたように、Remoteからputされたデータは必ずシリアライズ化されておりbyteArrayで表現される。 |
| 369 しかし、データの表現に圧縮したbyteArrayを追加したため、RemoteからputされたbyteArrayが圧縮されているのかそうでないのかを判別がつかなくなった。 | |
| 4 | 370 |
| 7 | 371 そこで、Aliceの通信におけるヘッダにあたるCommandMessage.classに圧縮状態を表すフラグを追加した。 |
| 4 | 372 これによってputされたDSMはフラグに応じた適切な形式でReceiveData.class内にDSを格納できる。 |
| 373 また、CommandMessage.classに圧縮前のデータサイズも追加したことで、適切な解凍が可能になった。 | |
| 374 | |
| 375 \section{評価と考察} | |
| 376 TreeVNCをAlice上で構築するために必要な機能をAliceのMeta Computationとして実装した。 | |
|
10
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
377 これにより、AliceVNCが簡潔な記述でTreeVNCと同等の性能を出せれば、実用的な分散アプリケーションの実装においてAliceのMeta Computationは有用であるといえる。 |
| 4 | 378 そこで、TreeVNCとAliceVNCの性能評価としてメッセージ伝達速度の比較を、コードの評価としてコード量とその複雑度の比較を行った。 |
| 379 | |
| 380 また、AliceのMeta Computationの価値を明確にするため、他言語・フレームワークとの比較を行った。 | |
| 381 | |
| 382 \subsection{メッセージ伝達速度の比較} | |
| 383 TreeVNC/AliceVNCにおいて、配信する画像データは構成した木を伝ってノードに伝搬され、接続する人数が増える毎に木の段数は増えていく。 | |
| 384 そこで、木の段数ごとにメッセージの到達にどれぐらい時間がかかっているかを計測した。 | |
| 385 | |
|
10
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
386 |
|
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
387 |
| 4 | 388 \textbf{実験環境} |
| 389 | |
| 8 | 390 講義内で学生に協力してもらい、最大17名の接続がある中でTreeVNC、AliceVNC(圧縮・転送機能あり)、AliceVNC(圧縮・転送機能なし)の木の段数1〜3の測定を行った。 |
| 4 | 391 |
|
10
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
392 |
|
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
393 |
| 4 | 394 \textbf{実験内容} |
| 395 | |
|
5
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
396 ルートノードから画面データを子ノードに伝搬する際に、計測用のヘッダをつけたパケットを子ノードに送信する。 |
|
10
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
397 各子ノードはパケットを受け取り自身のViewerに画面データを表示すると同時に、計測用ヘッダ部分のみのDSを作成し、親ノードに送り返す。 |
| 4 | 398 計測用DSは木を伝ってルートノードまで送り返され、ルートノードは受け取った計測用DSから到達時間を計算する。 |
| 399 | |
| 400 計測用のヘッダは以下の要素で構成されている。 | |
|
10
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
401 \newpage |
| 4 | 402 \begin{table}[htbp] |
| 403 \caption{計測用ヘッダの変数名の説明} | |
| 6 | 404 \label{tb:mesure} |
| 4 | 405 \begin{center} |
| 406 \begin{tabular} {|l|l|} | |
| 407 \hline | |
| 408 変数名&説明\\ | |
| 409 \hline | |
| 410 time&ルートノードがパケットを送信した時刻\\ | |
| 411 \hline | |
| 412 depth&木の段数。初期値=1。\\ | |
| 413 \hline | |
| 414 dataSize&送信時の形式に変換済みの画面データのサイズ\\ | |
| 415 \hline | |
| 416 \end{tabular} | |
| 417 \end{center} | |
| 418 \end{table} | |
| 419 timeにはパケットの送信時刻を、dataSizeには画面データのサイズを付けて送信する。 | |
| 420 今回、TreeVNCとAliceVNC(圧縮・転送機能あり)では圧縮形式の画面データのサイズを、AliceVNC(圧縮・転送機能なし)ではMessegePack形式でのサイズをdataSizeにセットする。 | |
| 421 depthは各ノードに到達するごとにインクリメントされる。 | |
| 422 | |
|
10
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
423 到達時間の計算方法は、計測用DSを受け取った時刻とDSのtime（送信した時刻）の差をとる。 |
| 4 | 424 この到達時間は画面データがノードまで到達した時間と計測DSをルートまで送り返す時間を含めているが、送り返す時間は誤差として考える。 |
| 425 また、depthは各ノードに到達するごとにインクリメントされるため、送り返す際もインクリメントされる。そのため、木の段数を計算するにはdepthを1/2した値となる。 | |
| 426 | |
|
10
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
427 |
| 4 | 428 |
| 429 \textbf{実験結果} | |
| 430 | |
|
10
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
431 3段目の測定結果の散布図を示す（図\ref{fig:TreeVNC_delay} 〜 \ref{fig:AliceVNC_compress_delay}）。 |
| 4 | 432 X軸が画面データのサイズ(byte)、Y軸が計算した到達時間(ms)である。 |
| 433 実験時間の都合上、AliceVNC（圧縮・転送機能あり）の計測時間が他より短くなってしまったためプロットされた点の数が少なくなっている。 | |
|
5
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
434 また、それぞれの図で処理に10000ms以上かかっている点の集合が見られるが、これは今回の実験において3段目にPCのスペック上処理が遅いノードが1台あったためである。そのため比較においてこの点集合は無視する。 |
| 4 | 435 |
|
5
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
436 どの図も同様の傾向があり、画面データのサイズが小さいうちは処理時間も5ms程度だが、50000byte以上から比例して処理時間も遅くなっている。このことからAliceVNCはTreeVNCと同等の処理性能があることがわかる。 |
| 4 | 437 |
| 438 \newpage | |
| 439 \begin{figure}[h] | |
| 440 \begin{center} | |
| 441 \includegraphics[width=70mm]{images/TreeVNC_depth3.pdf} | |
| 442 \end{center} | |
| 443 \caption{TreeVNCの測定結果} | |
| 444 \label{fig:TreeVNC_delay} | |
| 445 \end{figure} | |
| 446 | |
| 447 \begin{figure}[h] | |
| 448 \begin{center} | |
| 449 \includegraphics[width=70mm]{images/AliceVNC_notcompress_depth3.pdf} | |
| 450 \end{center} | |
| 451 \caption{AliceVNC(圧縮・転送機能なし)の測定結果} | |
| 452 \label{fig:AliceVNC_notcompress_delay} | |
| 453 \end{figure} | |
| 454 | |
| 455 \begin{figure}[h] | |
| 456 \begin{center} | |
| 457 \includegraphics[width=70mm]{images/AliceVNC_compress_depth3.pdf} | |
| 458 \end{center} | |
| 459 \caption{AliceVNC(圧縮・転送機能あり)の測定結果} | |
| 460 \label{fig:AliceVNC_compress_delay} | |
| 461 \end{figure} | |
| 462 \newpage | |
| 463 | |
|
10
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
464 |
|
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
465 また、AliceVNCを圧縮機能の有無でデータサイズ比較すると、圧縮機能のないAliceVNCはデータサイズがほとんど1000byte以上なのに対し、圧縮機能のあるAliceVNCではTreeVNC同様10byte程度のサイズに抑えるので圧縮も成功している。 |
|
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
466 |
|
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
467 さらに転送機能の有無で比較した場合、転送機能がないAliceVNCでは木の段数に関係なく1000ms近く到達に時間がかかってしまっているが、転送機能のあるAliceVNCではデータサイズが大きくなっても100ms程度に抑えられている。これは転送機能が余計なコピーを防いでいるためだと考えられる。 |
|
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
468 このことから、圧縮・転送のMeta Computationは分散通信において有用であると言える。 |
| 4 | 469 \subsection{コードの比較} |
| 470 \textbf{コード量} | |
| 471 | |
| 472 TreeVNCとAliceVNCのコード量を比較した表が表\ref{tb:code}である。 | |
| 473 TightVNCを含むコード全体にwcを行い、行数と単語数を比較した。 | |
| 474 また、hg diffでTightVNCからの変更行数を調べ変更量を比較した。 | |
| 475 | |
| 476 表からわかるように、Aliceを用いればコードの行数が25\%削減できる。 | |
| 477 また、TreeVNCではTightVNCに大幅に修正を加えながら作成したため仕様の変更が多かった。 | |
| 478 しかし、AliceVNCではTightVNCにほとんど修正を加えることなくトポロジー構成等のAliceのMeta Computationを使うために新しいクラスを作成したのみであった。 | |
| 479 そのためTreeVNCに比べ75\%も仕様の変更が抑えられている。 | |
| 480 \begin{table}[htbp] | |
| 481 \caption{コード量の比較} | |
| 482 \label{tb:code} | |
| 483 \begin{center} | |
| 484 \begin{tabular} {|l|l|l|l|} | |
| 485 \hline | |
| 486 &行数&単語数&変更行数\\ | |
| 487 \hline | |
| 488 TreeVNC&19502&73646&7351\\%11369+8133=19502,47010+26636,2094+5257 | |
| 489 \hline | |
| 490 AliceVNC&14647&59217&1129\\%689+7094+6864=14647,23035+34610+1572,689+395+45 | |
| 491 \hline | |
| 492 減少率(\%)&25&20&75\\ | |
| 493 \hline | |
| 494 \end{tabular} | |
| 495 \end{center} | |
| 496 \end{table} | |
| 497 | |
|
10
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
498 |
| 4 | 499 \textbf{コードの複雑度} |
| 500 | |
| 501 コード量の比較で述べたように、TreeVNCはTightVNCからの変更が多い。 | |
| 502 その理由の一つがトポロジーの構成や通信処理がコアな仕様と分離できておらず、 | |
| 503 そのためTreeVNCは大変複雑な記述になってしまっている。 | |
| 504 | |
| 505 そこでTreeVNCとAliceVNCにおいてコードの複雑度を比較した。 | |
| 506 今回、複雑度の指標としてThomas McCabeが提案した循環的複雑度\cite{complaxy}を用いた。 | |
|
5
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
507 循環的複雑度とはコード内の線形独立な経路の数であり、if文やfor文が多ければ複雑度も高くなりバグ混入率も高まる。 |
| 4 | 508 一般的に、循環的複雑度が10以下であればバグ混入率の少ない非常に良いコードとされる。 |
| 509 計測にはIntelliJのCodeMetrics計測プラグインであるMetricsReloadedを使用した。 | |
| 510 | |
| 511 表\ref{tb:complex}はTightVNC、TreeVNC、AliceVNCにおける循環的複雑度の比較である。 | |
| 512 プロジェクト全体でのクラスの複雑度の平均値と最高値をとった。 | |
| 513 平均値・最高値ともにAliceVNCのほうが複雑度が低いことから、Aliceではシンプルな記述が可能だということがわかる。 | |
|
5
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
514 |
| 7 | 515 TreeVNCで最高値を出したTreeRFBProto.classは全てプログラマが記述したコードであり、データの待ち合わせのためのタイマー処理や通信処理、画面データの圧縮処理などの複数のスレッド処理が集中した複雑なコードになっている。 |
| 516 これをAliceで記述した場合、データの待ち合わせはCSが行うためプログラマがデータの不整合を気にする必要はなく、また通信処理や圧縮処理もMeta Computationが提供するためコードが複雑になることはない。 | |
|
5
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
517 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
518 AliceVNCで複雑度の最高値を出したSwingViewerWindow.classはTightVNCで最高値を出したクラスと同じであり、コード量の比較でも示したようにAliceVNCで変更を加えた点がほとんどない。つまりこの複雑度は元来TightVNCが持っている複雑度と言える。 |
| 4 | 519 |
| 520 \begin{table}[htbp] | |
| 521 \caption{複雑度の比較} | |
| 522 \label{tb:complex} | |
| 523 \begin{center} | |
| 524 \begin{tabular} {|l|l|l|} | |
| 525 \hline | |
| 526 &平均値&最高値\\ | |
| 527 \hline | |
| 528 TightVNC&13.63&97\\ | |
| 529 \hline | |
| 530 TreeVNC&15.33&141\\ | |
| 531 \hline | |
| 532 AliceVNC&10.95&99\\%(4.12+13.64)/2 (4.12+9.16+19.59)/3 | |
| 533 \hline | |
| 534 \end{tabular} | |
| 535 \end{center} | |
| 536 \end{table} | |
| 537 | |
| 538 AliceVNCとTreeVNCの性能比較・コード比較から、AliceVNCはTreeVNCと同等の性能を持つ分散アプリケーションの記述ができ、かつコードの修正量・複雑度共に低く抑える能力を有することがわかった。 | |
| 539 | |
| 540 \subsection{他言語・フレームワークとの比較} | |
|
5
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
541 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
542 Aliceが採用しているCS/DSのプログラミングモデルやMeta Computationの特性を明確にするため、他言語・フレームワークとの類似点・相違点を比較した。 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
543 |
| 4 | 544 \textbf{Erlang} |
| 545 | |
|
5
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
546 並列指向プログラミング言語Erlang\cite{Erlang}は、プロセスと呼ばれるid付きの独立したタスクに対して、データをメッセージでやりとりする。 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
547 タスクをプロセスという細かい単位に分割して並列に動かす点や、メモリロックの仕組みを必要としない点はAliceと同様である。 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
548 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
549 しかしErlangでは分散環境の構築等はすべてプログラマ自身が記述しなければならない。 |
| 7 | 550 Aliceでは分散環境の構築はTopology ManagerなどのMeta Computationが行うためプログラマはトポロジーを指定するだけで良い。 |
|
5
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
551 また、Erlangでは複数のデータの待ち合わせのための再帰処理も自分で書かないといけない。 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
552 一方、Aliceのプログラミング手法はCSが必要なデータが全て揃うまで待ち合わせを行うためその必要はない。 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
553 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
554 |
| 4 | 555 \textbf{Akka} |
| 556 | |
|
5
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
557 Akka\cite{Akka}はScala・Java向けの並列分散処理フレームワークである。 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
558 アクターモデルを採用しており、アクターと呼ばれるアドレスを持ったタスクに、データをメッセージでやりとりする点がErlangと似ている。 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
559 AkkaもErlangもプロセス/アクターに直接データをやりとりする。データには名前がないため、メッセージを受け取ったあとにその内容を確認した上で次にどう振る舞うかを判断する。 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
560 一方Aliceでは、DSをCSに直接やりとりはせず、keyを指定してDSMにputする。 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
561 また、DSをtakeするときもkeyを指定して取り出すためどんなデータが入っているかを確認する必要がなく、扱い易い。 |
| 4 | 562 |
|
5
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
563 Akkaの特徴として、メッセージを送りたいプロセスのアドレスを知っていればアクターがどのマシン上にあるかを意識せずにプログラミングできるという点がある。 |
| 8 | 564 逆にAliceはどのRemote DSMに対してやり取りをするかを考慮するが、CSがOutputしたDSを次にどのCSに渡すかを意識する必要がない。この点はアクターモデルとCS/DSモデルのパラダイムの違いと言える。 |
|
5
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
565 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
566 一方AliceとAkkaは提供されるAPIという点で類似している。AkkaのメッセージAPIでは、メッセージを送るtellメソッドと、メッセージを送って返信を待つaskメソッドが用意されている。これはAliceのDataSegment APIのput/takeメソッドに対応している。 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
567 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
568 また、Akkaのもう一つの特徴として、アクターで親子関係を構成できる点がある。 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
569 分散通信部分を子アクターに分離し、親アクターは子アクターのExceptionが発生した時に再起動や終了といった処理を指定できる。 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
570 さらにRouterという子アクターへのメッセージの流れを制御するアクターや、Dispatcherというアクターへのスレッドの割当を管理する機能をAkkaが提供している。 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
571 このように処理を階層化し複雑な処理をフレームワーク側が提供する仕組みはAliceのMeta Computationと共通している。 |
|
10
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
572 相違点としては、AliceのMeta DSのようにデータの多態性を実現する機能はAkkaにはない。 |
| 4 | 573 |
| 574 | |
| 575 \section{まとめ} | |
|
5
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
576 並列分散フレームワークAliceでは、スケーラブルかつ信頼性の高いプログラムを記述する環境を実現するため、CS/DSの計算モデルとMeta Computationによる実装の階層化を採用している。 |
|
10
5774c70506ae
last-update of paper
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
9
diff
changeset
|
577 Aliceが実用的な分散アプリケーションを記述するために必要なMeta Computationとして、多態性を持つデータを扱う機能や無駄なコピーなくデータを転送する機能を実装した。 |
|
5
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
578 そしてMeta Computationを用いて分散アプリケーションTreeVNCをAlice上で実装し性能評価を行った。 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
579 その結果、TreeVNCで使用される基本機能はAliceでも実現でき、同等の性能を出すことができるということが分かった。 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
580 またコードの観点からTreeVNCとAliceVNCを比較した結果、Aliceが仕様の変更を抑えたシンプルな記述を実現し、信頼性の高い実用的な分散アプリケーションを構築するに有用であることが確認された。 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
581 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
582 今後の課題としては、TreeVNCで実装が困難であったNATを超えたノード間通信をAliceVNCで実現し、その性能とコード修正量を比較することが挙げられる。 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
583 図\ref{fig:overNAT}は２つの違うプライベートネットワークを超えた接続の設計例である。 |
| 4 | 584 |
|
5
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
585 \begin{figure}[h] |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
586 \begin{center} |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
587 \includegraphics[width=75mm]{images/overNAT.pdf} |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
588 \end{center} |
| 8 | 589 \caption{複数のTopology ManagerでNAT超えを実現} |
|
5
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
590 \label{fig:overNAT} |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
591 \end{figure} |
| 4 | 592 |
|
5
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
593 各ネットワークごとにTopoogy Managerを立ち上げることでネットワークを超えたノード間接続を実現する。 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
594 プライベートネットワークのTopoogy Managerは今までどおりネットワーク内に木を構築・管理する。 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
595 他のネットワークにあるノードBがノードAに接続したい場合は、グローバルアドレスを持ったTopology Managerに参加表明をすればノードAの情報が提供され、ノードAの子ノードとして接続される。 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
596 つまり、Topology Managerを複数用意するだけで、Topology Manager自体の「参加表明のあったノードで木を構成する」という仕様は全く変更しないで良い。 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
597 TreeVNCでは500行以上の変更が必要とされたが、Aliceでは複数のTopology Managerに接続するためのconfigファイルを変更するだけなので、AliceVNCの仕様の変更を抑えられると期待される。 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
598 この機能も実現できれば、AliceのMeta Computationが拡張性の高い環境を提供できると言える。 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
599 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
600 また、現在のAliceはネットワーク通信においてセキュリティをサポートしていない。 |
| 7 | 601 しかし、圧縮機能と同様に、暗号化形式を扱うMeta Computationを追加すれば、プログラマが記述するComputation部分を大きく変えずに自由度の高い通信を行うことができる。 |
|
5
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
602 |
|
50de9b120af4
add comparison & conclusion
Nozomi Teruya <e125769@ie.u-ryukyu.ac.jp>
parents:
4
diff
changeset
|
603 |
| 4 | 604 |
| 605 | |
| 606 | |
| 607 \nocite{*} | |
| 608 \bibliographystyle{ipsjunsrt} | |
| 609 \bibliography{prosym} | |
| 610 | |
| 611 | |
| 612 \end{document} |