--- a/paper/chapter4.tex	Wed Feb 15 15:55:35 2012 +0900
+++ b/paper/chapter4.tex	Thu Feb 23 16:31:56 2012 +0900
@@ -1,4 +1,4 @@
-\chapter{TreeVNCの実装}
+\chapter{TreeVNCの設計}
 \label{chap:introduction}
 \pagenumbering{arabic}
 
@@ -18,105 +18,5 @@
 今回作成したTreeVNCは、上記の実装でツリー状にクライアントを接続していくように実装を行い画面の共有だけを行うように実装した。
 
 TreeVNCはTightVNCのjava版のビューアを元に作成を行った。実装の細かい内容は以下で説明する。TreeVNCはTightVNCのjava版のビューアを元に作成を行った。
-\newpage
-\section{木の生成}
-今回は、ホストに対しクライアントがツリー状に繋がっていくように実装した。ツリーの構成は以下の手順で行う。
-　\begin{enumerate}
-  \item クライアントが接続する際、ホストに接続をしているプロキシ（今後このプロキシのことをTopと記述する）に接続する。
-　\item Topはクライアントにどこに接続すれば良いかを知らせる。
-　\item クライアントはTopから指定されたノードに接続を行う。
-　\end{enumerate}
-\subsection{Topの仕事}
-Topはjava.util.LinkedListでクライアントの情報を保持している。
-
-TopはtreeBranch(木の分木数)を定数で持っていて
-クライアントが接続してくるごとにcounterをインクリメントしていき
-LinkedListの(counter - 1)/treeBranche番目に入っている親の情報を
-接続してきたクライアントに教えることで木を構成することができる。
-\newpage
-\section{木の再構成}
-後で書く
-\newpage
-\section{クライアントとの通信}
-TreeVNCは、受け取った画面の描画データをそのまま自分に繋がっている次のクライアントに送信する。
-描画データを受け取ったクライントはまた次のクライアントへデータをそのまま送信する。
-内部では、まず受け取った描画データの読み込みを先に行いBytebufferでコピーを行う。
-次にクライアントへの送信と自身のビューアへの描画を並列に行う。
-\subsection{FramebufferrUpdate}
-RFB プロトコルでの画面の描画の更新は、FramebufferUpdateで行われる。
-FramebufferUpdateを受け取ることで画面の再描画が行われる。
-FrameBufferUpdateでは、メッセージタイプと画面の矩形の数がまず送られ、
-次にx座標、y座標、横幅、縦幅、エンコードのタイプ、描画データが矩形の数だけ送られてくる。
-描画データはエンコードのタイプに従った方法で送られてくる。
-
-\subsection{MulticastQueue}
-画面が更新された際に更新をクライアントに伝えなければならない。ノードが多数ある場合、一人一人に更新を知らせるのではなく、同時に画面の更新を知らせたい。
-同時に更新を知らせるために、CountDownLatchを用いてMultiCastQueueを作成した。
-
-CountDownLatch一回CountDownされたときに待機しているスレッドを解放するように宣言する。更新情報が来るまでawaitを用いてスレッドを待機させる。更新情報が来たときCountDownを行う。すると、スレッドが開放されるので同時に更新情報を参照することができる。
-\newpage
-
-\begin{figure}[tb]
-\begin{center}
-\includegraphics[scale = 0.5]{fig/multicastqueue.eps}
-\end{center}
-\caption{
-クライアントへは並列にデータを送信する。
-}
-\label{figure:splaying}
-\end{figure}
 
-\subsection{TimeOut}
-MultiCastQueueを使ってのデータの取得には問題が発生した。
-それは、接続してきたクライアントがデータを取得しない状況、例えばサスペンド状態になったときにTopのメモリの中にデータが残り続けるというものである。
-メモリに残り続けたデータはやがてメモリオーバーフローを引き起こしてしまうのである。その様子を図2.2に示す。
 
-\begin{figure}[!htbp]
-\begin{center}
-\includegraphics[scale = 0.5]{fig/TimeOut2.eps}
-\end{center}
-\caption{
-クライアントサスペンド時のTopのメモリの様子。
-データが残り続けメモリを圧迫してしまう。
-}
-\label{figure:splaying}
-\end{figure}
-
-そこで、ある一定の時間がたつと代わりにデータを取得してくれるTimeOut用のスレッドを作成した。
-TimeOutスレッドはサスペンドしているクライアントの代わりにデータを取得する。
-
-\begin{figure}[!htbp]
-\begin{center}
-\includegraphics[scale = 0.5]{fig/TimeOut3.eps}
-\end{center}
-\caption{TimeOutが代わりにデータを取得する}
-\label{figure:splaying}
-\end{figure}
-
-TimeOutスレッドがクライアントの代わりにデータを取得することで、MulticastQueueの中からデータが削除されTopのメモリを圧迫することがなくなった。
-
-\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圧縮は辞書を持っていて、その辞書に登録されているデータを元に解凍が行われる。
-しかし、java.util.zip.deflaterは現在持っている辞書を書き出すこと(flush)ができないことが分かった。
-辞書を書きだすことができない為、Zlib圧縮されたデータを途中から受け取ってもデータが正しく解凍を行うことができない。
-%元々のZlibの規約にはこの辞書をflushする機能があったがJavaには実装されていなかった。
-
-\subsection{ZRLEE}
-そこで、TopがZRLEで受け取ったデータをunzipし、データをzipし直して最後にfinish()
-をいれることで初めからデータを読んでいなくても解凍を行えるようにした(毎回新しい辞書を使うようにした)。
-このエンコードはZRLEEエンコードと定義した。
-一度ZRLEEエンコードに変換してしまえば、そのデータをそのまま流すだけで良い。
-よって変換はTopが行う一回だけですむ。
-ただし、deflater,inflaterでは前回までの通信で得た辞書をクリアしないといけないため、
-Topとクライアント側では毎回新しく作る必要がある(クライアント側はinflaterだけ)。
-また、ZRLEEはクライアント側が対応していなければならないという問題がある。
-
-\section{UserInterface}
-\section{lionAuthenticate}
-

--- a/paper/thesis-paper.tex	Wed Feb 15 15:55:35 2012 +0900
+++ b/paper/thesis-paper.tex	Thu Feb 23 16:31:56 2012 +0900
@@ -49,6 +49,9 @@
 % 設計方針
 \input{chapter4.tex}
 
+% 設計
+\input{chapter5.tex}
+
 % 今後の課題
 %\input{chapter5.tex}