Mercurial > hg > Papers > 2020 > riono-sigos

Binary file Paper/riono-sigos.pdf has changed
--- a/Paper/riono-sigos.tex	Thu May 07 20:19:14 2020 +0900
+++ b/Paper/riono-sigos.tex	Thu May 07 21:46:04 2020 +0900
@@ -286,30 +286,25 @@
 \item FULL\_FLUSH : SYNC\_FLUSH同様、これまでにStreamに格納されたデータ圧縮を行う。異なる点はこれまでの辞書情報がリセットされるため、圧縮率が極端に低くなる可能性がある
 \end{itemize}

-Packetのサイズは60KBとしているが、一旦の制限として42KBまでを格納可能としている。これには理由があり、ZRLEとjava.util.zip.deflaterを使用した圧縮では、圧縮後のデータ長を予測することができない。
+Packetのサイズは62KBとしているが、一旦の制限として37KBまでを格納可能としている。これには理由があり、ZRLEとjava.util.zip.deflaterを使用した圧縮では、圧縮後のデータ長を予測することができない。
 Packetが満杯になってしまうと、圧縮書き込みの途中であっても圧縮書き込みが中断する。
-そのため、Packetサイズを余分に確保する必要がある。したがって最初から最大の60KBではなく、42KBに制限を行なっている。TileLoopではデータの圧縮にNO\_FLUSHを利用していたが、圧縮後のデータがPacketの上限である60KBを超えてしまうことが多発した。
+そのため、Packetサイズを余分に確保する必要がある。したがって最初から最大の62KBではなく、37KBに制限を行なっている。TileLoopではデータの圧縮にNO\_FLUSHを利用していたが、圧縮後のデータがPacketの上限である62KBを超えてしまうことが多発した。

-これは圧縮されるための入力データの規定量が想定以上に多く、圧縮後のデータ長がMulticast Packetの上限を超えてしまったためである。
-
-そこで圧縮率は悪くなるが、確実にPacketに書き込まれるSYNC\_FLUSHを利用し、ZRLEEの生成を行う。
+これは圧縮されるための入力データの規定量が想定以上に多く、圧縮後のデータ長がMulticast Packetの上限を超えてしまったためである。そこで圧縮率は悪くなるが、確実にPacketに書き込まれるSYNC\_FLUSHを利用し、ZRLEEの生成を行う。

 また圧縮は別スレッドで行われているため、圧縮が途中の段階で圧縮用Streamに新しい入力があった場合、先に格納されている入力は消えてしまう。そのために、Code \ref{code:multicastput}: 20行目でneedInput()がTrueになるまで待機する。

+Code \ref{code:multicastput}: 21行目以降の処理はTileのフェーズ確認である。
+
+Code \ref{code:multicastput}: 22 - 27行目は行の最後のTileだった場合の条件分岐である。図\ref{fig:Packet}中のflushに該当するTileであり、そこで圧縮されたデータとループ内で再構成を行っているc1Rectの情報をPacketへ書き込みを行う。ここでFULL\_FLUSHを行う理由は、次の行に移る際圧縮用のStreamにデータを残さないためである。また、この箇所でPhase2かどうかの判断も行っている。


-図中3ではPacketの上限までいかなかった場合の分岐である。
-分岐の初めではRectangleの構成を行なっているc1Rectと、ZRLEから送られてきたRectangleなどと比較を行い、Phaseの確認をする。
+Code \ref{code:multicastput}: 33、47行目ではPhase0、Phase1の確認と処理を行っている。どちらの処理も圧縮されたデータとc1Rectの情報をPacketに書き込み、次のPhaseのための初期化などを行っている。Packetへ書き込みが完了すると、子Nodeへの送信のためにPacketがMulticastQueueへ格納される。

-Phaseの変更がなかった場合はLoopの先頭に戻るが、Phaseの変更があった場合、これまで構成していたRectangleとしてc1RectをそのPhaseのRectangle Headerに書き出す。c1Rectは次のPhaseに向けて初期化される。またこの時、図\ref{fig:Packet}の各Rectangleの行末にあるように、FULL\_HLUSHを行う理由は、次の行に移る際圧縮用のStreamにデータを残さないためである。

-図中4の処理は、Packetが一旦の上限42KBまで達したことで分岐する。
-
-java.util.zip.deflaterを使用した圧縮では、Packetが一杯になってしまうと、圧縮書き出し中でも中断してしまう。そこでPacketの余剰分を解放し上限を60KBにすることで、確実に書き込みを可能とする。図\ref{fig:Packet}中Last Tileとは、Packetが一杯になった際に読み込まれているTileのことを指す。Last Tileは圧縮前で最大16KBと考えられる。これを圧縮すると3 - 4KB程度であるので、その分のマージンを持っていくことで、読み込んだ最後のTileまできちんとPacketに書き込むことができる。
+%java.util.zip.deflaterを使用した圧縮では、Packetが一杯になってしまうと、圧縮書き出し中でも中断してしまう。そこでPacketの余剰分を解放し上限を60KBにすることで、確実に書き込みを可能とする。図\ref{fig:Packet}中Last Tileとは、Packetが一杯になった際に読み込まれているTileのことを指す。Last Tileは圧縮前で最大16KBと考えられる。これを圧縮すると3 - 4KB程度であるので、その分のマージンを持っていくことで、読み込んだ最後のTileまできちんとPacketに書き込むことができる。

-Packetに書き込み後はZRLEEでのMulticast Packetが完成したため、子Nodeへの送信のためにMulticastQueueへPacketが格納される。
-
-以上のルーチンをZRLEで受け取ったRectangle内のTile全てで行うことによって、VNCサーバから受け取ったZRLEの画像データをZRLEEとして生成を行うことができる。
+以上のルーチンでVNCサーバから受け取ったZRLEをZLREEへと変換、Rectangleの再構成を行っている。


 \section{Multicast用のシステム構成}
--- a/Paper/src/decode.java	Thu May 07 20:19:14 2020 +0900
+++ b/Paper/src/decode.java	Thu May 07 21:46:04 2020 +0900
@@ -22,7 +22,4 @@
       }
     }
   }
-  if (WifiMulticast)
-    tileloop.multicastPut(rfbProto, true, bytes, offset, 0, 0, 0, 0);
 }
-