changeset 27:3a6c2fd368b4

fix chapter2
author riono <e165729@ie.u-ryukyu.ac.jp>
date Sat, 15 Feb 2020 17:15:17 +0900
parents f9c3bb497e9c
children 74d52d516312
files FinalThesis/chapter2.tex
diffstat 1 files changed, 2 insertions(+), 2 deletions(-) [+]
line wrap: on
line diff
--- a/FinalThesis/chapter2.tex	Sat Feb 15 04:51:01 2020 +0900
+++ b/FinalThesis/chapter2.tex	Sat Feb 15 17:15:17 2020 +0900
@@ -93,7 +93,7 @@
 \newpage
 
 \section{MulticastQueue}
-配信側の画面が更新されると、VNCサーバから画面データがFRAME\_BUFFER\_UPDATEメッセージとして送らる。その際、画像データの更新を同時に複数のNodeに伝えるためにMulticastQueueというキューにデータを蓄積している。
+配信側の画面が更新されると、VNCサーバから画面データがFRAME\_BUFFER\_UPDATEメッセージとして送られる。その際親Nodeが受け取った画像データを、同時に複数の子Nodeに伝えるためにMulticastQueueというキューにデータを蓄積を行う。
 
 各NodeはMulticastQueueからデータを取得するスレッドを持つ。MulticastQueueは複数のスレッドから使用される。
 MulticastQueueはjava.util.concurrent.CountDownLatchを用いて実装されている。CountDownLatchとはjavaの並列実行用に用意されたAPIで、他のスレッドで実行中の操作が完了するまで、複数のスレッドを待機させることができるクラスである。スレッドを解放するカウントを設定することができ、カウントが0になるまでawaitメソッドでスレッドをブロックすることができる。
@@ -148,7 +148,7 @@
 
 そこでZRLEEは一度Root Nodeで受け取ったZRLEのデータをunzipし、後述するUpdate Rectangleと呼ばれる画面ごとのデータに辞書を付与してzipし直すことで、初めからデータを読み込んでいなくても解凍を出来るようになっている(図\ref{fig:ZRLEtoZRLEE})。
 
-一度ZRLEEに変換してしまえば、子Nodeはそのデータをそのまま流すだけでよい。ただし、deflaterとinflaterでは前回までの通信で得た辞書をクリアしないとけないため、Root Node側とNode側では毎回新しく作る必要がある。辞書をクリアすることにより adaptive compressionを実現していることになり圧縮率が向上する。
+一度ZRLEEに変換してしまえば、子Nodeはそのデータをそのまま流すだけでよい。ただし、deflaterとinflaterでは前回までの通信で得た辞書をクリアしないとけないため、Root Node側とNode側では毎回新しく作る必要がある。辞書をクリアすることで短時間で解凍され画面描画されるという、適応圧縮を実現していることになり圧縮率が向上する。
 
 \begin{figure}[htb] %PDF
 \begin{center}