# HG changeset patch # User riono # Date 1581754517 -32400 # Node ID 3a6c2fd368b4051f1806f4c2b1d37fb68900b15a # Parent f9c3bb497e9c313ca9abb5405365c440fbf3d843 fix chapter2 diff -r f9c3bb497e9c -r 3a6c2fd368b4 FinalThesis/chapter2.tex --- 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}