# HG changeset patch # User riono # Date 1588855564 -32400 # Node ID 628722dc83bb2dd1e4caa4c810efb9f4883919a8 # Parent 8364e334853c445f4f71ef837ccabbe374263d0a update diff -r 8364e334853c -r 628722dc83bb Paper/riono-sigos.pdf Binary file Paper/riono-sigos.pdf has changed diff -r 8364e334853c -r 628722dc83bb Paper/riono-sigos.tex --- 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用のシステム構成} diff -r 8364e334853c -r 628722dc83bb Paper/src/decode.java --- 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); } -