Mercurial > hg > Papers > 2016 > parusu-thesis
changeset 5:15eff3ba94ce
Add images
author | Tatsuki IHA <e125716@ie.u-ryukyu.ac.jp> |
---|---|
date | Mon, 08 Feb 2016 02:49:01 +0900 |
parents | 77b8edf27879 |
children | 9289e0444448 |
files | paper/images/checkDelay.graffle paper/images/checkDelay.pdf paper/images/directConnection.graffle paper/images/directConnection.pdf paper/images/shareScreenToMultiDisplay.graffle paper/images/shareScreenToMultiDisplay.pdf paper/images/treeVnc.graffle paper/images/treeVnc.pdf paper/images/zrle.graffle paper/images/zrle.pdf paper/images/zrleFail.graffle paper/images/zrleFail.pdf paper/images/zrlee.graffle paper/images/zrlee.pdf paper/main.tex |
diffstat | 15 files changed, 54 insertions(+), 24 deletions(-) [+] |
line wrap: on
line diff
--- a/paper/main.tex Fri Feb 05 00:02:39 2016 +0900 +++ b/paper/main.tex Mon Feb 08 02:49:01 2016 +0900 @@ -1,5 +1,5 @@ \documentclass[a4j,12pt]{jreport} -\usepackage[dvips]{graphicx} +\usepackage[dvipdfmx]{graphicx} \usepackage{mythesis} \usepackage{multirow} \usepackage{here} @@ -103,7 +103,7 @@ TreeVNC は クライアント同士を接続させ、画面描画のデータを受け取ったクライアントが次のクライアントにデータを流す方式を取っている。 また、サーバへ接続しに来たクライアントをバイナリツリー状に接続する(図\ref{fig:tree})。 -バイナリツリー状に接続することで、$N$台のクライアントが接続しに来た場合、画面配信の画像データをコピーする回数は従来の VNC ではサーバ側で$N$回する必要があるが、TreeVNCでは各ノードが2回ずつコピーするだけで済む。 +バイナリツリー状に接続することで、$N$ 台のクライアントが接続しに来た場合、画面配信の画像データをコピーする回数は従来の VNC ではサーバ側で$N$ 回する必要があるが、TreeVNCでは各ノードが2回ずつコピーするだけで済む。 TreeVNCで通信される画像のデータ量は大きいため、大きなネットワークスループットが必要である。 そのため、有線接続が必須である。 @@ -112,9 +112,9 @@ Root Node は子 Nodeにデータを流す機能に加え、各 Node の管理、 VNC サーバーから流れてきた画像データの管理を行う。 Node は 親 Node から送られたデータを 自分の子 Node に流す機能、 逆に子 Node から送られてきたデータを 親 Node に流す機能がある。 -\begin{figure}[ht] +\begin{figure}[htbp] \begin{center} - \includegraphics[width=70mm]{./pic/TreeVNC.pdf} + \includegraphics[scale=0.8]{./images/treeVnc.pdf} \end{center} \caption{構成される木構造} \label{fig:tree} @@ -128,13 +128,30 @@ Zlib は java.util.zip.deflater と java.util.zip.inflater で圧縮と解凍が行える。 しかし、 java.util.zip.deflater は解凍に必要な辞書を書き出す(flush)ことが出来ない。 -辞書を書き出すことが出来ないため、 Zlib圧縮されたデータを途中から受け取ってもデータを正しく解凍することが出来ない。 +そのため図\ref{fig:zrleFail} のように、 Zlib圧縮されたデータを途中から受け取ってもデータを正しく解凍することが出来ない。 -そこで ZRLEE は 一度 Root Node で受け取った ZRLE のデータを unzip し、 データをzip し直して最後に finish() をいれることで初めからデータを呼んでいなくても解凍を行えるようにした。 +そこで ZRLEE は 一度 Root Node で受け取った ZRLE のデータを unzip し、 データをzip し直して最後に finish() をいれることで初めからデータを呼んでいなくても解凍を行えるようにした(図\ref{fig:zrlee})。 一度 ZRLEE に変換してしまえば子 Node はそのデータをそのまま流すだけで良い。 ただし、deflater と inflater では前回までの通信で得た辞書をクリアしないといけないため、 Root Node と Node 側では毎回新しく作る必要がある。 +\begin{figure}[htbp] + \begin{center} + \includegraphics[scale=0.6]{./images/zrleFail.pdf} + \end{center} + \caption{ZRLEでの問題点} + \label{fig:zrleFail} +\end{figure} + +\begin{figure}[htbp] + \begin{center} + \includegraphics[scale=0.6]{./images/zrlee.pdf} + \end{center} + \caption{ZRLEE} + \label{fig:zrlee} +\end{figure} + + \section{通信経路} TreeVNC の通信経路として以下が挙げられる \begin{itemize} @@ -201,16 +218,26 @@ \begin{figure}[ht] \begin{center} - \includegraphics[width=65mm]{./pic/message.pdf} + \includegraphics[width=65mm]{./images/message.pdf} \end{center} \caption{node 間で行われるメッセージ通信} \label{fig:message} \end{figure} \section{MulticastQueue} -画用データの送信は MulticastQueue という Queue で行っている。 +配信側の画面が更新されると、 VNCServer から画像データがFRAME_BUFFER_UPDATE メッセージとして送られる。 +その際、 画像データの更新を複数の Node に同時に伝えるため、 MulticastQueue というキューに画像データを格納する。 + MulticastQueue は java.util.concurrent.CountDownLatch を用いて実装されている。 +CountDownLatch は java の並列用のAPIで他のスレッドで実行中の操作が完了するまで、複数のスレッドを待機させることが出来るクラスである。 +CountDownLatch を初期化する際にカウントを設定することができる。 +このカウントはスレッドを開放する際に使用し、 await メソッドでカウントが0になるまでメソッドをブロックする事ができる。 +MulticastQueue は put メソッドを使用して データを queue に追加する。 +put の際に CountDownLatch をカウントダウンする。 +poll メソッドを使用することで Queue のデータを取得することが出来る。 +poll メソッドの実行の際に await メソッドが使われているため、 次の put でデータが来るまでスレッドをブロックする。 +スレッドをブロックされた場合 新しいデータが put されると CountDownLatch がカウントダウンされるため、 データの読み込みが再開される。 \section{木の再構成} TreeVNC はバイナリツリーでの接続という特性上 Node が切断されたことを検知できずにいると、Node 同士で構成された木構造が崩れてしまい、新しい Node が接続に来た場合に適切な場所に Node を接続することができなくなってしまう。 @@ -219,9 +246,9 @@ TreeVNC の木構造のネットワークトポロジーは Root Node が持っている nodeList というリストで管理している。 つまり、Node の接続が切れた場合、木の再構成を行うため Root Node に知らせなければならない。 -TreeVNC は Lost\_CHILD というメッセージ通信で Node の切断を検知・木の再構成を行っている。 +TreeVNC は LOST\_CHILD というメッセージ通信で Node の切断を検知・木の再構成を行っている。 -TreeVNC は VNC サーバーから送られる画像データ(FRAME\_BUFFER\_Update)を MulticastQueue というキューに蓄積しており、 +TreeVNC は VNC サーバーから送られる画像データ(FRAME\_BUFFER\_Update)を MulticastQueue に蓄積しており、 Node はこのキューから画像データを取得し、画面を描画している。 Lost\_Child の検出方法はこの MulticastQueue を使用している。 ある一定時間 MulticastQueue から画像データが取得されない場合 Memory Over Flow を回避するために Timeout スレッドが用意されている。 @@ -238,7 +265,7 @@ \begin{figure}[ht] \begin{center} - \includegraphics[width=70mm]{./pic/lostChild1.pdf} + \includegraphics[width=70mm]{./images/lostChild1.pdf} \end{center} \caption{LOST\_CHILD を検知・再接続} \label{fig:lostchild1} @@ -249,7 +276,6 @@ \section{共有画面切り替え} ゼミでは発表者が順々に入れ替わる。発表者が入れ替わる度に共有する画面の切り替えが必要となる。 -ゼミを円滑に進めるために、画面の切り替えをスムーズに行いたい。 画面の共有にプロジェクタを使用する場合、 発表者が変わる度にケーブルの抜き差しを行う必要がある。 その際に、ディスプレイ解像度を設定し直す必要が出たり、 接続不良が起こる等の煩わしい問題が生じることがある。 @@ -264,7 +290,7 @@ VNC サーバーから画面データを受信し、そのデータを 子 Node へと送信している。 配信者切り替え時に Share Screen ボタンが押されると、 Root Node は Share Screen ボタン を押したクライアントの VNC サーバーと通信を始める。 -そのためTreeVNCは配信者切り替えの度に VNC を終了し、再接続する必要がない。 +そのため TreeVNC は配信者切り替えの度に VNC を終了し、再接続する必要がない。 \section{複数のネットワークの対応} 従来の TreeVNC は、クライアントの接続する木構造が単一であった。 @@ -274,7 +300,7 @@ \begin{figure}[ht] \begin{center} - \includegraphics[width=70mm]{./pic/MultiNetworkTree.pdf} + \includegraphics[width=70mm]{./images/MultiNetworkTree.pdf} \end{center} \caption{Multi Network Tree} \label{fig:multinetworktree} @@ -309,7 +335,7 @@ \begin{figure}[ht] \begin{center} - \includegraphics[width=70mm]{./pic/shareScreenToMultiDisplay.pdf} + \includegraphics[width=70mm]{./images/shareScreenToMultiDisplay.pdf} \end{center} \caption{マルチディスプレイへの対応} \label{fig:multidisplay} @@ -332,7 +358,7 @@ \begin{figure}[ht] \begin{center} - \includegraphics[width=80mm]{./pic/directConnection.pdf} + \includegraphics[width=80mm]{./images/directConnection.pdf} \caption{遠隔地 Node からの接続} \label{fig:directConnection} \end{center} @@ -365,7 +391,6 @@ データ計算方法を以下の Code \ref{calc}に記述する。 この変数 time は CHECK\_DELAY\_REPLY に付いている CHEKC\_DELAY の送信時刻である。 \begin{table}[htb] - \begin{lstlisting}[label=calc, caption=遅延時間の計算方法] Long delay = System.currentTimeMillis() - time; \end{lstlisting} @@ -390,18 +415,23 @@ \begin{figure}[ht] \begin{center} - \includegraphics[width=60mm]{./pic/depth1.eps} - \end{center} - \begin{center} - \includegraphics[width=60mm]{./pic/depth2.eps} + \includegraphics[scale=0.8]{./images/depth1.eps} \end{center} \begin{center} - \includegraphics[width=60mm]{./pic/depth3.eps} + \includegraphics[scale=0.8]{./images/depth2.eps} + \end{center} + \caption{深さ1,2のデータサイズと遅延の関係} + \label{fig:depth} +\end{figure} + +\begin{figure}[ht] + \begin{center} + \includegraphics[scale=0.8]{./images/depth3.eps} \end{center} \begin{center} - \includegraphics[width=60mm]{./pic/depth4.eps} + \includegraphics[scale=0.8]{./images/depth4.eps} \end{center} - \caption{深さ毎のデータサイズと遅延の関係(上から深さ1, 2, 3, 4)} + \caption{深さ3, 4のデータサイズと遅延の関係} \label{fig:depth} \end{figure} % 今後の課題