Mercurial > hg > Papers > 2019 > riono-sigos

Binary file Paper/riono-sigos.pdf has changed
--- a/Paper/riono-sigos.tex	Thu May 09 16:38:44 2019 +0900
+++ b/Paper/riono-sigos.tex	Thu May 09 17:09:02 2019 +0900
@@ -55,7 +55,9 @@
 \maketitle

 \section{画面配信ソフトウェア TreeVNCの活用}
-現代の講義や発表, プレゼンなどではPC画面で用意した資料を見ながら進行することが多い. ゼミでは発表者のPC画面を切り替えを行いながら発表を行う場合もある. 通常このような場面では資料やスライドを表示するためにプロジェクタが利用される. その際, 発表者のPC画面を切り替えるたびにケーブルを差し替える必要がある. 発表者のPCによっては接続するアダプターの種類や解像度の設定により, 正常にPC画面を表示できない場合がある. また, 参加者もプロジェクタに集中を割く必要があり, 手元のPCと相互に参照する場合, 負担になる場合がある.
+現代の講義や発表, プレゼンなどではPC画面で用意した資料を見ながら進行することが多い. ゼミでは発表者のPC画面を切り替えを行いながら発表を行う場合もある.
+
+通常このような場面では資料やスライドを表示するためにプロジェクタが利用される. その際, 発表者のPC画面を切り替えるたびにケーブルを差し替える必要がある. 発表者のPCによっては接続するアダプターの種類や解像度の設定により, 正常にPC画面を表示できない場合がある. また, 参加者もプロジェクタに集中を割く必要があり, 手元のPCと相互に参照する場合, 負担になる場合がある.

 当研究室で開発している画面配信システムTreeVNC\cite{taninari:2011a}は, 発表者の画面を参加者のPCに表示するソフトウェアである. そのため, 参加者は不自由なく手元のPCを操作しながら講義を受けることが可能になる. 更に発表者の切り替えの際もケーブルを差し替えずに, 共有する画面の切り替えが可能になっている.

@@ -74,13 +76,17 @@
 \end{center}
 \end{figure}

-RFB（Remote Frame Buffer）プロトコル\cite{rfbprotocol}とは, 自身のPC画面をネットワーク上に送信し他人の画面に表示を行うプロトコルである. 画面が表示されるユーザ側をRFBクライアントと呼び, 画面を送信のためにFramebufferの更新が行われる側をRFBサーバと呼ぶ. Framebufferとは, メモリ上に置かれた画像データのことである. RFBプロトコルでは, 最初にプロトコルのバージョン確認や認証が行われる. その後, クライアントへ向けてFramebufferの大きさやデスクトップに付けられた名前などが含まれている初期メッセージを送信する.
+RFB（Remote Frame Buffer）プロトコル\cite{rfbprotocol}とは, 自身のPC画面をネットワーク上に送信し他人の画面に表示を行うプロトコルである. 画面が表示されるユーザ側をRFBクライアントと呼び, 画面を送信のためにFramebufferの更新が行われる側をRFBサーバと呼ぶ.
+
+Framebufferとは, メモリ上に置かれた画像データのことである. RFBプロトコルでは, 最初にプロトコルのバージョン確認や認証が行われる. その後, クライアントへ向けてFramebufferの大きさやデスクトップに付けられた名前などが含まれている初期メッセージを送信する.

 RFBサーバ側はFramebufferの更新が行われるたびに, RFBクライアントに対してFramebufferの変更部分のみを送信する. 更に, RFBクライアントのFramebufferUpdateRequestが来るとそれに答え返信する. 変更部分のみを送信する理由は, 更新がある度に全画面を送信すると, 送信するデータ面と更新にかかる時間面において効率が悪くなるからである.

 TreeVNCはサーバに接続してきたクライアントをバイナリツリー状に接続する. 接続してきたクライアントをノードとし, その下に新たなノード二つを接続していく.
 これにより, 人数分のコピーと送信の手間を分散することができる. （図\ref{fig:TreeStructure}）.
+
 バイナリツリー状に接続することで, N台のクライアントが接続しにきた場合, 従来のVNCではサーバ側がN回のコピーを行なって配信をする必要があるが, TreeVNCでは各ノードが2回ずつコピーをするだけで配信が可能となる.
+
 送信されるデータは従来の方法ではNノードに対してN-1の通信が必要であるが, 木構造を用いても通信の数は変わらない.

 バイナリツリーのルートのノードをRoot Nodeと呼び, そこに接続されるノードをNodeと呼ぶ. Root Nodeは子Nodeにデータを渡す機能, 各Nodeの管理, VNCサーバから送られてきたデータの管理を行なっている. 各Nodeは, 親Nodeから送られてきたデータを自身の子Nodeに渡す機能, 子Nodeから送られてきたデータを親Nodeに渡す機能がある.
@@ -96,6 +102,8 @@
 \section{TreeVNCの通信プロトコル}

 TreeVNCの通信経路として以下の6つが挙げられる.
+
+
 \begin{itemize} %箇条書き
 \item Root Nodeから任意のNodeに直接通信を行う send direct message （Root to Node）
 \item 任意のNodeからRoot Nodeに直接通信を行う send direct message （Node to Root）
@@ -151,15 +159,10 @@
 \subsection{木構造の再構成}
 TreeVNCはバイナリツリーでの接続のため, Nodeが切断されたことを検知できないと構成した木構造が崩れてしまい, 新しいNodeを適切な場所に接続できなくなってしまう. そこで木構造を崩さないよう, Node同士の接続の再構成を行う必要がある.

-TreeVNCの木構造のネットワークトポロジーはRoot Nodeが持っているnodeListで管理している. Nodeの接続が切れた場合, Root Nodeに切断を知らせなければならない. TreeVNCはLOST\_CHILDというメッセージ通信で, Nodeの切断を検知および木構造の再構成を行なっている. LOST\_CHILDの検出方法にはMulticastQueueを使用しており, ある一定時間MulticastQueueから画像データが取得されない場合, MemoryOverFlowを回避するためにTimeoutスレッドが用意されている. そして, Timeoutを検知した際にNodeとの接続が切れたと判断する.
+TreeVNCの木構造のネットワークトポロジーはRoot Nodeが持っているnodeListで管理している. Nodeの接続が切れた場合, Root Nodeに切断を知らせなければならない.

-\begin{figure}[htb]　%PDF
-\begin{center}
-\includegraphics[width=8cm]{Image/EncodeZRLEE.pdf}
-\caption{Multi Network Tree}
-\label{fig:ZRLEE}
-\end{center}
-\end{figure}
+TreeVNCはLOST\_CHILDというメッセージ通信で, Nodeの切断を検知および木構造の再構成を行なっている. LOST\_CHILDの検出方法にはMulticastQueueを使用しており, ある一定時間MulticastQueueから画像データが取得されない場合, MemoryOverFlowを回避するためにTimeoutスレッドが用意されている. そして, Timeoutを検知した際にNodeとの接続が切れたと判断する.
+

 \subsection{ZRLEE}
 TreeVNCでは, ZRLEE\cite{taninari:2012a}というエンコード方法でデータの圧縮を行う. ZRLEEはRFBプロトコルで使用できるZRLEというエンコードタイプを元に生成される.
@@ -169,6 +172,13 @@
 そこでZRLEEは一度Root Nodeで受け取ったZRLEのデータをunzipし, データをupdate rectangleと呼ばれる画面ごとのデータに辞書を付与してzipし直すことで初めからデータを読み込んでいなくても解凍できるようにした（図\ref{fig:ZRLEE}）.
 辞書をクリアすることによりadaptive compressionを実現していることになり圧縮率はむしろ向上する.

+\begin{figure}[htb]　%PDF
+\begin{center}
+\includegraphics[width=8cm]{Image/EncodeZRLEE.pdf}
+\caption{ZRLEE}
+\label{fig:ZRLEE}
+\end{center}
+\end{figure}


 \subsection{ShareScreen}
@@ -187,13 +197,16 @@
 \end{figure}

 \subsection{ネットワーク複数時の接続}
-TreeVNCはRoot Nodeが複数のネットワークに接続している場合, 図\ref{fig:multinetworktree}のようにネットワーク別に木構造を形成する. TreeVNCはRoot NodeがTreeManagerというオブジェクトを持っている. TreeManagerはTreeVNCの接続部分を管理しており, 木構造を管理するnodeListを生成する. このnodeListを元に, 新しいNodeの接続や, 切断検出時の接続の切り替え等を行う. Tree ManagerはRoot Nodeの保持しているネットワーク毎に生成される. 新しいNodeが接続してきた際, interfacesからNodeのネットワークと一致するTree Managerを取得し, Node接続の処理を任せる.
+TreeVNCはRoot Nodeが複数のネットワークに接続している場合, 図\ref{fig:multinetworktree}のようにネットワーク別に木構造を形成する. TreeVNCはRoot NodeがTreeManagerというオブジェクトを持っている. TreeManagerはTreeVNCの接続部分を管理しており, 木構造を管理するnodeListを生成する. このnodeListを元に, 新しいNodeの接続や, 切断検出時の接続の切り替え等を行う.
+
+Tree ManagerはRoot Nodeの保持しているネットワーク毎に生成される. 新しいNodeが接続してきた際, interfacesからNodeのネットワークと一致するTree Managerを取得し, Node接続の処理を任せる.


 %\section{マルチキャストの導入}
 \section{有線接続との接続形式の違い}
 画面配信のデータ量は膨大なため, 現在のTreeVNCでVNCServerに無線LAN接続を行なった場合, 画面配信の遅延が大きくなってしまう.
+
 この場合でも画面切り替えの機能は有効である. つまり, 画面を提供するPCのみを無線経由で接続し, 配信を希望する側は有線を使用することができる. ここで, Wifi のMulticast の機能を用いて配信側にもWifiを使用することが可能であると考えられる. Tree Root は無線LANに対して, 変更する UpdateRectangle を Multicast で一度だけ送信する.

 Wifi のMulticast packet のサイズは 64kbyte が最大となっている. HDや4Kの大きさの画面更新は8Mb * 8byteで圧縮前で64MB程度になる.
@@ -203,12 +216,10 @@

 ここではまずBlocking について考察と実験を行う.

-
-
 \section{RFBのUpdateRectangle の構成}

-RFB のUpdateRectangle は以下の表\ref{tb:updateRectangle}の構成になっている. 一つのupdateRectangleには複数のRectangleは入っていて, さらに一つ一つのRectangleの encoding type がある. ここでは ZRLEで encode された rectangle  が一つサーバから送られてくる.
-rectangle には zlib で圧縮されたデータが指定された長さだけ付いてくる. このデータは, 64x64 の tile にさらに分割されている（図\ref{fig:rectangle}）.
+RFB のUpdateRectangle は以下の表\ref{tb:updateRectangle}の構成になっている. 一つのupdateRectangleには複数のRectangleは入っていて, さらに一つ一つのRectangleの encoding type がある. ここでは ZRLEで encode された Rectangle  が一つサーバから送られてくる.
+Rectangle には zlib で圧縮されたデータが指定された長さだけ付いてくる. このデータは, 64x64 の tile にさらに分割されている（図\ref{fig:rectangle}）.
 tile 内はパレットとかがある場合があるが, Run length encode されたRGBデータである.

 \begin{figure}[htb]　%PDF
@@ -219,7 +230,6 @@
 \end{center}
 \end{figure}

-
 このパケットを64kbyteに収まる三つのRectangleに再構成する. この時に, tile 内部は変更する必要はないが, Rectangleの構成は変わる.
 ZRLE を展開しつつ, パケットを構成する必要がある.

@@ -228,8 +238,6 @@

 64kbyte のpacketの中には複数の tile が存在するが, 連続して Rectangle を構成する必要がある. 行の途中から始まり, 途中で終わる可能性があるので, 三つのRectangleが必要になる.

-
-
 \begin{table}[hp]
     \caption{updateRectangleの構成}
     \begin{tabular}{|rrr|l|} \hline