授業やゼミ向けの画面共有システム
TreeVNCの設計と実装
谷成 雄
Feb 4, 2014
授業やゼミ向けの画面共有システム
概要
大学の講義、プロジェクタなどの投影機を用いて授業を行っているが、スクリーンに写されている画面は後ろの席に行けば行くほど見えづらくなる。
その問題を画面共有ソフトVNCを用いて、手元のコンピュータに講師の画面を表示することで解決しようと考えた。
しかし、通常のVNCを用いて多人数が同時に接続するとサーバ側の処理性のが低下し、授業の進行について行かなくなってしまう。
本研究では、多人数で使用しても処理性能が低下することない画面共有システムTreeVNCの設計と実装を行い、更にゼミなどで使用しやすいようにUIの提案と実装も行った。
VNCについて
VNC(Virtual Network Computing)とは、RFBプロトコルというプロトコルを用いて画面共有を実現することのできるアプリケーションである。
RFBプロトコルはGUI操作によるリモートアクセス用の通信プロトコルである。
ソースコードはオープンソースとして公開されているため、多数の派生ソフトが存在する。
派生ソフトには、RealVNCやTightVNCなどがある。
多人数でVNCを使用する場合の問題点
VNC Serverに対して、一極集中型で接続してしまうので、VNC ServerへのCPU負荷が高い。
VNC Server側の通信網1本への通信負荷が高い。
多人数でVNCを使用する場合の問題点
1台と48台でVNC Serverに接続した時のCPU使用率とスループット
| スループット(単位:bps) | CPU使用率 | |
| 1台 | 20M(VNCでの最大速度) | 55% |
| 48台 | 4M(1台あたり) | 100% |
48台でVNC Serverに接続した際、CPU使用率が100%になりスループットが5分の1まで下がってしまう。
TreeVNCの設計
多人数でVNCを使用する際は、VNC Serverに一極集中で接続してしまうのが問題であったので、集中している負荷を分散できないか考えた。
VNC Serverに負荷が集中しているので、クライントに負荷を分散するようにクライアント同士でのデータをやりとりすることで負荷分散ができる。
クライント同士の接続を木構造に行って、データを上から下へと流しすようにすることで、すべてのクライアントへデータを届ける。 今後、木構造に接続されたクライアントのことをNodeと呼ぶ。
TreeVNCの設計
Nodeを木構造に接続させるために、トポロジを管理する特別なNodeが必要になる。今後このノードのことをRoot Nodeと呼ぶ。
RootNodeはVNC Serverに接続し、Nodeの接続に対して木構造にNodeを接続するように命令を出す。
TreeVNCの原理
TreeVNCでは、接続が分散していて、通信網1本に対する負荷が減少するのでNodeが増えても高いスループットを保つことができる。
木の構成方法
- Nodeは接続を行う時にRoot Nodeに接続し、Root Nodeから接続するべき場所のIPアドレスをもらう。
- Root Nodeは接続してきたNodeのIPアドレスを自身が持つリストに登録し、接続先のIPアドレスを返す。
- Nodeは指定されたNodeに接続を行う。
Nodeが接続される度に、この手順を繰り返すことで、木を構成することができる。
画面切り替えの実装
授業ではなくゼミなどの多数発表者がいる場面で、TreeVNCを用いるためには、発表者が変わる度にRoot NodeとNodeがアプリケーションを立ち上げなおさなければならない。 発表者が大勢いると切り替えだけで時間を取られてしまう。
そこで、ボタンひとつで画面を切り替えることのできるように実装を行った。
画面の切り替え
画面の切替手順は以下のとおりである。
- Node側が、アプリケーションのWindowに配置された、切り替えボタンを押すと、Root Nodeに対してボタンを押したNodeのIPアドレスが渡される。
- Root Nodeは受け取ったIPアドレスのNodeに対して、接続要求を出す。
- Nodeが要求を認証するとRoot Nodeは現在使用しているストリームを閉じて、すべてのNodeに対して画面が切り替わったことを知らせる。
- Nodeは切り替わった画面への接続を行う。
マルチディスプレイの対応
マルチディスプレイを使用してTreeVNCを使用する場合、Nodeにすべてのディスプレイのデータが送られてしまう。 しかし、実際、発表する際には一つのディスプレイしか使用しない場合が多いので、無駄なデータが流れていることになる。 Node側も見たい画面へとスクロールする手間が出てくる。
一つのディスプレイのデータを送ることができるように実装を行った。
マルチディスプレイの対応
RFBプロトコルの中ではFrameBufferUpdateで、画像データの送信を行っている。 画像のやりとりの手順は以下の表である。
| バイト数 | 説明 |
|---|---|
| 2 | message-type and padding |
| 2 | number-of-rectangle |
| 2 | x-position |
| 2 | y-position |
| 2 | width |
| 2 | height |
| 4 | encoding-type |
マルチディスプレイの対応
流れてきたx-position,y-position,width,heightで画像の位置と大きさがわかる。
２つディスプレイがある場合は、２つのディスプレイにまたがった画像のデータが来ることはない。
そこで、Root Nodeでフィルタリングしてやることで一つのディスプレイの情報を送ることができる。 例えば上の図で左側の画面の画像を送信したい場合は、x-positionが1920以下の画像だけを、Nodeに送ることでひとつのディスプレイデータを送ることが実現できる。
MulticastとBroadcastについて
TreeVNCでは、TCPコネクションを用いて、通信を行っているので、クライアント数の通信が必要である。
BroadcastやMulticastを用いると、データ送信は一回だけで良い。
しかし、BroadcastとMulticastのは、パケットの確実性は保証していないので、パケットが消失してしまうことがある。
MulticastとBroadcastについて
どの程度パケットが消失しているのかをテストしてみた。 以下の表は100packetデータを送信してデータのロス率を調べた表である。
| 256byte | 4000byte | |
| Broadcast | 47% | 87% |
| Multicast | 0% | 37% |
Multicastを使用しても、4000byteで1000packetを送信して37%のデータをロスしているので、予想以上にロス率が高い。
MulticastとBroadcast
MulticastとBroadcastは、一回のデータ送信で、約64000byteのデータしか送信することができない。
1920*1080の画像で送られてくるデータは6220800byteである。つまりデータを約100個に分割しなければならない。
分割するテストプログラムを書いてみたところ、分割と送信に画面共有に支障をきたすほど処理が遅くなってしまった。
TreeVNCの評価
TreeVNCを評価するために複数のNodeが必要となる、そこで今回は学科で提供されている並列計算環境を利用して、実験を行った。 使用した並列計算環境の性能は以下の図に示す。
| 名前 | 概要 |
|---|---|
| CPU | Intel(R) CPU X5650@2.67GHz |
| 物理コア数 | 2 |
| 物理コア数 | 4 |
| OS | CentOS 5.8 |
| 台数 | 48台 |
TreeVNCの評価
TreeVNCは木構造で構成されているので、一番上のノードから一番下のノードまで、データが届くのに時間がかかってしまう可能性がある。
| 段数 | 遅延 |
|---|---|
| 2 | 約1ミリ秒 |
| 4 | 約58ミリ秒 |
| 6 |
約139ミリ秒
Full-slide embed with (optional) slide title on topThank you! |