# HG changeset patch # User riono # Date 1588850354 -32400 # Node ID 8364e334853c445f4f71ef837ccabbe374263d0a # Parent c9d0d3e1a82f0024a9f7013b301b17585680f063 update diff -r c9d0d3e1a82f -r 8364e334853c Paper/riono-sigos.pdf Binary file Paper/riono-sigos.pdf has changed diff -r c9d0d3e1a82f -r 8364e334853c Paper/riono-sigos.tex --- 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の確認をする。