# 画面配信システム TreeVNC のマルチキャストの導入
author: Ryo Yasuda, Shinji Kono
profile: 並列信頼研

## 画面配信システムの活用
- 講義やゼミではプロジェクタを使用して、先生が用意した資料を見ることが多い。その際接続不良など、物理的アクシデントが起きる恐れがある
- 画面配信システムで代用する場合がある。画面配信システムのとしてはAppleTVやUstreamなどが挙げられる
    - AppleTVは画面共有先がTVに限定されている
    - Ustreamは画面の切り替えを行うことができない


<center><img src="https://i.imgur.com/5lT1RZ9.png" alt="message" width="200" height="200">
<img src="https://i.imgur.com/qpeYXUl.png" alt="message" width="200" height="150"></center>




## 画面配信システムの活用
- 画面配信システムTreeVNCは、自身のPC画面を他者のPCと共有できるソフトウェアである
- javaで書かれているためOSに依存せず、物理的な制約なしに使用可能
- TreeVNCを使用することで、参加者は手元のPCを使用しながら講義を受ける事が可能になる。切り替えの際も、ボタン1つで共有する画面の切替を可能としている

## TreeVNCの講義等での活用
- 講義では先生のPC画面を手元のPCで見ることで、コマンドを手元で打ち間違えや、メモを取る際にPCのみに集中を向けることができるようになった
- ゼミにおいてもコードをつなげるために移動する必要がなく、各自の席で発表者の画面を見ることができる
- 以上のようにTreeVNCは従来のプロジェクタなどよりも利便性が高い

## 本研究の概要
- 画面配信は送信するデータ量が多いため、TreeVNCでは無線接続の場合、画面配信の遅延が大きくなってしまう
- 現在のTreeVNCのデータ転送方法だと、無線接続で送信するには大きすぎる 
- 本研究ではMulticastの導入としてBlockingによるデータの分割を実装した

## VNC
- VNC(Virtual Network Computing)は、RFB(Remote Frame Buffer)プロトコルを用いてPCの遠隔操作を行うことを目的としたリモートデスクトップソフトウェア
- サーバー側とクライアント側に分かれており、起動したサーバーにクライアントが接続することで遠隔操作を可能にしている
- 全てのNodeが一台のサーバーに接続するため負担が大きい

<center><img src="https://i.imgur.com/ufIEIe5.png)" alt="message" width="450" height="300"></center>


## TreeVNCとは
- TreeVNCは本研究室で開発している画面配信システム
- 木構造の接続方式によりNode間で画像データのやりとりを行う
- 各ノードが2回ずつ画像データをコピーすることで配信側の負荷を分散し、大人数での画面配信が可能

<center><img src="https://i.imgur.com/zpeYi9p.png" alt="message" width="450" height="300"></center>
      
## UpdateRectangleによる画面更新
- RFB (Remote Frame Buffer) プロトコルを利用し、自身の画面をネットワークを通じて送信し他者の画面に表示する
- クライアントに送信するデータは画面全てではなく、変更があった部分のFrameBufferを送る
- 配信PC画面の変更があった部分のみをRFBで、UpdateRectangleとしてマルチキャストで一度のみ送信する
- RFBプロトコルでは画像データをRectangleで送信しているため、UpdateRectangleとして送信されるPacketには複数のRectangleが入るような構成をとっている

<center><img src="https://i.imgur.com/ZN6jMYI.png" alt="message" width="450" height="300"></center>


## RFBプロトコルのエンコードタイプ
- ZRLEとはRFBプロトコルでサポートされているエンコードタイプの1つ
- zlib圧縮、タイリング、run lengthエンコードを組み合わせている

<center><img src="https://i.imgur.com/CdGCftg.png" alt="message" width="500" height="350"></center>

## RFBプロトコルのエンコードタイプ
- 解凍に必要な辞書を書き出すことができないため、途中からデータを受け取ると正確に解凍できなくなる

<center><img src="https://i.imgur.com/VxeaTMD.png"
alt="message" width="500" height="350"></center>



## TreeVNCの画像データ圧縮方法
- ZRLEを応用したZRLEEを使用している
- 辞書の書き出しを行えるようにし、データを途中から受け取っても解凍することが可能
- ZRLEを一度解凍し、辞書を書き出して再圧縮を行う


<center><img src="https://i.imgur.com/VxeaTMD.png" alt="message" width="500" height="400"></center>


## Multicastの問題点
- wifiのMulticast Paketの最大サイズは64KBである
- HDや4Kの画面を更新するためのサイズは大きい
    - 4Kディスプレイの場合8MB(画素数) x 8Byte(色情報)で64MB
- 送信データの圧縮と64KB毎のパケット変換が必要


## Blockingの考察
- 64KBのパケットに収めるため、ZRLEEで圧縮する前にBlockingを行い、Rectangleの再構成を行う
- ZRLEを解凍したデータのRectangleは以下のような状況になっていると考えられ、Phaseで区別する
    - 行の途中から行の最後まで　　Phase0
    - 行の最初から最後まで　　　　Phase1
    - 行の最初から行の途中まで　　Phase2

<center><img src="https://i.imgur.com/HrqYOhP.png" alt="message" width="600" height="400"></center>


## Blockingの考察
- 最大3つのRectangleの再構成を行いつつ、ZRLEEで変換を行いパケットの構成をする
- Packetの先頭にはmessageIDなどが格納されているPacke Headerがある
- 各RectangleにはRectangleのx,y座標や圧縮されたデータ長などが格納されているRectangle Headerを持っている


<center><img src="https://i.imgur.com/HrqYOhP.png" alt="message" width="600" height="400"></center>


## 圧縮方式
- zlibには以下の3つの圧縮方法が存在する
    * NO FLUSH : Stream に格納されたデータを最高率で 圧縮を行う。Stream にある入力データが規定量に満た ない場合は圧縮されない
    * SYNC FLUSH : これまでに Stream に格納されたデー タの圧縮を行う。ただし圧縮率が低下する可能性がある
    * FULL FLUSH : SYNC FLUSH 同様、これまでに Stream に格納されたデータの圧縮を行う。異なる点 はこれまでの辞書情報がリセットされるため、圧縮率 が極端に低くなる可能性がある 


<!--## paket lossする可能性
- wifiのMulticast paketは確実に送信されることが保証されておらず、paket lossする可能性がある
- その対策としては以下の2つが取れる
    - 何もしない、定期的に全画面のデータが送信されるため問題ないと考える
    - 再送要求を行う、処理が複雑であることが予想される
- 現状では定期的に全画面のデータを送信しており、十分実用に耐えると考える
-->

## 圧縮方法
- 1TileごとにSYNC_FLUSHを行なっている
- 行末ではFULL_FLUSHを行う
- NO_FLUSHを利用していないためデータの圧縮率は下がる

## その他の実装
- TreeVNCのBuildに使用している、Gradleを4.8から6.1へのバージョンアップ対応
- java9以降非推奨だったRetinaAIPの更新対応 
- デバッグオプションの修正


## まとめ
- WifiでBlockingを用いて、Multicast paketを利用する手法についての考察と実装を行なった
    - Wifiの速度とMulticastの信頼性が高ければ実用的である可能性がある

- TreeVNCのBuildやAPIのバージョンアップ対応、デバッグオプション修正を行なった
    
- 今後の課題
    - Multicast通信の実装
    - WifiのMulticast paket lossは接続環境や状況に依存すると思われるためさらなる実験が必要
    - Node接続時の有線接続と無線接続の判断、区別処理の実装
    - SYNC_FLUSHを使っているため圧縮率が低下しているため、圧縮率の向上についての考察