view FinalThesis/chapter3.tex @ 21:fa92cb03dac1

update chapter3 and add Blocking UpdateRectangle image
author riono <e165729@ie.u-ryukyu.ac.jp>
date Thu, 13 Feb 2020 21:01:10 +0900
parents c1f1f84bb7b6
children e18aecd16936
line wrap: on
line source

\chapter{MalticastのためのBlockingの実装}
\label{chap:poordirection}

\section{有線接続と無線LAN接続との違い}
画像配信のデータ量は膨大なため、現在のTreeVNCでVNCサーバに無線LAN接続を行なった場合、画面配信の遅延が大きくなってしまう。

この場合でも画面切り替えの機能は有効であるため、VNCサーバ(配信)側が無線LANで接続を行い、クライアント側は有線接続を行うことで画面配信が可能となる。ここで、WifiのMulticastの機能を用いてクライアント側でもWifiを使用することが可能であると考えられる。Root Nodeは無線LANに対して、変更するUpdate RectangleをMulticastで一度だけ送信する。

WifiのMulticast Packetのサイズは64KByteが最大となっている。4Kディスプレイを例にとると、4Kディスプレイの大きさの画面更新には8MByte(画素数) \* 8Byte(色情報)で圧縮前で、64MByte程度となる。


\section{Update Rectangleの構成}
RFBのUpdate Rectangleは以下の表\ref{tb:updateRectangle}の構成となっている。

\begin{table}[htp]
    \caption{UpdateRectangleの構成}
    \begin{center}
    \begin{tabular}{|rrr|l|} \hline
        1 byte & & & messageID    \\
        1 byte & & & padding   \\
        2 byte & & & n of rectangles   \\ \hline
        & 2 byte & & U16 - x-position  \\
        & 2 byte & &  U16 - y-position  \\
        & 2 byte & &  U16 - width  \\
        & 2 byte & &  U16 - height  \\
        & 4 byte & &  S32 - encoding-type  \\
        & 4 byte & &  U32 datalengths   \\ \hline
        &  & 1 byte & subencoding of tile     \\
        &  & n byte & Run Length Encoded Tile \\ \hline
    \end{tabular}
    \end{center}
    \label{tb:updateRectangle}
\end{table}

1つのUpdate Rectangleには複数のRectangleが入っており、さらに1つ1つのRectangleにはx,y座標や縦横幅、encoding type が含まれているRectangle Headerを持っている。ここではZRLEで圧縮されたRectangleが1つ、VNCサーバから送られてくる。RectangleにはZlib圧縮されたデータが、datelengthsと呼ばれる指定された長さだけ付いてくる。このデータは、さらに64x64のtileに分割されている\ref{fig:BlockingUpdateRectangle}中 Tile)。

\newpage

tile内はパレットなどがある場合があるが、通常はRun Length encodeされたRGBデータである。
これまでのTreeVNCではVNCサーバから受け取ったRectangleを分割せずにZRLEEへ再構成を行なっていた。これをMluticastのためにデータを64KByteに収まる最大3つのRectangleに再構成する(図\ref{fig:BlockingUpdateRectangle})。この時に、tile内部は


\begin{figure}[htb] %PDF
\begin{center}
\includegraphics[scale=0.5]{fig/FrameUpdateRectangle.pdf}
\figcaption{Rectangleの分割}
\label{fig:BlockingUpdateRectangle}
\end{center}
\end{figure}


Zlibは丁度良い所で圧縮をflushする必要がある。
このためには




\section{TileLoop}

\section{Packet Lost}
WiftのMulticast Packetは確実に送られることが保証されていない。データに通し番号をつけて、欠落を検出することはできるが、再送処理は複雑であることが予想される。そこで、一定時間ごとに全画面のデータを送信することによってPacket Lostしても画面共有に影響はないと考える。

\section{木構造とマルチキャストの共存}