# HG changeset patch # User Shinji KONO # Date 1588817706 -32400 # Node ID e1196cd575bf65c4bde3540181864d338e14c6df # Parent cd6b71029f96db4601d70c0263d182878ea99645 fix diff -r cd6b71029f96 -r e1196cd575bf Paper/riono-sigos.tex --- a/Paper/riono-sigos.tex Thu May 07 04:37:57 2020 +0900 +++ b/Paper/riono-sigos.tex Thu May 07 11:15:06 2020 +0900 @@ -53,16 +53,18 @@ %% その場合、発表者のPCを接続するたびにケーブルを差し替える必要がある。発表者のPCによっては接続するアダプターの種類や解像度の設定により、正常にPC画面を表示できない場合がある。また、参加者もプロジェクタに集中を割く必要があり、同時に手元のPCで作業を行う場合集中の妨げとなってしまう。 -最近の社会情勢により、世間ではリモートワークが増えている。リモートワークではビデオ通話を行いながら自宅で仕事をすることになるが、PCの画面共有を利用して情報を共有することも多い。 +最近のコロナ禍などの社会情勢によりリモートワークの重要性が高まっている。リモートワークではビデオ通話を行いながら自宅で仕事をすることになるが、PCの画面共有を利用して情報を共有することも多い。 -ビデオ通話ソフトウェアの1つにZoomがある。Zoomはカメラを利用したビデオ通話に重点を置いて開発されているため、送信される画像に対してある程度のロスを許容して圧縮が行われている。そのためPC画面を共有した際に書類の文字がはっきり見えないということが発生する。またビデオ通話には、各地に存在するサーバを経由して通信を行っている。 +ビデオ通話ソフトウェアの1つにZoomがある。Zoomはカメラを利用したビデオ通話に重点を置いて開発されているため、送信される画像に対してある程度のロスを許容して圧縮が行われている。そのためPC画面を共有した際に書類の文字がはっきり見えないということが発生する。またビデオ通話には、Zoomが管理するデータセンターにあるサーバを経由して通信を行っている。 -当研究室で開発している画面配信システムTreeVNC\cite{taninari:2011a}は、発表者の画面を参加者のPC画面に表示するソフトウェアである。画面共有に特化しており、共有するPC画面をロスなく圧縮しデータを送信することが可能である。またPC同士で通信を行うため外部のサーバに接続する必要がなく、一般的なサーバ通信よりも高速に通信が可能である。 - +当研究室で開発している画面配信システムTreeVNC\cite{taninari:2011a}は、発表者の画面を参加者のPC画面に表示するソフトウェアである。画面共有に特化しており、共有するPC画面をロスなく圧縮しデータを送信することが可能である。 +TreeVNC は木構造型のオーバーレイネットワークを動的にLANまたはWAN上に構成し、画面共有に参加しているPC同士でのP2P型の通信を行う。これにより、データセンター上の強力なサーバやネットワークを要求せずに配信を可能にしている。 %そのため、参加者は不自由なく手元のPCを操作しながら講義を受けることが可能になる。さらに、発表者の交代もケーブルの差し替えを行わずに、全体に共有する画面の切り替えが可能となっている。 -しかし、画面共有は送信するデータ量が多いため、現在のTreeVNCで無線LAN接続を行なった際に有線接続よりも遅延が大きくなってしまう。そこで本研究では、Multicast通信の実装を行い無線LAN接続でもTreeVNCを利用可能にし、TreeVNCの有用性を評価することで講義やゼミを円滑に行えることを目標とする。 +しかし、オーバーレイネットワークは無線LAN接続では共有された通信帯域を消費してしまう。有線の場合はネットワークスイッチの容量が十分に大きければ問題にならないが、 +LAN/WAN/WifiでMulticast通信がサポートされていれば、それを使うことが望ましい。 +本研究では、TreeVNC のMulticast通信の実装を行い実際の動作確認を行う。 \section{TreeVNCの基本概念} Virtual Network Computing\cite{vnc}(以下VNC)は、サーバ側とクライアント(ビューワー)側からなるリモートデスクトップソフトウェアである。遠隔操作にはサーバを起動し、クライアント側がサーバに接続することで可能としている。また、動作にはRFBプロトコルを用いている。 @@ -131,19 +133,22 @@ 一度ZRLEEに変換してしまえば、子Nodeはそのデータをそのまま流すだけでよい。ただし、deflaterとinflaterでは前回までの通信で得た辞書をクリアしないといけないため、Root Node側とNode側では毎回新しく作る必要がある。辞書をクリアすることで短時間で解凍され画面描画されるという、適応圧縮を実現していることになり圧縮率は向上する。 -\section{ShareScreen} +\section{ShareMyScreen} 従来のVNCでは、配信者が交代するたびにVNCの再起動、サーバ・クライアント間の再接続を行う必要がある。TreeVNCでは配信者の切り替えのたびに生じる問題を解決している。 -TreeVNCを立ち上げることでケーブルを使用せずに、各参加者の手元のPCに発表者の画面を共有することができる。画面の切り替えについてはユーザがVNCサーバへの再接続を行うことなく、ビューワー側のShere Screenボタンを押すことで配信者の切り替えが可能となっている。 +TreeVNCを立ち上げることでケーブルを使用せずに、各参加者の手元のPCに発表者の画面を共有することができる。画面の切り替えについてはユーザがVNCサーバへの再接続を行うことなく、ビューワー側のShere My Screenボタンを押すことで配信者の切り替えが可能となっている。 TreeVNCのROot Nodeは配信者のVNCサーバと通信を行なっている。VNCサーバから画面データを受信し、そのデータを子Nodeへと送信している。配信者切り替え時にShare Screenを実行すると、Root Nodeに対しSERVER\_CHANGE\_REQUESTというメッセージが送信される。このメッセージにはShare Screenボタンを押したNodeの番号やディスプレイ情報が付与されている。メッセージを受け取ったRoot Nodeは配信を希望しているNodeのVNCサーバと通信を始める。 -\section{有線接続と無線接続の違い} -現在のTreeVNCでは有線接続と無線LAN接続のどちらでも、VNCサーバから画面配信の提供を受けることが可能である。しかし画面配信のッデータ量は膨大なため、無線LAN接続を行なった場合画面配信の遅延が大きくなってしまう。 +\section{Multicastの利用} +現在のTreeVNCでは有線接続と無線LAN接続のどちらでも、VNCサーバから画面配信の提供を受けることが可能である。しかし無線LANの帯域は接続PC全部で共有されるために +オーバーレイネットワークを用いる場合は少数の台数の場合でしか実用的には動作しない。 +WifiのMulticastの機能を用いればこの欠点を克服することができると考えられる。 +Root Nodeは無線LANに対して変更するUpdate RectangleをMulticastで一度だけ送信すればよい。 +Treeの構築には従来通りのオーバーレイネットワークを用いる。Root Node は複数のネットワーク毎に木構造とMulticastを管理することになる。 +(図\ref{fig:coexistence})。このMulticastはネットワークがサポートしていればLAN/WAN/Wifiのそれぞれで有効であると思われる。 -無線LAN接続の場合でも画面切り替えの機能は有効であるため、VNCサーバ側が無線LAN接続を行い、クライアント側は有線接続を行うことで画面配信が可能となる。ここで、WifiのMulticastの機能を用いてクライアント側でもWifiを使用することが可能であると考えられる。Root Nodeは無線LANに対して、変更するUpdate RectangleをMulticastで一度だけ送信すればよい。 - -有線接続の場合は従来通り、VNCサーバ、Root Node、Nodeからなるバイナリツリー状に接続されるため、有線接続時と無線LAN接続時でのVNCサーバの接続方法を分割することが可能である。(図\ref{fig:coexistence})。こうすることにより、新しいNodeが無線LAN接続であっても有線接続の木構造に影響を及ぼさない。 +制御構造を木構造オーバーレイネットワークによって行うのは従来のコードを再利用できるのが主な理由でRootに直接接続する方法でも良い。 \begin{figure}[htb]　%PDF \begin{center} @@ -197,8 +202,10 @@ \item 行の初めから、行の途中までを構成するRectangle(図\ref{fig:BlockingUpdateRectangle}中 Phase2) \end{itemize} -\section{TileLoop} +\section{TileLoopの圧縮とブロッキング} TileLoopはVNCサーバから受け取ったZRLEを図\ref{fig:BlockingUpdateRectangle}のようにRectangleを分割し、ZRLEEに再構成を行ったPacketを生成する。 +通常では1画面全部を一つのUpdate Rectangleで送ることがあり、数Mbyteのパケットが生成されしまう。これを再圧縮を行いながら64kbyte以内の +Update Rectangleに分割する。個々のパケットは長方形の集合なので、分割されたパケットは1-3個の長方形を含むことになる。 以下の図\ref{fig:Packet}にTileLoopで生成されるPacket全体と、分割される各PhaseのRectangleを示した。 \begin{figure}[htb]　%PDF @@ -285,12 +292,21 @@ 画面配信をMulticastに対応できるように図\ref{fig:connectMulticast}のようなシステムを構築した。 新しく接続しに来たクライアントはRoot Nodeに対してFind Root を送信する。Root Nodeが見つかれば、Root Nodeはこれに対してFind Root Replyを送り、hostとportについての情報をクライアントに知らせる(図\ref{fig:connectMulticast}中 1,2)。次のメッセージ通信で木構造のどのNodeを親とすれば良いかが決まる(図\ref{fig:connectMulticast}中 3,4)。木構造に接続する理由は、画面配信の初期メッセージを受け取るために行っている(図\ref{fig:connectMulticast}中 5,6)。初期メッセージを受け取った後は、Root NodeよりUpdate Rectangleを受け取ることでMulticastにおける画面配信を可能としている(図\ref{fig:connectMulticast}中 7)。 +\section{実装の現状} +理論上はWifi接続で画面配信が可能であったが、いくつかの問題が発生していることがわかった。 +まず IPv4とIPv6の両方でMulticastを行うことはできない。Javaのlibraryのレベルで失敗してしまう。 +IPv4のMulticastではクライアントが1台のみしか接続できない状況となった。 +IPv6ではMulticast実装は必須なので状況が改善する可能性がある。また、これはWifi Stationの制限である可能性もある。 +接続しているPC上では有線と同等の性能を発揮することができ、Blocking による遅延も数秒程度であった。また、パケット落ちもほとんど見られなかった。 + +Multicast実装は有線上でも有効であると考えられるが、コロナ禍下で大学での実験に制約があり、十分な測定ができていない。 \section{まとめ} + 今回の実装では、Wifiにデータを乗せるためのパケット分割を行うBlockingと、Multicastを行うためのオーバーレイネットワークの実装を行なった。 -理論上はWifi接続で画面配信が可能であったが、IPv4とIPv6の両方でMulticastを行っていたところクライアントが1台のみしか接続できない状況となった。また、IPv4の場合はMulticastが必須対応とされていないため、IPv6優先でオーバーレイネットワークの構築が必要である。 +実装によりMulticastで実用的に画面配信が可能であると推測されるが、まだ、接続が限られるなどの問題があり解決されていない。 現在TreeVNCはPC画面のみ配信をすることが可能であるが、音声を送信することも可能である。その場合、画面よりも音声の方がデータ量少ないため、Multicastでも送信することは可能である。