|
2
|
1 # 画面配信システム TreeVNC のマルチキャストの導入
|
|
0
|
2 author: Ryo Yasuda, Shinji Kono
|
|
|
3 profile: 並列信頼研
|
|
|
4
|
|
|
5 ## 画面配信システムの活用
|
|
|
6 - 講義やゼミではプロジェクタを使用して、先生が用意した資料を見ることが多い。その際接続不良など、物理的アクシデントが起きる恐れがある
|
|
|
7 - 画面配信システムで代用する場合がある。画面配信システムのとしてはAppleTVやUstreamなどが挙げられる
|
|
|
8 - AppleTVは画面共有先がTVに限定されている
|
|
|
9 - Ustreamは画面の切り替えを行うことができない
|
|
|
10
|
|
2
|
11
|
|
|
12 <center><img src="https://i.imgur.com/5lT1RZ9.png" alt="message" width="200" height="200">
|
|
|
13 <img src="https://i.imgur.com/qpeYXUl.png" alt="message" width="200" height="150"></center>
|
|
|
14
|
|
|
15
|
|
0
|
16
|
|
|
17
|
|
|
18 ## 画面配信システムの活用
|
|
|
19 - 画面配信システムTreeVNCは、自身のPC画面を他者のPCと共有できるソフトウェアである
|
|
2
|
20 - javaで書かれているためOSに依存せず、物理的な制約なしに使用可能
|
|
|
21 - TreeVNCを使用することで、参加者は手元のPCを使用しながら講義を受ける事が可能になる。切り替えの際も、ボタン1つで共有する画面の切替を可能としている
|
|
0
|
22
|
|
|
23 ## TreeVNCの講義等での活用
|
|
|
24 - 講義では先生のPC画面を手元のPCで見ることで、コマンドを手元で打ち間違えや、メモを取る際にPCのみに集中を向けることができるようになった
|
|
|
25 - ゼミにおいてもコードをつなげるために移動する必要がなく、各自の席で発表者の画面を見ることができる
|
|
|
26 - 以上のようにTreeVNCは従来のプロジェクタなどよりも利便性が高い
|
|
|
27
|
|
2
|
28 ## 本研究の概要
|
|
|
29 - 画面配信は送信するデータ量が多いため、TreeVNCでは無線接続の場合、画面配信の遅延が大きくなってしまう
|
|
|
30 - 現在のTreeVNCのデータ転送方法だと、無線接続で送信するには大きすぎる
|
|
|
31 - 本研究ではMulticastの導入としてBlockingによるデータの分割を実装した
|
|
|
32
|
|
0
|
33 ## VNC
|
|
|
34 - VNC(Virtual Network Computing)は、RFB(Remote Frame Buffer)プロトコルを用いてPCの遠隔操作を行うことを目的としたリモートデスクトップソフトウェア
|
|
|
35 - サーバー側とクライアント側に分かれており、起動したサーバーにクライアントが接続することで遠隔操作を可能にしている
|
|
|
36 - 全てのNodeが一台のサーバーに接続するため負担が大きい
|
|
|
37
|
|
2
|
38 <center><img src="https://i.imgur.com/ufIEIe5.png)" alt="message" width="450" height="300"></center>
|
|
0
|
39
|
|
|
40
|
|
|
41 ## TreeVNCとは
|
|
|
42 - TreeVNCは本研究室で開発している画面配信システム
|
|
|
43 - 木構造の接続方式によりNode間で画像データのやりとりを行う
|
|
|
44 - 各ノードが2回ずつ画像データをコピーすることで配信側の負荷を分散し、大人数での画面配信が可能
|
|
|
45
|
|
2
|
46 <center><img src="https://i.imgur.com/zpeYi9p.png" alt="message" width="450" height="300"></center>
|
|
|
47
|
|
|
48 ## UpdateRectangleによる画面更新
|
|
|
49 - RFB (Remote Frame Buffer) プロトコルを利用し、自身の画面をネットワークを通じて送信し他者の画面に表示する
|
|
|
50 - クライアントに送信するデータは画面全てではなく、変更があった部分のFrameBufferを送る
|
|
|
51 - 配信PC画面の変更があった部分のみをRFBで、UpdateRectangleとしてマルチキャストで一度のみ送信する
|
|
|
52 - RFBプロトコルでは画像データをRectangleで送信しているため、UpdateRectangleとして送信されるPacketには複数のRectangleが入るような構成をとっている
|
|
|
53
|
|
|
54 <center><img src="https://i.imgur.com/ZN6jMYI.png" alt="message" width="450" height="300"></center>
|
|
0
|
55
|
|
|
56
|
|
2
|
57 ## RFBプロトコルのエンコードタイプ
|
|
|
58 - ZRLEとはRFBプロトコルでサポートされているエンコードタイプの1つ
|
|
|
59 - zlib圧縮、タイリング、run lengthエンコードを組み合わせている
|
|
|
60
|
|
|
61 <center><img src="https://i.imgur.com/CdGCftg.png" alt="message" width="500" height="350"></center>
|
|
|
62
|
|
|
63 ## RFBプロトコルのエンコードタイプ
|
|
|
64 - 解凍に必要な辞書を書き出すことができないため、途中からデータを受け取ると正確に解凍できなくなる
|
|
|
65
|
|
|
66 <center><img src="https://i.imgur.com/VxeaTMD.png"
|
|
|
67 alt="message" width="500" height="350"></center>
|
|
0
|
68
|
|
|
69
|
|
|
70
|
|
2
|
71 ## TreeVNCの画像データ圧縮方法
|
|
|
72 - ZRLEを応用したZRLEEを使用している
|
|
|
73 - 辞書の書き出しを行えるようにし、データを途中から受け取っても解凍することが可能
|
|
|
74 - ZRLEを一度解凍し、辞書を書き出して再圧縮を行う
|
|
|
75
|
|
|
76
|
|
|
77 <center><img src="https://i.imgur.com/VxeaTMD.png" alt="message" width="500" height="400"></center>
|
|
|
78
|
|
0
|
79
|
|
|
80 ## Multicastの問題点
|
|
|
81 - wifiのMulticast Paketの最大サイズは64KBである
|
|
|
82 - HDや4Kの画面を更新するためのサイズは大きい
|
|
2
|
83 - 4Kディスプレイの場合8MB(画素数) x 8Byte(色情報)で64MB
|
|
0
|
84 - 送信データの圧縮と64KB毎のパケット変換が必要
|
|
|
85
|
|
|
86
|
|
|
87 ## Blockingの考察
|
|
|
88 - 64KBのパケットに収めるため、ZRLEEで圧縮する前にBlockingを行い、Rectangleの再構成を行う
|
|
|
89 - ZRLEを解凍したデータのRectangleは以下のような状況になっていると考えられ、Phaseで区別する
|
|
|
90 - 行の途中から行の最後まで Phase0
|
|
|
91 - 行の最初から最後まで Phase1
|
|
|
92 - 行の最初から行の途中まで Phase2
|
|
|
93
|
|
2
|
94 <center><img src="https://i.imgur.com/HrqYOhP.png" alt="message" width="600" height="400"></center>
|
|
|
95
|
|
0
|
96
|
|
|
97 ## Blockingの考察
|
|
|
98 - 最大3つのRectangleの再構成を行いつつ、ZRLEEで変換を行いパケットの構成をする
|
|
2
|
99 - Packetの先頭にはmessageIDなどが格納されているPacke Headerがある
|
|
|
100 - 各RectangleにはRectangleのx,y座標や圧縮されたデータ長などが格納されているRectangle Headerを持っている
|
|
0
|
101
|
|
|
102
|
|
2
|
103 <center><img src="https://i.imgur.com/HrqYOhP.png" alt="message" width="600" height="400"></center>
|
|
0
|
104
|
|
|
105
|
|
2
|
106 ## 圧縮方式
|
|
|
107 - zlibには以下の3つの圧縮方法が存在する
|
|
|
108 * NO FLUSH : Stream に格納されたデータを最高率で 圧縮を行う。Stream にある入力データが規定量に満た ない場合は圧縮されない
|
|
|
109 * SYNC FLUSH : これまでに Stream に格納されたデー タの圧縮を行う。ただし圧縮率が低下する可能性がある
|
|
|
110 * FULL FLUSH : SYNC FLUSH 同様、これまでに Stream に格納されたデータの圧縮を行う。異なる点 はこれまでの辞書情報がリセットされるため、圧縮率 が極端に低くなる可能性がある
|
|
0
|
111
|
|
|
112
|
|
2
|
113 <!--## paket lossする可能性
|
|
|
114 - wifiのMulticast paketは確実に送信されることが保証されておらず、paket lossする可能性がある
|
|
|
115 - その対策としては以下の2つが取れる
|
|
|
116 - 何もしない、定期的に全画面のデータが送信されるため問題ないと考える
|
|
|
117 - 再送要求を行う、処理が複雑であることが予想される
|
|
|
118 - 現状では定期的に全画面のデータを送信しており、十分実用に耐えると考える
|
|
|
119 -->
|
|
0
|
120
|
|
2
|
121 ## 圧縮方法
|
|
|
122 - 1TileごとにSYNC_FLUSHを行なっている
|
|
|
123 - 行末ではFULL_FLUSHを行う
|
|
|
124 - NO_FLUSHを利用していないためデータの圧縮率は下がる
|
|
0
|
125
|
|
2
|
126 ## その他の実装
|
|
|
127 - TreeVNCのBuildに使用している、Gradleを4.8から6.1へのバージョンアップ対応
|
|
|
128 - java9以降非推奨だったRetinaAIPの更新対応
|
|
|
129 - デバッグオプションの修正
|
|
0
|
130
|
|
|
131
|
|
2
|
132 ## まとめ
|
|
|
133 - WifiでBlockingを用いて、Multicast paketを利用する手法についての考察と実装を行なった
|
|
|
134 - Wifiの速度とMulticastの信頼性が高ければ実用的である可能性がある
|
|
0
|
135
|
|
2
|
136 - TreeVNCのBuildやAPIのバージョンアップ対応、デバッグオプション修正を行なった
|
|
0
|
137
|
|
|
138 - 今後の課題
|
|
2
|
139 - Multicast通信の実装
|
|
0
|
140 - WifiのMulticast paket lossは接続環境や状況に依存すると思われるためさらなる実験が必要
|
|
2
|
141 - Node接続時の有線接続と無線接続の判断、区別処理の実装
|
|
|
142 - SYNC_FLUSHを使っているため圧縮率が低下しているため、圧縮率の向上についての考察
|
|
0
|
143 |
