Mercurial > hg > Papers > 2020 > riono-thesis
view FinalThesis/chapter3.tex @ 23:e18aecd16936
add new chapter4 and add coexistence img
author | riono <e165729@ie.u-ryukyu.ac.jp> |
---|---|
date | Fri, 14 Feb 2020 18:21:24 +0900 |
parents | fa92cb03dac1 |
children | f98010ed4fa9 |
line wrap: on
line source
\chapter{Multicastに向けたBlockingの実装} \label{chap:poordirection} \section{有線接続と無線LAN接続との違い} 現在のTreeVNCでは有線接続と無線LAN接続のどちらでも、VNCサーバから画面配信の提供を受けることが可能である。しかし画像配信のデータ量は膨大なため、現在のTreeVNCでVNCサーバに無線LAN接続を行なった場合、画面配信の遅延が大きくなってしまう。 無線LAN接続時の場合でも画面切り替えの機能は有効であるため、VNCサーバ側が無線LANで接続を行い、クライアント側は有線接続を行うことで画面配信が可能となる。ここで、WifiのMulticastの機能を用いてクライアント側でもWifiを使用することが可能であると考えられる。Root Nodeは無線LANに対して、変更するUpdate RectangleをMulticastで一度だけ送信する。 有線接続の場合は従来通り、VNCサーバ、Root Node、Nodeからなるバイナリツリー状に接続されるため、有線接続時と無線LAN接続時でのVNCサーバの接続方法を分割することが可能である(図\ref{fig:coexistence})。こうすることにより、新しいNodeが無線LAN接続であっても有線接続の木構造には影響を及ぼさない。 \begin{figure}[htb] %PDF \begin{center} \includegraphics[scale=0.35]{fig/coexistence.pdf} \figcaption{接続方法の分割} \label{fig:coexistence} \end{center} \end{figure} \newpage 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内部は変更する必要はないが、Rectangleの構成は変わる。ZLREを展開しつつ、Packetを構成する必要がある。 \begin{figure}[htb] %PDF \begin{center} \includegraphics[scale=0.5]{fig/FrameUpdateRectangle.pdf} \figcaption{Rectangleの分割} \label{fig:BlockingUpdateRectangle} \end{center} \end{figure} Zlibは丁度良い所で圧縮をflushする必要がある。このためには、ZlibのAPIを用いて、適当なタイミングでflushを呼ぶ。この時に1tileずつflushしてしまうと圧縮率を下げる可能性がある。 64KByteのPacketの中には複数のtileが存在するが、連続してRectangleを構成する必要がある。3つの Rectangleの構成を下記に示す。 \begin{itemize} \item 行の途中から始まり、行の最後までを構成するRectangle(図\ref{fig:BlockingUpdateRectangle}中 Phase0) \item 行の初めから最後までを構成するRectangle(図\ref{fig:BlockingUpdateRectangle}中 Phase1) \item 行の初めから、行の途中までを構成するRectangle(図\ref{fig:BlockingUpdateRectangle}中 Phase2) \end{itemize} \section{TileLoop} \section{Packet Lost} WiftのMulticast Packetは確実に送られることが保証されていない。データに通し番号をつけて、欠落を検出することはできるが、再送処理は複雑であることが予想される。そこで、一定時間ごとに全画面のデータを送信することによってPacket Lostしても画面共有に影響はないと考える。