Mercurial > hg > Papers > 2015 > sugi-master
view paper/chapter2.tex @ 14:b9b3f2241ab4
modify chapter2
author | sugi |
---|---|
date | Tue, 13 Jan 2015 17:10:56 +0900 |
parents | ef47dab5764f |
children | 930eae4e8aeb |
line wrap: on
line source
\chapter{Aliceを使った例題} \label{chapter:chapter2} この章ではAliceを用いて作成されたアプリケーションを紹介する。これらのアプリケーションでAliceの性能テスト、必要な機能の洗い出しを行っている。 \section{AliceVNC} \label{section:AliceVNC} AliceVNCは、当研究室で開発を行っているTreeVNCをAliceを用いて実装された、授業向け画面共有システムである。 授業でVNCを使う場合、1つのコンピュータに多人数が同時につながるため、性能が大幅に落ちるという問題がある(図\ref{fig:vnc})。この問題をノード同士を接続させ、木構造を構成することで負荷分散を行い解決したものがTreeVNCである(図\ref{fig:treestructure})。TreeVNCは、TightVNCのソースコードを利用して開発されている。 \begin{figure}[htbp] \begin{minipage}{0.5\hsize} \begin{center} \includegraphics[width=80mm]{images/vnc.pdf} \end{center} \caption{VNCの構造} \label{fig:vnc} \end{minipage} \begin{minipage}{0.5\hsize} \begin{center} \includegraphics[width=80mm]{images/treestructure.pdf} \end{center} \caption{TreeVNC, AliceVNCの構造} \label{fig:treestructure} \end{minipage} \end{figure} しかし、TreeVNCにも問題が存在する。ノードを木構造にするためアプリケーション内で管理する必要があるが、不特定多数のノードを管理することは容易ではない。また、通信プロトコルは、TightVNCのプロトコルを拡張して利用している。アプリケーション層でプロトコルを拡張する場合、サーバとクライントの両方のプログラムコードを変更する必要があり、プロトコル処理部の保守性を維持していくことが難しい。 実際に、プロトコルを拡張したことにより予想外のエラーでTreeVNCが強制終了することがある。 さらに、TighVNCのアップデートに対応する必要がある。だが、アップデートによってはパッケージ構成が変更され、元のコードが残っていないことも考えられる。この場合、新しいTightVNCに作成した機能を1つずつ移行するしなければならないためコストが高い。 %分散アプリケーションは、デバックが行い難くエラーを再現することですら難しい。 これらの問題は、分散フレームワークAliceを使うことで解決することができる。ノードの管理は全てAliceが行なうため、プログラマーは画面共有の処理のみ記述すれば良い。プロトコルはAlice上で構築することでTightVNCのプロトコルと干渉することがないため、エラーが起こった場合はAliceで記述したコードのみを確認すればよい。 アップデートの問題に関しては、TightVNCに必要なデータをputする処理さえ追加すれば良いため、問題なく対応できるはずである。 Aliceが以上の問題に対応できることを証明するため、また実用的なアプリケーションの記述が可能であるかを検証するためAliceVNCの開発を行った。 \subsection{AliceVNCの原理} 従来のVNCとTreeVNCの構造を比較した図を(図\ref{fig:comparenormalandtree})に示す。 \begin{figure}[!htbp] \begin{center} \includegraphics[width=130mm]{images/comparenormalandtree.pdf} \end{center} \caption{AliceVNCの構造} \label{fig:comparenormalandtree} \end{figure} 表\ref{tb:oneporttraffic}はポート一本あたりの通信量である。従来のVNCの場合、ポート一本あたりの負荷はノード数に比例して増える。しかし、AliceVNCの場合はTreeの子供の数が一定なので、Node数に関係なく一定である。通信量が増えるほど、CPUに負荷がかかり性能が低下する。AliceVNCの場合、通信量は一定なので性能が低下せず使用することができる。 \begin{table}[htbp] \caption{ポート一本あたりの通信量(NはNode数、MはTreeの子供の数)} \label{tb:oneporttraffic} \begin{center} \begin{tabular}{|c|c|c|} \hline & 従来のVNC & AliceVNC \\ \hline 通信量 & N * データ量 & (M + 1) * データ量 \\ \hline \end{tabular} \end{center} \end{table} \subsection{表示画面の切り替え} ゼミなど発表者が多数いる場合、発表者が変わるたびにアプリケーションを立ち上げ直すのは手間である。 そのため、アプリケーションに切り替えの機能を実装するのが望ましい。そこで、AliceVNCに切り替えの機能を実装した。 TreeVNCにも同様に切り替え機能が存在するが、AliceVNCの切り替え機能と挙動が異なる(図\ref{fig:changeTree} \ref{fig:changeAlice})。 \begin{figure}[htbp] \begin{minipage}{0.5\hsize} \begin{center} \includegraphics[width=80mm]{images/changeTreeVNC.pdf} \end{center} \caption{TreeVNCにおける切り替え} \label{fig:changeTree} \end{minipage} \begin{minipage}{0.4\hsize} \begin{center} \includegraphics[width=80mm]{images/changeAliceVNC.pdf} \end{center} \caption{AliceVNCにおける切り替え} \label{fig:changeAlice} \end{minipage} \end{figure} %図の変更 TreeVNCの場合、Root Nodeが常にVNCServerと接続するため、切り替えが行われる際にはRoot Nodeが画面共有のrequestを出したノードと接続を行う。 AliceVNCの場合、Root Nodeではなく画面共有のrequestを出したノードが自分自身のVNCServerと接続を行う。そのため、AliceVNCは、VNC Serverとノード間にネットワーク遅延が無いという利点がある。 しかし、図 \ref{fig:changeAlice}のように底辺にいるノードが配信を行った場合、1度Root Nodeまでデータを上げる必要がある。従って、全ノードにデータが行き渡るにはTreeVNCと比べ2倍の時間がかかる。 \section{水族館ゲーム} Aliceで作成された始めての分散アプリケーションである。Aliceに分散アプリケーションを記述する能力があることを確かめるために作成された。 過去にFederated Lindaでも作成されている。UIとしてJava7から組み込まれたJavaFxが使用されている。 アプリケーションを起動すると参加したノード1台ごとに1つウインドウが表示される。表示されたウインドウの中にユーザが操作可能な魚が1匹表示されている。魚は画面端まで移動すると自分の画面上からは消え、隣のプレイヤーの画面端に表示される。 %画像挿入 \subsection{処理の流れ} 図\ref{fig:NodeToClient}はデータの伝搬の様子をコラボレーションダイアグラムで示したものである。 \begin{enumerate} \item ユーザーが魚を操作することで魚の座標のData SegmentであるfishDataが更新される。 \item \label{point:replyData} fishDataが魚のオブジェクトに座標をセットするためのCode Segment であるSetLocationにreplyされる。 \item SetLocationが実行され魚が移動する。 \item 他のノードに更新されたfishDataを送信するためのCode SegmentであるSendDataにfishDataがreplyされる。 \item SendDataに自分と接続されているノード一覧のData Segmentであるlistがreplyされる。 \item \label{point:sendData} SendDataはlistを参照してfishDataを送信する。 \item 各clientで\ref{point:replyData} から\ref{point:sendData} が実行され、fishPositionが全体で共有される。 \end{enumerate} \ref{point:sendData}ではlistを参照して、利用可能なRemote Data SegmentにData Segmentをputしているが、この利用可能なRemote Data Segmentの中にはData Segmentを送信してきたものが含まれている。全てのRemote Data Segmentに送信してしまうと同じData Segmentを永遠にやりとりすることになる。しかし、Data Segmentは送信元のメタ情報が付加されており、このメタ情報を利用して送信元のRemote Data Segmentに対してfishDataを送り返すことを防いでいる。 \begin{figure}[htbp] \begin{center} \includegraphics[width=110mm]{images/NodeToClient.pdf} \end{center} \caption{データの伝搬の様子} \label{fig:NodeToClient} \end{figure} \section{木構造をデータベースJungle} JungleはスケーラビリティのあるCMSの開発を目指して当研究室で開発されている非破壊的木構造データベースである。 \section{bitonic sort} bitnic sortは並列ソートであり、Aliceがマルチコアに対応していることを確認するため実装した。 \begin{figure}[htbp] \begin{center} \includegraphics{images/sortflow.pdf} \end{center} \caption[width=100mm]{sort flow} \label{fig:sortflow} \end{figure} \subsection{処理の流れ} 指定された数の乱数を生成し、Sortを行う例題である。 また、図\ref{fig:bitonicSort}はSortされるまでの流れをコラボレーションダイアグラムで示したものである。 \begin{enumerate} \item SetTask (Code Segment)が乱数列を分割してarray1とarray2にputする。 \item \label {fig:start}replyされたData SegmentをSort (Code Segment)で昇順に整列させる。 \item \label {fig:end}整列された配列を分割する。上半分をarray1-F、下半分をarray1-Bにputする。 \item 分割した各数列(array2)に対しても同様に \ref{fig:start}と\ref{fig:end}を行う。 \item \label {fig:start2}replyされた2つのData Segment(array1-B、array2-F)を合体させ、整列させる。 \item 整列された配列の上半分をarray1-B、下半分をarray2-Fにputする。 \item \label {fig:start1}replyされた2つのData Segment(array1-F、array1-B)を合体させ、整列させる。 \item \label {fig:end1}整列された配列の上半分をarray1-F、下半分をarray1-Bにputする。 \item \label {fig:end2}array2に対しても操作 \ref {fig:start1} と\ref {fig:end1} を行う。 \item \ref {fig:start2} - \ref {fig:end2} を繰り返し行うことで全体がSortされる。 \end{enumerate} \begin{figure}[htbp] \begin{center} \includegraphics{images/bitonicsort.pdf} \end{center} \caption{Aliceにおけるbitonic sortの動き} \label{fig:bitonicSort} \end{figure}