title: PC画面配信システムTreeVNCの NAT への対応
author: Tatsuki IHA, Shinji KONO
profile:
lang: Japanese
code-engine: coderay

# 画面共有を利用したコミュニケーション
- 授業やゼミ等で、それぞれが PC 端末を持っている場合では、PC の機能を活かした コミュニケーションが可能である
- 画面配信システム TreeVNC は参加したクライアントをバイナリツリー状に接続し、配信コストを分散させる 仕組みを取っている。そのため, 多人数が参加しても処理性能が下がらない
- ツリー のルートが参照している VNC サーバーを変更することで、ケーブルの差し替えなしに画面の切替が行える

# TreeVNC の問題点
- TreeVNC を実際に使用していく中で様々な問題が発生
- 講義等を大学外の遠隔地から受けたい場合がある
- TreeVNC は NAT を越えた接続が行うことができない

# TreeVNC の問題点
- ゼミ等で発表者毎に画面切り替えを行う際、デュアルディスプレイを使っている学生がいた
- その際 VNC サーバーからはすべての画面データが送信されており、発表とは関係ない画面も配信されていた

<img src="./images/multidisplay.svg" alt="message" width="500">

# この発表は
- TreeVNC の概要
    - 構造
    - 原理
    - 画面切り替え
- 今回の改良
    - NAT を越えた通信
    - マルチディスプレイの対応
- TreeVNC の評価
    - 画像データ送信の遅延
    - ネックになってるノードへの対処

# TreeVNC
-  TreeVNC は本研究室で開発している VNC を利用した画面配信システム
- 参加したクライアントをバイナリツリー状で接続することで配信コストを分散させる
- スムーズな配信画面の切替を行う

<img src="./images/treeVnc.svg" alt="message" width="400">

# VNC
- VNC(Virtual Network Computing) は RFBプロトコルを用いて遠隔操作を行うソフトウェア
- サーバー側とクライアント側に分かれており、サーバーを起動し、クライアントがサーバーに接続を行うことで遠隔操作を可能とする

<img src="./images/vnc.svg" alt="message" width="600">

# RFB プロトコル
- RFB(Remote Frame Buffer)プロトコルは VNC で用いられているプロトコル
- 自身の画面をネットワーク越しに他者の画面に表示する
- Framebuffer と呼ばれるメモリ上に置かれた画像データを使用して画面表示を行う
- サーバーは Framebuffer が更新されるたびにクライアントに対して変更部分だけを送信する。

# TreeVNC の構造
- Java で作成されたTightVNC(Tight Virtual Network Computing) を元に作成されている
- 様々なメッセージで通信を行う
- クライアント同士をバイナリツリー状に接続する
- バイナリツリーのルートのノードをRoot Nodeと呼び、 Root Node に接続されるノードを Node と呼ぶ

# TreeVNCの原理
- ポート一本あたりの負荷
    - 従来のVNC : Node数 * データ量
    - TreeVNC   : (2(子供の数) + 1) * データ量
- 従来のVNCはNode数に比例
- TreeVNCはNode数に関係なく一定

<img src="./images/treeVncTheory.svg" alt="message" width="600">

# 切断時の木の再構成
- TreeVNC はバイナリーツリーという特性上 Node の切断を検知できずにいると、Node 同士で構成された木構造が崩れてしまう
- TreeVNC は Node 切断の検知を LOST\_CHILD というメッセージで行っている

<img src="./images/lostChild.svg" alt="message" width="800">

# 共有画面切り替え
- TreeVNC の Root Node は配信者の VNC サーバーと通信を行っている
- 画面を配信されている側のビューワにある Share Screen ボタンが押す 
- Root Node に SERVER\_CHANGE\_REQUEST を木構造を辿りながら送信
- Root Node は Share Screen ボタンを押したクライアントの VNC サーバーと通信を開始

# Direct Connection
- NATを越えたネットワークからの接続は直接配信側の Root Node に接続を行うことで実現する
- Direct Connection した Node はそのネットワークの Root Node になる
- Direct Connection された Root Node では NAT を越えたネットワーク先の Node の管理を行わない

<img src="./images/directConnection.svg" alt="message" width="800">

# マルチディスプレイ
- 画面切り替えの際のSERVER\_CHANGE\_REQUESTに共有するディスプレイの座標を付加する
- Root Node は 接続した VNC サーバーから画像データを要求する FRAME\_BUFFER\_UPDATE\_REQUEST に受け取った座標を付加する
- VNC サーバーは要求された座標内の画像データを FRAME\_BUFFER\_UPDATE で Root Node に送信する

<img src="./images/shareScreenToMultiDisplay.svg" alt="message" width="800">

# TreeVNCの評価
- 木の深さによる画像データの遅延を調べる
- 実験環境
    - 実際に講義を受講している学生が TreeVNC を使用
    - 約20名の接続

# 実測方法
- Root Node は 送信時間と画像データを持った CHECK\_DELAY を 末端 Node まで木構造を辿りながら伝達する
- CHECK\_DELAY を受け取った各 Node は 付加された送信時間を CHECK\_DELAY\_REPLY に付加し、 Root Node に送信する
- CHECK\_DELAY\_REPLY を受け取った Root Node は CHECK\_DELAY の送信にどれだけ時間がかかったかの計算を行う

```java
// 遅延時間の計算
Long delay = System.currentTimeMillis() - time;
```

# 深さ1, 2
<img src="./images/depth1.svg" alt="message" width="450">
<img src="./images/depth2.svg" alt="message" width="450">

# 深さ3, 4
<img src="./images/depth3.svg" alt="message" width="450">
<img src="./images/depth4.svg" alt="message" width="450">

# 結果から
- 画像データの伝達はほぼ1秒以内に収まっている
- 容量が小さい場合でも時間がかかる場合がある。 それはその送信の前に大容量の画像を送信した後の回線の遅延が残っているためだと考えられる
- 深さ3が遅い原因として1つの Node がボトルネックになっている事が判明した。
- ネックになった Node をそのままにするとその子Nodeに影響を及ぼしてしまう。 そのためその Node に何らかの対応を行う必要がある

# ネックになっているノードへの対処
- CHECK\_DELAY\_REPLY で Root Node は ネックかどうかのを判断をする
- ネックになっているなら、そのノードを木構造のリストから削除
- 最後のノードを削除したnodeの場所に移動
- ネックになったところは三分木になる

<img src="./images/fixTree.svg" alt="message" width="800">

# まとめと課題
- 今回TreeVNCの様々な問題点の解決を行った
- 実験を行うことによりさらなる問題点が判明した
- 実測で判明したネックになっているNodeへの対処
- NATを越えた画面切り替え
- 追加した機能の評価方法を思考し、評価を行う