# HG changeset patch
# User Nobuyasu Oshiro  <dimolto@cr.ie.u-ryukyu.ac.jp>
# Date 1312799516 -32400
# Node ID 185665b0270d62127b4136725ec3ce9d90e45892
# Parent  4a40637a65920ec9aff2b25e028567caf43250c9
commit yuu-jssst.tex

diff -r 4a40637a6592 -r 185665b0270d yuu-jssst.pdf
Binary file yuu-jssst.pdf has changed
diff -r 4a40637a6592 -r 185665b0270d yuu-jssst.tex
--- a/yuu-jssst.tex	Mon Aug 08 19:06:42 2011 +0900
+++ b/yuu-jssst.tex	Mon Aug 08 19:31:56 2011 +0900
@@ -125,6 +125,44 @@
 \end{figure}
 
 
+\section{java.util.zip.deflaterのバグ}
+VNCで扱うRfb Protocolには、使えるエンコーディングのタイプとしてZRLEエンコードがある。
+ZRLEエンコードはZlib圧縮されたデータを内包する。
+deflaterはプリセット辞書をもち、Zlib圧縮されたデータはその辞書を用いて解凍が行われる。
+辞書はで更新されることもあるのでZlib圧縮されたデータを解凍する為には辞書のデータも受け取る必要がある。
+しかし、JavaにはこのZlibの辞書を相手へ書きだす(flush)する機能が無い。
+元々のZlibの規約にはこの辞書をflushする機能があったがJavaには実装されていなかった。
+これはJava。util。zop。deflaterのバグである。
+
+
+\section{ZRLEEエンコード}
+そこで、Top ProxyがZRLE(Zlib)で受け取ったデータをunzipし、データをzipし直して最後にfinish()
+をいれることで初めからデータを読んでいなくても解凍を行えるようにした。
+このエンコードはZRLEEエンコードと定義した。
+一度ZRLEEエンコードに変換してしまえば、そのデータをそのまま流すだけで良い。
+よって変換はProxyが行う一回だけですむ。
+ただし、deflaterでは前回までの通信で得た辞書をクリアしないといけないため、Client側では毎回
+deflaterは新しいものを使うことになる。
+ZRLEEはクライアント側が対応していなければならないという問題がある。
+
+
+\section{ZRLEとZRLEEのデータ圧縮率の比較}
+
+
+
+
+
+\begin{figure}[tb]
+\begin{center}
+\scalebox{0.5}{\includegraphics{fig/compare_encoding.eps}}
+\end{center}
+\caption{
+
+}
+\label{figure:splaying}
+\end{figure}
+
+