# Multicast Wifi VNCの実装と評価
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>
-->
- コロナ禍によりリモートワークが推進され、ビデオ通話ソフトウェアの重要性が高まっている
- リモートワークではPCの画面共有を行って、情報を共有することも多い
- ビデオ通話ソフトウェアとしてはZoomやMicrosoft Teamsなどが挙げられる

(zoomとteamsの画像)

## 画面配信システムの活用
- 既存のソフトウェアではカメラを利用したビデオ通話に重点を置いて開発されており、PC画面を共有するとぼやけてしまう
- ビデオ通話にはそれぞれのサービスのサーバを経由しなければならない

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


## 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を使っているため圧縮率が低下しているため、圧縮率の向上についての考察