画面配信システム TreeVNC のマルチキャストの導入
Ryo Yasuda, Shinji Kono 並列信頼研
画面配信システムの活用
講義やゼミではプロジェクタを使用して、先生が用意した資料を見ることが多い。その際接続不良など、物理的アクシデントが起きる恐れがある
画面配信システムで代用する場合がある。画面配信システムのとしてはAppleTVやUstreamなどが挙げられる
AppleTVは画面共有先がTVに限定されている
Ustreamは画面の切り替えを行うことができない
画面配信システムの活用
当研究室が開発している画面配信システムTreeVNCは、自身のPC画面を他者のPCと共有できるソフトウェアである
javaで書かれているためOSに依存せず、物理的な制限なしに使用可能である
TreeVNCを使用することで、参加者は手元のPCを使用しながら講義を受ける事が可能になる。切り替えの際も、ボタン一つで共有する画面の切替を可能としている
TreeVNCとは
TreeVNCは本研究室で開発している画面配信システム
VNC(リモートデスクトップソフトウェア)を利用している
木構造の接続方式によりNode間で画像データのやりとりを行うことで、配信側の負荷を分散し大人数での画面配信が可能
TreeVNCのマルチキャスト利用
TreeVNCの問題点
画面配信は送信するデータ量が多いため、TreeVNCでは無線接続の場合、画面配信の遅延が大きくなってしまう
現在のTreeVNCのデータ転送方法だと、無線接続で送信するには大きすぎる
本研究ではマルチキャストを導入することで、Wifi環境下における画面配信の遅延対応の検討する
VNC
VNC(Virtual Network Computing)は、RFBプロトコルを用いてPCの遠隔操作を行うことを目的としたリモートデスクトップソフトウェア
サーバー側とクライアント側に分かれており、起動したサーバーにクライアントが接続することで遠隔操作を可能にしている
全てのNodeが一台のサーバーに接続するため負担が大きい
RFB プロトコル
RFB (Remote Frame Buffer) プロトコルは、自身の画面をネットワークを通じて送信し他者の画面に表示するプロトコル
他人のPC画面が表示される側と、FrameBufferへの更新が行われる(自身のPC画面を送信する)側に分かれ、それぞれをRFBクライアント、RFBサーバと呼ぶ
FrameBufferは、メモリ上に置かれた画像データのこと
TreeVNC の構造
TreeVNCは接続してきたクライアントをNodeとし、木構造状に管理する
ルートのノードをRoot Nodeと呼び、その下に新たなNodeを接続していく
Root Nodeが参照しているVNCServerからFrameBufferUpdateを取得し、各Nodeに送信する
木構造状に接続することで、画像データのコピーを各Nodeに負担させることができる
木構造の再構成
Nodeが切断されたことを検知できなければ木構造が維持できない
Root Nodeが木構造のネットワークトポロジーを管理しているため、Root NodeにNodeの切断を知らせる必要がある
切断検知には画像データが入っているMulticastQueueを使用
MulticastQueueから画像データが一定時間取得されず、Timeoutを検知した場合切断したと判断する
画像データのエンコード方法
TreeVNCではZRLEというエンコードタイプを元にした、ZRLEEというエンコードを用いて画像データを圧縮を行う
ZRLEはZlibで圧縮されたデータとそのデータのバイト数がヘッダーとして送られる
Zlibとはデータの可逆圧縮アルゴリズムが実装されているライブラリ
画像データのエンコード方法
ZRLEでは解凍時に必要な辞書データを書き出すことができない
ZRLEEはRoot Nodeで受け取ったZRLEのデータを一度解凍し、辞書データを付与して再圧縮している
共有画面切り替え
従来のVNCでは、配信者が切り替わるたびに再起動、再接続を行う必要があった
TreeVNCでは、画面上にあるShareScreenボタンを押すことで配信者の切り替えが実行できる
ShareScreen実行後、Root Nodeに対しSERVER CHANGE REQUESTというメッセージが送信される
メッセージを受け取ったRoot Nodeは配信を希望しているNodeのVNCサーバーと通信を行い、切り替え作業に入る
有線接続との接続の違い
現状のTreeVNCでは画面配信のデータ量は多く、無線LAN接続を行うと画面配信の遅延が大きくなる
WifiのMulticast機能を利用し、UpdateRectangleを一度だけ送信することで無線LAN接続でも十分に遅延が抑えられると考える
HDや4kの画面更新には64MB程度となり、これを圧縮しつつwifiのMulticast paketの最大サイズ64KBに変換、送信する必要がある
paket lossがあった場合、再送処理は複雑であると予想できるため、まずBlokingによる実験を行う
RFBプロトコルのUpdateRectangleの構成
1つのUpdateRectangleには複数のRectangleが格納されている
RectangleはZlibで圧縮されたデータが指定された長さだけ格納されており、そのデータはさらに64x64 ByteのTileに分割されている
RFBプロトコルのUpdateRectangleの構成
無線接続の場合、一度に送信できるデータ量が64KBしかないため、それに合わせて更新された部分のRectangleを分割する必要がある
Phase0 行の途中から始まる部分
Phase1 行の最初から最後までの部分
Phase2 行の途中で終わる部分
木構造とマルチキャストの共存
ツリーに無線接続のNodeを加えてしまうと全体の配信遅延に繋がる
無線接続時のMulticastの実装を提案
Multicastならば、Serverからの送信は一度で済むため、ツリー構造の形成が必要ない
従って新しいNodeが無線接続であっても、有線接続のツリーの配信には影響が出ない
まとめ
WifiでMulticast paketを利用する手法についての考察を行なった
Wifiの速度とMulticastの信頼性が高ければ実用的である可能性がある
Blockingは実装中、再圧縮の時間は実用的な時間で済むと予想されている
今後の課題
Blockingの実装
WifiのMulticast paket lossは接続環境や状況に依存すると思われるためさらなる実験が必要
Node接続じの有線接続と無線接続の判断、区別処理の実装
