\chapter{TreeVNCの実装}
\label{chap:introduction}
\pagenumbering{arabic}


\section{木の生成}
今回は、ホストに対しクライアントがツリー状に繋がっていくように実装した。ツリー\\
の構成は以下の手順で行う。
　\begin{enumerate}
  \item クライアントが接続する際、ホストに接続をしているプロキシ（今後このプロ\\
キシのことをTopと記述する）に接続する。
　\item Topはクライアントの接続を受けると、どこに接続すれば良いかをクライアントに教える(この時にクライアントにシリアルナンバーを振っていく)。
　\item クライアントはTopから指定されたノードに接続を行う。
　\end{enumerate}
\subsection{Topの仕事}
Topはクライアントが接続してくるたびにjava.util.LinkedListにクライアントの情報を追加していく。

クライアントからアクセスが来るたびにスレッドを作成しているので、
複数のクライアントが同時に接続してきても対応することができる。
しかし、多数のスレッドが同じjava.util.LinkedListなどの共有資源に対して同時に接続を行うと
共有資源の情報が正しく更新されない可能性が出てくる。
このような共有資源を更新する際はjavaのsynchronizedメソッドを使用して複数のスレッドが共有資源
に同時にアクセスすることができないようにした。

TopはtreeBranch(木の分木数)を定数で持っていて
クライアントが接続してくるごとにcounterをインクリメントしていき
LinkedListの(counter - 1)/treeBranche番目に入っている親の情報を
接続してきたクライアントに教えることで木を構成することができる。
\newpage
\section{木の再構成}
木を構成することはできたが途中のクライアントが落ちてしまった場合に木を再構成しなければならない。
木を再構成する手順は以下の用に行う。
　\begin{enumerate}
  \item 子供が親が落ちたことをTopに対して報告する。
　\item Topは番号の一番大きいノード(最後のノード)に対して落ちた親の代わりになるように報告する。
　\item クライアントはTopから指定されたノードに接続を行う。
　\end{enumerate}


\newpage
\section{クライアントとの通信}
TreeVNCは、受け取った画面の描画データをそのまま自分に繋がっている次のクライアントに送信する。
描画データを受け取ったクライントはまた次のクライアントへデータをそのまま送信する。
内部では、まず受け取った描画データの読み込みを先に行いBytebufferでコピーを行う。
次にクライアントへの送信と自身のビューアへの描画を並列に行う。


\subsection{データの先読み}
1回のFramebufferUpdateで送られくるデータ量はエンコードタイプまで読みこめば知ることができる。
例えば、RAWエンコードの場合は width * height * 4 のバイト数が送られてくる(4はピクセルのデータ量である)。
計算で求めた数の分とヘッダーを合わせた数だけバイトを読み込むことで
1回分のFramebufferUpdateのコピーを行うことができる。

\subsection{FramebufferrUpdate}
RFB プロトコルでの画面の描画の更新は、FramebufferUpdateで行われる。
FramebufferUpdateを受け取ることで画面の再描画が行われる。
FrameBufferUpdateでは、メッセージタイプと画面の矩形の数がまず送られ、
次にx座標、y座標、横幅、縦幅、エンコードのタイプ、描画データが矩形の数だけ送ら\\
れてくる。
描画データはエンコードのタイプに従った方法で送られてくる。

\subsection{MulticastQueue}
画面が更新された際に更新をクライアントに伝えなければならない。ノードが多数ある場合、一人一人に更新を知らせるのではなく、同時に画面の更新を知らせたい。
同時に更新を知らせるために、CountDownLatchを用いてMultiCastQueueを作成した。

java.util.concurrent.CountDownLatchはjavaの並列用に用意されたAPIで
他のスレッドで実行中の操作が完了するまで、複数のスレッドを待機させることのできるクラスである。

使い方は、カウント(何回カウントしたらスレッドを開放するのかの数)を指定してCountDownLatchの初期化を行う。

countDownメソッドを使うとカウントダウンを行うことができる。

awaitメソッドはcowntDownメソッドの呼び出しの結果カウントがゼロになるまでの間スレッドをブロックすることができる。

countDwonメソッドの結果がゼロになるとawaitメソッドで停止していたスレッドが動き出す。



MulticastQueueはQueueのように使用することができる。
データをputメソッドするとデータがqueueに追加される。データをputする際にCountDownLatchをカウントダウンする。
pollメソッドを持ちいることで、次のデータを取得することができる。
pollメソッドの中でawaitが使われているので次のputでデータが来るまでスレッドがブロックする。
このようなことを行うことでデータの更新が来た際に複数のクライアントに対して並列にデータを転送することが出来る。
\vspace{5mm}


\begin{figure}[tb]
\begin{center}
\includegraphics[scale = 0.7]{fig/multicastqueue.eps}
\end{center}
\caption{
クライアントへは並列にデータを送信する。
}
\label{figure:multicastqueue}
\end{figure}

\newpage 

\subsection{TimeOut}
MultiCastQueueを使ってのデータの取得には問題が発生した。
それは、接続してきたクライアントがデータを取得しない状況、例えばサスペンド状態になったときにTopのメモリの中にデータが残り続けるというものである。
メモリに残り続けたデータはやがてメモリオーバーフローを引き起こしてしまうのである。その様子を図5.2に示す。


\begin{figure}[tb]
\begin{center}
\includegraphics[scale = 0.8]{fig/TimeOut2.eps}
\end{center}
\caption{
クライアントサスペンド時のTopのメモリの様子。
データが残り続けメモリを圧迫してしまう。
}
\label{figure:TimeOut2.eps}
\end{figure}


そこで、ある一定の時間がたつと代わりにデータを取得してくれるTimeOut用のスレッドを作成した。
TimeOutスレッドはサスペンドしているクライアントの代わりにデータを取得する。

\begin{figure}[tb]
\begin{center}
\includegraphics[scale = 0.8]{fig/TimeOut3.eps}
\end{center}
\caption{
TimeOutが代わりにデータを取得する
}
\label{figure:TimeOut3.eps}
\end{figure}


TimeOutスレッドがクライアントの代わりにデータを取得することで、MulticastQueueの中からデータが削除されTopのメモリを圧迫することがなくなった。(図5.3)

\newpage 

\section{圧縮の問題}
VNCで扱うRFB プロトコルには、使えるエンコーディングのタイプの1つとしてZRLE(Zlib Run-Length Encoding)がある。
ZRLEはZlibで圧縮されたデータとそのデータのバイト数がヘッダーとして付けられ送られてくる。
Zlibはフリーのデータ圧縮及び解凍を行うライブラリである。
可逆圧縮アルゴリズムの圧縮と解凍が行えるjava.util.zip.deflaterとjava.util.zip.inflaterを実装している。

\subsection{java.util.zip.deflaterの実装の問題}
Zlib圧縮は辞書を持っていて、その辞書に登録されているデータを元に解凍が行われる。(図5.4)
しかし、java.util.zip.deflaterは現在持っている辞書を書き出すこと(flush)ができないことが分かった。
辞書を書きだすことができない為、Zlib圧縮されたデータを途中から受け取ってもデータが正しく解凍を行うことができない。
(図5.5)
%元々のZlibの規約にはこの辞書をflushする機能があったがJavaには実装されていなかった。

\begin{figure}[!htbp]
\begin{center}
\includegraphics[scale = 0.6]{fig/ZRLE.pdf}
\end{center}
\caption{
test
}
\label{figure:ZRLE}
\end{figure}


\begin{figure}[!htbp]
\begin{center}
\includegraphics[scale = 0.6]{fig/ZRLE2.pdf}
\end{center}
\caption{
test
}
\label{figure:ZRLE2}
\end{figure}


\subsection{ZRLEE}
そこで、TopがZRLEで受け取ったデータをunzipし、データをzipし直して最後にfinish()
をいれることで初めからデータを読んでいなくても解凍を行えるようにした(毎回新しい辞書を使うようにした)。
このエンコードはZRLEEエンコードと定義した。
一度ZRLEEエンコードに変換してしまえば、そのデータをそのまま流すだけで良い。
よって変換はTopが行う一回だけですむ。
ただし、deflater,inflaterでは前回までの通信で得た辞書をクリアしないといけないため、
Topとクライアント側では毎回新しく作る必要がある(クライアント側はinflaterだけ)。
また、ZRLEEはクライアント側が対応していなければならないという問題がある。

\begin{figure}[!htbp]
\begin{center}
\includegraphics[scale = 0.7]{fig/ZRLEE2.pdf}
\end{center}
\caption{
test
}
\label{figure:ZRLEE2}
\end{figure}

\begin{figure}[!htbp]
\begin{center}
\includegraphics[scale = 0.7]{fig/ZRLEE3.pdf}
\end{center}
\caption{
test
}
\label{figure:ZRLEE3}
\end{figure}





\subsubsection{ZRLEとZRLEEのデータ圧縮率の比較}
RAW,ZRLE,ZRLEEのデータ量の比較を行った。                                        
図6は1920 * 1080の画面の全描画にかかるデータ量を測った結果を示した図である。
ZRLEEの方がデータ量が少なくですんでいる。                                          
これは、ZRLE(Zlib)が初めに送られた辞書を用いての解凍が余り有効的に働いていない
場合があるからだと思われる。                                                    
つまりVNCの場合はZRLEEの様に毎回辞書のデータを付加させて送ってもデータ量に差が
でない可能性があることが分かった。                                              


\begin{figure}[!htbp]
\begin{center}
\includegraphics[scale = 0.8]{fig/compare_encoding.eps}
\end{center}
\caption{
RAW,ZRLE,ZRLEEによる1画面(1920*1080)描画にかかるデータ量。
x軸はピクセル数、y軸はバイト数を表している。
}
\label{figure:compare_encoding}
\end{figure}


\newpage


\section{UserInterface}
\subsection{プロキシの検索}
TreeVNCはクライアントが起動した際にBroadcastをもちいて、
同一セグメント内にプロキシが起動しているかを調べる。
プロキシはクライアントからBroadcastのリクエストが飛んでくると、
リクエストのあったクライアントに対してソケットを張ってクライアントに自分の情報を教える。
クライアントは上記の要領で同一セグメント内にあるプロキシの情報を得ることができるので、
同一セグメントに有るプロキシの一覧を表示することができるのでクライアントはその中から
どの画面に接続するかを選択することができる。

\subsection{TreeVNCの使い方}
今回作成したTreeVNCはクライアントが使いやすいように設計を行った。
TreeVNCはまずプロキシを起動させる事が必要である。
プロキシを始動するには-pオプションを指定してやる事で
localhostに対してVNC要求を出すことができる。
この時自分の画面にアクセス要求が来るので画面を共有を認証するとプロキシが立ち上がる。

別のコンピュータに対して画面共有を行いたい場合は-pオプションを指定してやるか
、第一引数にIpAddress,第二引数にportを指定してやる事で別のコンピュータの
画面共有も行う事ができる。

クライアントは引数なしで実行すると(ダブルクリックで実行できる)
現在つなぐ事のできるプロキシの一覧が表示されるので、選択すると画面共有を行うことができる。

しかし、説明したとおりBroadcastを使用してプロキシの検索を行っているので、
別セグメントで起動しているプロキシを見つける事ができない。
そこで、TreeVNCを起動する際に-cオプションを付けてやる事で、
アドレス入力欄が表示されるので、そこに接続したいプロキシのアドレスを
入力する事で、別セグメントのプロキシとも画面共有を行えるようにした。

\newpage
\section{LionAuthenticate}
プロキシがサーバに対してVNC接続を行う際、ハンドシェイクが必要となる。
ハンドシェイクの手順として、まず始めにプロキシがサーバに接続を行うと、
サーバがサポートする最新のプロトコルバージョンが送られてくる。
プロキシはサーバから送られてきたプロトコルバージョン以下の使用できるバージョンを
サーバに対し送り、