有線 LAN 上のPC画面配信システムTreeVNCの改良
Tatsuki IHA, Shinji KONO
画面共有を利用したコミュニケーション
授業やゼミ等で、それぞれが PC 端末を持っている場合では、PC の機能を活かした コミュニケーションが可能である
画面配信システム TreeVNC は参加したクライアントをバイナリツリー状に接続し、配信コストを分散させる 仕組みを取っている。そのため, 多人数が参加しても処理性能が下がらない
ツリー のルートが参照している VNC サーバーを変更することで、ケーブルの差し替えなしに画面の切替が行える
TreeVNC の問題点
TreeVNC を実際に使用していく中で様々な問題が発生した。
琉球大学では無線と有線が別々のネットワークになっている
TreeVNCは単一のネットワークにしか対応できず、両方のネットワークにつながっている端末でも1つのネットワークでしか使用できなかった
講義等を大学外の遠隔地から受けたい場合がある
TreeVNC は NAT を越えた接続が行うことができない
TreeVNC の問題点
ゼミ等で発表者毎に画面切り替えを行う際、デュアルディスプレイを使っている人がいた
その際 VNC サーバーからはすべての画面データが送信されており、発表とは関係ない画面も配信されていた
この発表は
TreeVNC の概要
構造
圧縮形式
TreeVNC の原理
画面切り替え
今回の改良
描画処理の安定化
複数のネットワークの対応
NAT を越えた通信
マルチディスプレイの対応
TreeVNC の評価
画像データ送信の遅延
TreeVNC
TreeVNC は本研究室で開発している VNC を利用した画面配信システム
参加したクライアントをバイナリツリー状で接続することで配信コストを分散させる
スムーズな配信画面の切替を行う
VNC
VNC(Virtual Network Computing) は RFBプロトコルを用いて遠隔操作を行うソフトウェア
サーバー側とクライアント側に分かれており、サーバーを起動し、クライアントがサーバーに接続を行うことで遠隔操作を可能とする
RFB プロトコル
RFB(Remote Frame Buffer)プロトコルは VNC で用いられているプロトコル
自身の画面をネットワーク越しに他者の画面に表示する
Framebuffer と呼ばれるメモリ上に置かれた画像データを使用して画面表示を行う
サーバーは Framebuffer が更新されるたびにクライアントに対して変更部分だけを送信する。
多人数でVNCを使用する際の問題点
多人数のクライアントが1つのサーバーに接続する構造
サーバー側の処理性能が落ちてしまう
配信者を切り替える際、配信側のサーバーを立ち上げ直す必要がある
TreeVNC の構造
Java で作成されたTightVNC(Tight Virtual Network Computing) を元に作成されている
様々なメッセージで通信を行う
クライアント同士をバイナリツリー状に接続する
バイナリツリーのルートのノードをRoot Nodeと呼び、 Root Node に接続されるノードを Node と呼ぶ
Node が行う処理
Node
親 Node から送られたデータを自分の子 Node に流す
子 Node から送られてきたデータを親 Nodeに流す
Root Node
TreeVNC で配信を行う際に一番最初に起動する Node
Node の機能
各 Node の管理
VNC サーバーから送信されたFramebuffer の管理
TreeVNCの負荷分散
ポート一本あたりの負荷
従来のVNC : Node数 * データ量
TreeVNC : (2(子供の数) + 1) * データ量
従来のVNCはNode数に比例
TreeVNCはNode数に関係なく一定
TreeVNC の圧縮形式
TreeVNC は ZRLEE というエンコードでデータのやり取りを行う
ZRLEE は Rfb でのエンコードの1つである ZRLE を元に生成される
ZRLE を一度 Root Node で解凍して再圧縮を行う
配信画面の更新のたびに辞書を作りなおす
途中からデータを受け取っても解凍できる
メッセージ通信の流れ
切断時の木の再構成
TreeVNC はバイナリーツリーという特性上 Node の切断を検知できずにいると、Node 同士で構成された木構造が崩れてしまう
TreeVNC は Node 切断の検知を LOST_CHILD というメッセージで行っている
共有画面切り替え
TreeVNC の Root Node は配信者の VNC サーバーと通信を行っている
画面を配信されている側のビューワにある Share Screen ボタンが押す
Root Node に SERVER_CHANGE_REQUEST を送信する
Root Node は Share Screen ボタンを押したクライアントの VNC サーバーと通信を始める。
NAT 越えは現時点では実装されていない
QUALITY モードと SPEED モード
高解像度のデータの描画処理はPCのスペックによって重くなる場合がある
画像描画処理には
高画質優先の QUALITY モード
描画速度優先の SPEED モード
今まで QUALITY モード を使用していた(変更不可)
ビューワからユーザーがどちらのモードを使用するかを変更を可能にした
マルチディスプレイ
画面切り替えの際のSERVER_CHANGE_REQUESTに共有するディスプレイの座標を付加する
Root Node は 接続した VNC サーバーから画像データを要求する FRAME_BUFFER_UPDATE_REQUEST に受け取った座標を付加する
VNC サーバーは要求された座標内の画像データを FRAME_BUFFER_UPDATE で Root Node に送信する
複数ネットワークの対応
Root Node が接続しているネットワークごとに木構造を形成する
新しい Node が接続してきた際、 interfaces から Node のネットワークと一致する木構造を取得し、 接続の処理を任せる
Direct Connection
NATを越えたネットワークからの接続は直接配信側の Root Node に接続を行うことで実現する
Direct Connection した Node はそのネットワークの Root Node になる
Direct Connection された Root Node では NAT を越えたネットワーク先の Node の管理を行わない
TreeVNCの評価
木の深さによる画像データの遅延を調べる
実験環境
実際に講義を受講している学生が TreeVNC を使用
約20名の接続
実測方法
Root Node は 送信時間と画像データを持った CHECK_DELAY を 末端 Node まで木構造を辿りながら伝達する
CHECK_DELAY を受け取った各 Node は 付加された送信時間を CHECK_DELAY_REPLY に付加し、 Root Node に送信する
CHECK_DELAY_REPLY を受け取った Root Node は CHECK_DELAY の送信にどれだけ時間がかかったかの計算を行う
// 遅延時間の計算 Long delay = System.currentTimeMillis() - time;
深さ1, 2
深さ3, 4
結果から
画像データの伝達はほぼ1秒以内に収まっている
容量が小さい場合でも時間がかかる場合がある。 それはその送信の前に大容量の画像を送信した後の回線の遅延が残っているためだと考えられる
深さ3が遅い原因として1つの Node がボトルネックになっている事が判明した。
ネックになった Node をそのままにするとその子Nodeに影響を及ぼしてしまう。 そのためその Node に何らかの対応を行う必要がある
まとめと課題
今回TreeVNCの様々な問題点の解決を行った
実験を行うことによりさらなる問題点が判明した
実測で判明したネックになっているNodeへの対処
NATを越えた画面切り替え
追加した機能の評価方法を思考し、評価を行う