author: Ryo Yasuda, Shinji Kono profile: 並列信頼研

# 画面配信システムの活用

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

# 画面配信システムの活用

• 画面配信システム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が一台のサーバーに接続するため負担が大きい

# TreeVNCとは

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

# UpdateRectangleによる画面更新

• RFB (Remote Frame Buffer) プロトコルを利用し、自身の画面をネットワークを通じて送信し他者の画面に表示する
• クライアントに送信するデータは画面全てではなく、変更があった部分のFrameBufferを送る
• 配信PC画面の変更があった部分のみをRFBで、UpdateRectangleとしてマルチキャストで一度のみ送信する
• RFBプロトコルでは画像データをRectangleで送信しているため、UpdateRectangleとして送信されるPacketには複数のRectangleが入るような構成をとっている

# RFBプロトコルのエンコードタイプ

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

# RFBプロトコルのエンコードタイプ

• 解凍に必要な辞書を書き出すことができないため、途中からデータを受け取ると正確に解凍できなくなる

# TreeVNCの画像データ圧縮方法

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

# Multicastの問題点

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

# Blockingの考察

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

# Blockingの考察

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

# 圧縮方式

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

# 圧縮方法

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