# HG changeset patch
# User riono <e165729@ie.u-ryukyu.ac.jp>
# Date 1581441534 -32400
# Node ID 2acb79484a9990fd9b4accd64aecc94dd555956f
# Parent  9dd78e00f833082d85916b5bfb3034a20d883aa4
update chapter2 "ZRLEE"

diff -r 9dd78e00f833 -r 2acb79484a99 FinalThesis/chapter2.tex
--- a/FinalThesis/chapter2.tex	Tue Feb 11 22:11:47 2020 +0900
+++ b/FinalThesis/chapter2.tex	Wed Feb 12 02:18:54 2020 +0900
@@ -121,7 +121,42 @@
 \end{center}
 \end{figure}
 
+LOST\_CHILDによって、切断された全てのNodeを検知することができるため、nodeListの更新が正しく行われる。よって、新しく接続を行ってきたNodeを適切な場所に接続することが可能となる。
+
 \section{データの圧縮形式}
+TreeVNCはZRLEEというエンコードタイプでデータのやり取りを行う。ZRLEEはRFBプロトコルで使用できるZLREというエンコードタイプを元に生成される。
+
+ZLREはZlibで圧縮されたデータとそのデータのバイト数がヘッダーとして付与され送信される。Zlibはjava.util.zip.deflaterとjava.util.zip.inflaterで圧縮と解凍が行える。しかしjava\.util.zip.deflaterは解凍に必要な辞書を書きだす(flush)ことが出来ない。従って、圧縮されたデータを途中から受け取ってもデータを正しく解凍することが出来ない。
+
+そこでZRLEEは一度Root Nodeで受け取ったZRLEのデータをunzipし、後述するupdate Rectangleと呼ばれる画面ごとのデータに辞書を付与してzipし直すことで、初めからデータを読み込んでいなくても解凍を出来るようにした(\ref{fig:ZRLEtoZRLEE})。
+
+
+
+
+
+
+TreeVNCではRFBプロトコルによって配信側の画面の変更部分はFRAME\_BUFFER\_UPDATEメッセージとして送られてくる。メッセージの中には変更部分の原点のx,y座標と縦横の幅が含まれており、長方形として展開される。この長方形をupdate Rectangleと呼ぶ。以下の表\ref{tb:updateRectangle}にupdate Rectangleの構成を示す。
+
+\begin{table}[hp]
+    \caption{updateRectangleの構成}
+    \begin{center}
+    \begin{tabular}{|rrr|l|} \hline
+        1 byte & & & messageID    \\
+        1 byte & & & padding   \\
+        2 byte & & & n of rectangles   \\ \hline
+        & 2 byte & & U16 - x-position  \\
+        & 2 byte & &  U16 - y-position  \\
+        & 2 byte & &  U16 - width  \\
+        & 2 byte & &  U16 - height  \\
+        & 4 byte & &  S32 - encoding-type  \\
+        & 4 byte & &  U32 datalengths   \\ \hline
+        &  & 1 byte & subencoding of tile     \\
+        &  & n byte & Run Length Encoded Tile \\ \hline
+    \end{tabular}
+    \end{center}
+    \label{tb:updateRectangle}
+\end{table}
+
 
 
 \section{ShareScreen}
diff -r 9dd78e00f833 -r 2acb79484a99 FinalThesis/main.pdf
Binary file FinalThesis/main.pdf has changed