# HG changeset patch # User riono # Date 1581595270 -32400 # Node ID fa92cb03dac1622401573b81aa698f811b45048c # Parent 69ef71aaaca6653384cfc342506481cfc6ec065e update chapter3 and add Blocking UpdateRectangle image diff -r 69ef71aaaca6 -r fa92cb03dac1 FinalThesis/chapter2.tex --- a/FinalThesis/chapter2.tex Thu Feb 13 16:31:23 2020 +0900 +++ b/FinalThesis/chapter2.tex Thu Feb 13 21:01:10 2020 +0900 @@ -132,21 +132,19 @@ \begin{figure}[htb]　%PDF \begin{center} -\includegraphics[scale=0.7]{fig/EncodeZRLE.pdf} +\includegraphics[scale=0.6]{fig/EncodeZRLE.pdf} \figcaption{ZRLEでデータを途中から受け取った場合} \label{fig:ZRLE} \end{center} \end{figure} -\newpage - -そこでZRLEEは一度Root Nodeで受け取ったZRLEのデータをunzipし、後述するupdate Rectangleと呼ばれる画面ごとのデータに辞書を付与してzipし直すことで、初めからデータを読み込んでいなくても解凍を出来るようになっている(図\ref{fig:ZRLEtoZRLEE})。 +そこでZRLEEは一度Root Nodeで受け取ったZRLEのデータをunzipし、後述するUpdate Rectangleと呼ばれる画面ごとのデータに辞書を付与してzipし直すことで、初めからデータを読み込んでいなくても解凍を出来るようになっている(図\ref{fig:ZRLEtoZRLEE})。 一度ZRLEEに変換してしまえば、子Nodeはそのデータをそのまま流すだけでよい。ただし、deflaterとinflaterでは前回までの通信で得た辞書をクリアしないとけないため、Root Node側とNode側では毎回新しく作る必要がある。辞書をクリアすることにより adaptive compressionを実現していることになり圧縮率が向上する。 \begin{figure}[htb]　%PDF \begin{center} -\includegraphics[scale=0.8]{fig/EncodeZRLEtoZRLEE.pdf} +\includegraphics[scale=0.7]{fig/EncodeZRLEtoZRLEE.pdf} \figcaption{ZRLEEへ再圧縮されたデータを途中から受け取った場合} \label{fig:ZRLEtoZRLEE} \end{center} @@ -154,28 +152,9 @@ \newpage -TreeVNCではRFBプロトコルによって配信側の画面の変更部分はFRAME\_BUFFER\_UPDATEメッセージとして送られてくる。メッセージの中には変更部分の原点のx,y座標と縦横の幅が含まれており、長方形として展開される。この長方形をupdate Rectangleと呼ぶ。以下の表\ref{tb:updateRectangle}にupdate Rectangleの構成を示す。 - +TreeVNCではRFBプロトコルによって配信側の画面の変更部分はFRAME\_BUFFER\_UPDATEメッセージとして送られてくる。メッセージの中には変更部分の原点のx,y座標と縦横の幅等が含まれており、長方形として展開される。この長方形をUpdate Rectangleと呼ぶ。 -\begin{table}[hp] - \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} +\newpage \section{ShareScreen} ゼミでは発表者が順々に入れ替わる。発表者が入れ替わるたびに共有する画面の切り替えが必要となる。ゼミを円滑に進めるために、画面の切り替えをスムーズに行いたい。 diff -r 69ef71aaaca6 -r fa92cb03dac1 FinalThesis/chapter3.tex --- a/FinalThesis/chapter3.tex Thu Feb 13 16:31:23 2020 +0900 +++ b/FinalThesis/chapter3.tex Thu Feb 13 21:01:10 2020 +0900 @@ -1,13 +1,63 @@ -\chapter{実験} +\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{実験説明} +\section{Update Rectangleの構成} +RFBのUpdate Rectangleは以下の表\ref{tb:updateRectangle}の構成となっている。 -\section{} +\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} -\section{検証結果} +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{考察} + +\section{TileLoop} + +\section{Packet Lost} +WiftのMulticast Packetは確実に送られることが保証されていない。データに通し番号をつけて、欠落を検出することはできるが、再送処理は複雑であることが予想される。そこで、一定時間ごとに全画面のデータを送信することによってPacket Lostしても画面共有に影響はないと考える。 + +\section{木構造とマルチキャストの共存} diff -r 69ef71aaaca6 -r fa92cb03dac1 FinalThesis/fig/FrameUpdateRectangle.graffle Binary file FinalThesis/fig/FrameUpdateRectangle.graffle has changed diff -r 69ef71aaaca6 -r fa92cb03dac1 FinalThesis/fig/FrameUpdateRectangle.pdf Binary file FinalThesis/fig/FrameUpdateRectangle.pdf has changed diff -r 69ef71aaaca6 -r fa92cb03dac1 FinalThesis/main.pdf Binary file FinalThesis/main.pdf has changed diff -r 69ef71aaaca6 -r fa92cb03dac1 FinalThesis/main.tex --- a/FinalThesis/main.tex Thu Feb 13 16:31:23 2020 +0900 +++ b/FinalThesis/main.tex Thu Feb 13 21:01:10 2020 +0900 @@ -6,6 +6,7 @@ \usepackage{here} \usepackage{cite} \usepackage{url} +\usepackage{scalefnt} diff -r 69ef71aaaca6 -r fa92cb03dac1 riono-thesis.mm --- a/riono-thesis.mm Thu Feb 13 16:31:23 2020 +0900 +++ b/riono-thesis.mm Thu Feb 13 21:01:10 2020 +0900 @@ -22,16 +22,39 @@ - + + + + - - + + + + + + + + + + + + + + + + + + + + - + + + @@ -89,12 +112,9 @@ - - - - - - + + + @@ -102,7 +122,16 @@ - + + + + + + + + + + @@ -115,6 +144,11 @@ + + + + +