Binary file Paper/riono-sigos.pdf has changed

--- a/Paper/riono-sigos.tex	Thu May 07 19:45:00 2020 +0900
+++ b/Paper/riono-sigos.tex	Thu May 07 20:19:14 2020 +0900
@@ -267,15 +267,16 @@
 \lstinputlisting[caption=TileLoopの処理関数, label=code:tileloop]{src/decode.java}
 
 
-Code \ref{code:tileloop}8 - 11行目はTileLoopの初期化でBlockingと構築するPacketの準備を行っている。Code \ref{code:tileloop}12行目からのLoopではZRLEで受け取ったRectangleを1Tile 64x64に分割し、1Tileずつ処理を行う。%そして受け取ったZRLEより処理を行うTileのデータを取得し、フェーズの確認と圧縮段階に入る。
+Code \ref{code:tileloop}: 8 - 11行目はTileLoopの初期化でBlockingと構築するPacketの準備を行っている。Code \ref{code:tileloop}: 12行目からのLoopではZRLEで受け取ったRectangleを1Tile 64x64に分割し、1Tileずつ処理を行う。%そして受け取ったZRLEより処理を行うTileのデータを取得し、フェーズの確認と圧縮段階に入る。
+
+TileLoopにはc1Rectと呼ばれるRectangleを持っている。これは読み込んだTile分だけ縦横を拡張していくことによってRectangleの再構成を行なっている(Code \ref{code:tileloop}: 15行目)。
+
+Code \ref{code:tileloop}: 21行目では処理対象のTileのデータ圧縮とフェーズ確認を行う関数である。Code \ref{code:multicastput}はその関数の処理を大まかに抜粋したものである。
+
+\lstinputlisting[caption=TileLoopの処理関数, label=code:multicastput]{src/multicastPut.java}
 
 
-TileLoopにはc1Rectと呼ばれるRectangleを持っている。これは読み込んだTile分だけ縦横を拡張していくことによってRectangleの再構成を行なっている。図\ref{fig:TIleLoopFlow}中2の圧縮段階では、読み込んだTileのデータを圧縮用のStreamに格納し、java.util.zip.deflaterを利用して圧縮を行なっている。Packetのサイズは60KBとしているが、一旦の制限として42KBまでを格納可能としている。
-
-Code \ref{code:tileloop}21行目では処理対象のTileのデータ圧縮とフェーズ確認を行う関数である。Code \ref{code:multicastput}はその関数の処理を大まかに抜粋したものである。
-
-
-\lstinputlisting[caption=TileLoopの処理関数, label=code:multicastput]{src/multicastPut.java}
+Code \ref{code:multicastput}: 2 - 19行目では、読み込んだTileのデータを圧縮用のStreamに格納し、java.util.zip.deflaterを利用して圧縮を行う。
 
 java.util.zip.deflaterには下記の3種類の圧縮方法がある。
 
@@ -285,12 +286,18 @@
 \item FULL\_FLUSH : SYNC\_FLUSH同様、これまでにStreamに格納されたデータ圧縮を行う。異なる点はこれまでの辞書情報がリセットされるため、圧縮率が極端に低くなる可能性がある
 \end{itemize}
 
-ZRLEとjava.util.zip.deflaterを使用した圧縮では、圧縮後のデータ長を予測することができない。Packetが満杯になってしまうと、圧縮書き込みの途中であっても圧縮書き込みが中断する。そのため、Packetサイズを余分に確保する必要がある。したがって最初から最大の60KBではなく、42KBに制限を行なっている。TileLoopではデータの圧縮にNO\_FLUSHを利用していたが、圧縮後のデータがPacketの上限である60KBを超えてしまうことが多発した。
+Packetのサイズは60KBとしているが、一旦の制限として42KBまでを格納可能としている。これには理由があり、ZRLEとjava.util.zip.deflaterを使用した圧縮では、圧縮後のデータ長を予測することができない。
+Packetが満杯になってしまうと、圧縮書き込みの途中であっても圧縮書き込みが中断する。
+そのため、Packetサイズを余分に確保する必要がある。したがって最初から最大の60KBではなく、42KBに制限を行なっている。TileLoopではデータの圧縮にNO\_FLUSHを利用していたが、圧縮後のデータがPacketの上限である60KBを超えてしまうことが多発した。
 
 これは圧縮されるための入力データの規定量が想定以上に多く、圧縮後のデータ長がMulticast Packetの上限を超えてしまったためである。
 
 そこで圧縮率は悪くなるが、確実にPacketに書き込まれるSYNC\_FLUSHを利用し、ZRLEEの生成を行う。
 
+また圧縮は別スレッドで行われているため、圧縮が途中の段階で圧縮用Streamに新しい入力があった場合、先に格納されている入力は消えてしまう。そのために、Code \ref{code:multicastput}: 20行目でneedInput()がTrueになるまで待機する。
+
+
+
 図中3ではPacketの上限までいかなかった場合の分岐である。
 分岐の初めではRectangleの構成を行なっているc1Rectと、ZRLEから送られてきたRectangleなどと比較を行い、Phaseの確認をする。