Papers/2016/parusu-thesis: paper/main.tex comparison

comparison paper/main.tex @ 14:84e12a138c37

Add TreeVNC theory

author	Tatsuki IHA <e125716@ie.u-ryukyu.ac.jp>
date	Sat, 13 Feb 2016 19:00:18 +0900
parents	bcd8506cd151
children	1890002fd43b

comparison

equal deleted inserted replaced

-:bcd8506cd151
+:84e12a138c37
 \begin{figure}[htbp]
 \begin{center}
 \includegraphics[scale=0.8]{./images/vnc.pdf}
 \end{center}
-\caption{VNC}
+\caption{VNCの構造}
 \label{fig:vnc}
 \end{figure}
 \section{TreeVNC の構造}
 TreeVNC は Java を用いて作成された TightVNC(Tight Virtual Network Computing)\cite{tightvnc} を元に作成されている。
 \caption{構成される木構造}
 \label{fig:tree}
 \end{figure}
 \section{TreeVNC の原理}
-TreeVNC のの原理を書く予定
+従来の VNC と TreeVNC の構造を比較を図\ref{fig:treeVncTheory}に示す。
-\begin{itemize}
-\item 従来のVNC : Node数 * データ量
+\begin{figure}[htbp]
-\item TreeVNC   : (2(子供の数) + 1) * データ量
+\begin{center}
-\end{itemize}
+\includegraphics[scale=0.5]{./images/treeVncTheory}
-% 従来のVNCはNode数に比例
+\end{center}
-% TreeVNCはNode数に関係なく一定
+\caption{構成される木構造}
-% 計算式 従来 N * データ量, TreeVNC (M+1) * データ量
+\label{fig:treeVncTheory}
+\end{figure}
+表\ref{tb:treeVncTheory}はポート一本あたりの通信量である。
+通常の VNC の場合、クライアント数に比例してポート一本あたりの負荷が増えている。
+TreeVNC の場合は1つの Node に対して2台の Node が接続するため、クライアント数関係なく一定である。
+送信するデータ量も通常の VNC の場合 Node 数に比例した量のデータを送信する必要があり、 CPU に負荷がかかってしまう。
+それに対して TreeVNC はクライアントが増えても送信するデータはクライアント毎に分散されているため、1台の CPU に掛かる負荷は一定となる。
+そのため、性能が低下せずに画面配信を行うことが出来る。
+\begin{table}[htbp]
+\begin{center}
+\caption{ポート一本あたりの通信量(N はノード数)}
+\begin{tabular}{|l|l|l|} \hline
+& 通常の VNC   & TreeVNC \\ \hline
+通信量 & N * データ量 & (2 + 1) * データ量 \\ \hline
+\end{tabular}
+\label{tb:treeVncTheory}
+\end{center}
+\end{table}
 \section{圧縮形式}
 TreeVNC は ZRLEE\cite{taninari:2012a} というエンコードでデータのやり取りを行う。
 ZRLEE はRFB プロトコルで使えるエンコーディングタイプの ZRLE を元に生成される。
 \section{ノード間で行われるメッセージ通信}
 RFBプロトコルで提供されているメッセージに加え、 TreeVNC 独自のメッセージを使用している。
 TreeVNC で使用されるメッセージの一覧を表\ref{tb:message}に示す。
-\begin{table}[htb]
+\begin{table}[htbp]
 \caption{通信経路とメッセージ一覧}
 \scriptsize
 \begin{tabular}{|l|l|l|} \hline
 通信経路            & message                    & 説明 \\ \hline \hline
 & FIND\_ROOT                 & TreeVNC接続時にRoot Nodeを探す。 \\ \cline{2-3}
 Root Node の保持しているネットワーク毎にTreeManager を生成する用に変更を行った。
 新しい Node が接続してきた際、 interfaces から Node のネットワークと一致する TreeManager を取得し、 Node 接続の処理を任せる。
 そのため、 TreeVNC が複数のネットワーク別に木構造を構成することが可能となる。
 \chapter{NAT 対応}
+\section{遠隔地からの接続}
+TreeVNC は 木構造を所属しているネットワークでしか生成しておらず
 \section{DirectConnection}
 遠隔地からでもゼミや授業に参加できるよう、 NATを越えたネットワークから TreeVNC への接続を可能にした。
 図\ref{fig:directConnection} にNATを越えたネットワークからの接続を示す。
 別ネットワークからTreeVNCに参加する際、 直接配信側のネットワークの Root Node に接続を行う。
 \caption{遠隔地 Node からの接続}
 \label{fig:directConnection}
 \end{center}
 \end{figure}
-\chapter{TreeVNC の追加機能}
+\chapter{TreeVNC のリファクタリング}
 \section{マルチディスプレイ対応}
 画面配信側のPCがマルチディスプレイの場合 VNC サーバーからは複数の画面全体の画像データが送信されてしまう。
 授業やゼミ等でTreeVNCを使用する場合、複数画面の表示は必要ない。
 そこで、画面を共有する際、ディスプレイを選択させ、画面共有を行う機能を追加した。
 Root Node は SERVER\_CHANGE\_REQUEST を受け取ると、 配信状態を維持したまま、画面切り替え用に新しくスレッドを生成する。
 切り替え用のスレッドは切り替えに必要なデータの設定、 VNC サーバー への接続など通常の切り替え処理を実行する。
 切り替えが完了した後に、 現在配信中の画面を停止し、画面の切替を行う。
 切り替え用のスレッドを用意することで、配信状況を維持したままスムーズな画面切り替えが可能になった。
-\section{ネックになっているノードへの対処}
 \section{クライアントへのエラー通知}
 TreeVNC には接続しているクライアントへのエラーの通知を行うことが出来なかった。
 そのため、 画面切り替えを行う際に切り替え先が VNC サーバーの共有設定をしていない場合 Root Node に接続エラーのダイアログが表示されるという実装になっており、切り替えを行ったクライアントには通知されていなかった。
 CHECK\_DELAY\_REPLY を受け取った Root Node はメッセージと画像データの伝達にどれだけの時間がかかったかを計算する。
 データ計算方法を以下の Code \ref{calc}に記述する。 この変数 time は CHECK\_DELAY\_REPLY に付いている CHEKC\_DELAY の送信時刻である。
 \begin{lstlisting}[label=calc, caption=遅延時間の計算方法]
 Long delay = System.currentTimeMillis() - time;
 \end{lstlisting}
 \section{結果}
 バイナリツリーで木を構成した場合、 Node 数が17台だと深さが4となる。
 各木構造の階層毎に、画像データの伝搬にかかった時間を測定した。
-図\ref{fig:depth1}は遅延の分布を示した散布図である。
+図\ref{fig:depth1}, \ref{fig:depth2}, \ref{fig:depth3}, \ref{fig:depth4}は遅延の分布を示した散布図である。
 X軸はメッセージ伝達にかかった秒数(ms)、 Y軸は画像データのサイズ(Byte)である。
 画像データの伝達はほぼ1秒以内に収まっているが、容量が小さい場合でも時間がかかる場合がある。
 それはその送信の前に大容量の画像を送信した後の回線のDelayが残っているためだと考えられる。
 また、深さ3で極端に遅い場合がある。 遅い原因として、1つの Node がボトルネックになっていることが判明している。
-このような極端に遅い Node をそのまま木に配置した場合、その Node の子 Node 以下に影響を及ぼす場合がある。
+このような極端に遅い Node をそのまま木に配置した場合、その Node の子 Node 以下に影響を及ぼすおそれがある。
-そのため、遅い Nodeを検出して、木の最後尾に移動させる機能が必要である。
+\begin{figure}[htbp]
-\begin{figure}[ht]
+\begin{center}
-\begin{center}
+\includegraphics[scale=0.7]{./images/depth1.eps}
-\includegraphics[scale=0.8]{./images/depth1.eps}
+\end{center}
-\end{center}
+\caption{データサイズと遅延の関係 : 深さ1}
-\begin{center}
-\includegraphics[scale=0.8]{./images/depth2.eps}
-\end{center}
-\caption{深さ1,2のデータサイズと遅延の関係}
 \label{fig:depth1}
 \end{figure}
-\begin{figure}[ht]
+\begin{figure}[htbp]
 \begin{center}
-\includegraphics[scale=0.8]{./images/depth3.eps}
+\includegraphics[scale=0.7]{./images/depth2.eps}
 \end{center}
-\begin{center}
+\caption{データサイズと遅延の関係 : 深さ2}
-\includegraphics[scale=0.8]{./images/depth4.eps}
-\end{center}
-\caption{深さ3, 4のデータサイズと遅延の関係}
 \label{fig:depth2}
 \end{figure}
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics[scale=0.7]{./images/depth3.eps}
+\end{center}
+\caption{データサイズと遅延の関係 : 深さ3}
+\label{fig:depth3}
+\end{figure}
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics[scale=0.7]{./images/depth4.eps}
+\end{center}
+\caption{データサイズと遅延の関係 : 深さ4}
+\label{fig:depth4}
+\end{figure}
+\section{ボトルネックになっているノードへの対処}
 % 今後の課題
 \chapter{まとめ}
 \section{NATを越えた画面切り替え}
 \section{新機能の評価}

Mercurial > hg > Papers > 2016 > parusu-thesis

comparison paper/main.tex @ 14:84e12a138c37