Mercurial > hg > Papers > 2020 > riono-thesis
changeset 33:f93a34243a0b
update chapter3
| author | riono <e165729@ie.u-ryukyu.ac.jp> |
|---|---|
| date | Sun, 16 Feb 2020 06:46:26 +0900 |
| parents | 77951f2269aa |
| children | a5e11f973269 |
| files | FinalThesis/chapter3.tex FinalThesis/fig/Blocking.graffle FinalThesis/fig/Blocking.pdf FinalThesis/fig/TileLoopFlow.graffle FinalThesis/fig/TileLoopFlow.pdf FinalThesis/main.pdf FinalThesis/main.tex |
| diffstat | 7 files changed, 15 insertions(+), 18 deletions(-) [+] |
line wrap: on
line diff
--- a/FinalThesis/chapter3.tex Sun Feb 16 05:27:40 2020 +0900 +++ b/FinalThesis/chapter3.tex Sun Feb 16 06:46:26 2020 +0900 @@ -50,7 +50,6 @@ Tile内はパレットなどがある場合があるが、通常はRun Length encodeされたRGBデータである。 これまでのTreeVNCではVNCサーバから受け取ったRectangleを分割せずにZRLEEへ再構成を行なっていた。これをMluticastのためにデータを64KByteに収まる最大3つのRectangleに再構成する(図\ref{fig:BlockingUpdateRectangle})。この時にTile内部は変更する必要はないが、Rectangleの構成は変わる。ZLREを展開しつつ、Packetを構成する必要がある。 - \begin{figure}[htb] %PDF \begin{center} \includegraphics[scale=0.5]{fig/FrameUpdateRectangle.pdf} @@ -74,6 +73,7 @@ TileLoopはVNCサーバから受け取ったZRLEを図\ref{fig:BlockingUpdateRectangle}のようにRectangleを分割し、ZRLEEに再圧縮を行ったPacketを生成する。 以下の図\ref{fig:Packet}にTileLoopで生成されるPacket全体と、分割される各PhaseのRectangleを示した。 +\vspace{-8mm} \begin{figure}[htb] %PDF \begin{center} @@ -84,8 +84,10 @@ \end{figure} + Packet Headerには表\ref{tb:updateRectangle}に示したmessageID、padding、n of rectanglesが格納されている。また、分割されたRectangleにはそれぞれ表\ref{tb:rectangleheader}に示したRectangle Headerを持っている。 + \begin{table}[htp] \caption{Rectangle Headerの構成} \begin{center} @@ -103,19 +105,20 @@ \label{tb:rectangleheader} \end{table} -\newpage - 次にTileLoopの処理について説明する。以下の図\ref{fig:TileLoopFlow}はTileRoopのフローチャートである。 +\newgeometry{top=5mm} -\begin{figure}[hp] %PDF +\begin{figure}[htp] %PDF \begin{center} -\includegraphics[scale=0.5]{fig/TileLoopFlow.pdf} +\includegraphics[scale=0.8]{fig/TileLoopFlow.pdf} \figcaption{TileLoopのフローチャート} \label{fig:TileLoopFlow} \end{center} \end{figure} +\restoregeometry +\newpage 図\ref{fig:TileLoopFlow} 中1にて、TileLoopの初期化でBlockingと構築するPacketの準備を行う。Loop本体ではZRLEで受け取ったRecganleを1Tile 64x64に分割し、1Tileずつ処理を行う。そして受け取ったZRLEより処理を行うTileのデータを取得し、圧縮段階に入る。 @@ -140,24 +143,18 @@ 図\ref{fig:TileLoopFlow} 中3ではPacketの上限まで行かなかった場合の分岐である。 - - -Phaseが変わるとそれまでに構成されたc1RectをRectangle Headerに書き出している。 +分岐の初めではRectangleの構成を行っているc1Rectと、ZRLEから送られてきたRectangleなどと比較を行い、Phaseの確認をする。 - -\newpage - +Phaseの変更がなかった場合はLoopの先頭に戻るが、Phaseの変更があった場合、これまで構成していたRectangleとしてc1RectをそのPhaseのRectangle Headerに書き出す。c1Rectは次のPhaseに向けて初期化される。またこの時、図\ref{fig/Blocking.pdf}の各Rectangleの行末にあるように、FULL\_FLUSHを行う。FULL\_FLUSHを行う理由は、次の行に移る際、圧縮用のStreamにデータを残さないためである。 - +図\ref{fig:TileLoopFlow} 中4の処理は、Packetが一旦の上限42KByteまで達したことで分岐する。 -PacketにはMessage IDなどが入っているPacket Headerの他に、各RectangleのHeaderであるRectangle Headerが付いている。 +java.util.zip.deflaterを使用した圧縮では、Packetが一杯になってしまうと、圧縮書き出し中でも中断してしまう。そこでPacketの余剰分を解放し上限を60KByteにすることで、確実に書き込みを可能とする。図\ref{fig:Packet}中 Last Tileとは、Packetが一杯になった際に読み込まれているTileのことを指す。Last Tileは圧縮前で最大16KByteと考えられる。これを圧縮すると3 - 4 KByte程度であるので、その分のマージンを持っておくことで、読み込んだ最後のTileまできちんとPacketに書き込むことができる。 -また、Phaseが変わるごとにRectangle を構成し直す必要があるため、各Phaseの終了時には確実にflushをする必要がある。 +Packetに書き込み後はZRLEEでのMulticast Packetが完成したため、子Nodeへの送信のためにMulticastQueueへPacketが格納される。その後、次のPacket生成のためにPacketが初期化される。 -Packetの上限は60KByte取っているがZlibの性質上、パケットの容量を予測して圧縮書き出しすることができず、圧縮時にPacketから溢れてしまう場合がある。そのため、初期上限を42KByteとしてPacketが一杯にになった際に上限を60KByteまで大きくする。 - -圧縮前の1Tileの大きさは最大で16KByteと考えられる。これを圧縮すると3 - 4 KByte程度であるので、その分のマージンを持っておくことで、読み込んだ最後のTileまできちんとPacketに書き込むことができる。 +以上のルーチンをZRLEで受け取ったRectangle内のTile全てで行うことによって、VNCサーバから受け取ったZRLEの画像データをZRLEEとして生成を行うことができる。 \section{Packet Lost}