Mercurial > hg > Papers > 2019 > riono-sigos
annotate Slide/slide.md @ 45:ddd0b2232465
update slide 11p
| author | e165729 <e165729@ie.u-ryukyu.ac.jp> |
|---|---|
| date | Wed, 29 May 2019 22:36:31 +0900 |
| parents | 2709c4da4ba9 |
| children | 4a8bb459e283 |
| rev | line source |
|---|---|
| 32 | 1 title: 画面配信システム TreeVNC のマルチキャストの導入 |
| 2 author: Ryo Yasuda, Shinji Kono | |
| 3 profile: 並列信頼研 | |
| 4 lang: Japanese | |
| 5 code-engine: coderay | |
| 6 | |
| 7 <!-- <\!-- slideshow の command -\-> --> | |
| 8 <!-- slide.htmlでは通常キーでのコマンドが存在している --> | |
| 9 | |
| 10 <!-- p,a,s : スライドを自動送り(1,2...) --> | |
| 11 <!-- : スライドを逆方向に自動送り(...,2,1) --> | |
| 12 <!-- n : Page数を on/off --> | |
| 13 <!-- f : 右下ロゴの on/off --> | |
| 14 <!-- t : slide.html.pdf に変更 --> | |
| 15 <!-- c : 右下スライド移動用UIの on/off --> | |
| 16 <!-- d : ロゴ部分の選択…？ --> | |
| 17 <!-- [URL](http://~~~) --> | |
| 18 <!-- [FILE](file:///Users/ryokka/~~~) --> | |
| 19 <!-- slideshow build スライド.md -t s6cr --> | |
| 20 | |
| 21 <!-- ## 目次 | |
| 22 - **TreeVNC の概要** | |
| 23 - **基本概念** | |
| 24 - **構造** | |
| 25 - 研究内容 | |
| 26 - TreeVNC の改良 | |
| 27 - 送信データの Blocking | |
| 28 --> | |
| 29 | |
|
36
322aad31566d
fix slide and add images
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
35
diff
changeset
|
30 ## 画面配信システムの活用 |
|
37
eb2dbbcaa96e
slide Rewriting and add images
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
36
diff
changeset
|
31 - 講義やゼミではプロジェクタを使用して、先生が用意した資料を見ることが多い。その際接続不良など、物理的アクシデントが起きる恐れがある |
|
eb2dbbcaa96e
slide Rewriting and add images
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
36
diff
changeset
|
32 - 画面配信システムで代用する場合がある。画面配信システムのとしてはAppleTVやUstreamなどが挙げられる |
|
eb2dbbcaa96e
slide Rewriting and add images
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
36
diff
changeset
|
33 - AppleTVは画面共有先がTVに限定されている |
|
eb2dbbcaa96e
slide Rewriting and add images
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
36
diff
changeset
|
34 - Ustreamは画面の切り替えを行うことができない |
|
eb2dbbcaa96e
slide Rewriting and add images
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
36
diff
changeset
|
35 |
|
eb2dbbcaa96e
slide Rewriting and add images
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
36
diff
changeset
|
36 <center><img src="./fig/AppleTVRogo.svg " alt="message" width="200" height="200"> |
|
eb2dbbcaa96e
slide Rewriting and add images
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
36
diff
changeset
|
37 <img src="./fig/UstreamRogo.svg" alt="message" width="200" height="150"></center> |
|
eb2dbbcaa96e
slide Rewriting and add images
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
36
diff
changeset
|
38 |
|
eb2dbbcaa96e
slide Rewriting and add images
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
36
diff
changeset
|
39 |
|
eb2dbbcaa96e
slide Rewriting and add images
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
36
diff
changeset
|
40 ## 画面配信システムの活用 |
| 38 | 41 - 画面配信システムTreeVNCは、自身のPC画面を他者のPCと共有できるソフトウェアである |
| 42 - javaで書かれているためOSに依存せず、物理的な制限なしに使用可能 | |
|
36
322aad31566d
fix slide and add images
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
35
diff
changeset
|
43 - TreeVNCを使用することで、参加者は手元のPCを使用しながら講義を受ける事が可能になる。切り替えの際も、ボタン一つで共有する画面の切替を可能としている |
|
322aad31566d
fix slide and add images
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
35
diff
changeset
|
44 |
| 42 | 45 ## VNC |
| 46 - VNC(Virtual Network Computing)は、RFB(Remote Frame Buffer)プロトコルを用いてPCの遠隔操作を行うことを目的としたリモートデスクトップソフトウェア | |
| 47 - サーバー側とクライアント側に分かれており、起動したサーバーにクライアントが接続することで遠隔操作を可能にしている | |
| 48 - 全てのNodeが一台のサーバーに接続するため負担が大きい | |
| 49 | |
| 43 | 50 <center><img src="./fig/vnc-crop.svg" alt="message" width="450" height="350"></center> |
| 42 | 51 |
| 52 | |
| 38 | 53 ## TreeVNCとは |
| 54 - TreeVNCは本研究室で開発している画面配信システム | |
| 42 | 55 - 木構造の接続方式によりNode間で画像データのやりとりを行う |
| 56 - 各ノードが2回ずつ画像データをコピーすることで配信側の負荷を分散し、大人数での画面配信が可能 | |
| 38 | 57 |
| 58 <center><img src="./fig/treevnc-crop.svg" alt="message" width="450" height="350"></center> | |
| 59 | |
|
36
322aad31566d
fix slide and add images
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
35
diff
changeset
|
60 |
| 39 | 61 ## 本研究の概要 |
|
36
322aad31566d
fix slide and add images
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
35
diff
changeset
|
62 - 画面配信は送信するデータ量が多いため、TreeVNCでは無線接続の場合、画面配信の遅延が大きくなってしまう |
| 39 | 63 - 現在のTreeVNCのデータ転送方法だと、無線接続で送信するには大きすぎる |
| 40 | 64 - 本研究ではMulticastを導入することで、Wifi環境下における画面配信の遅延対策の検討を行なった |
| 39 | 65 |
| 44 | 66 (途中に無線接続,全体delay図) |
| 67 | |
| 43 | 68 ## TreeVNCの画面配信方法 |
| 69 - RFB (Remote Frame Buffer) プロトコルを利用し、自身の画面をネットワークを通じて送信し他者の画面に表示する | |
| 42 | 70 - 他人のPC画面が表示される側と、FrameBufferへの更新が行われる(自身のPC画面を送信する)側に分かれ、それぞれをRFBクライアント、RFBサーバと呼ぶ |
| 71 - FrameBufferは、メモリ上に置かれた画像データのこと | |
| 43 | 72 - RFBクライアントに送信するデータは画面全てではなく、変更があった部分のFrameBufferを送る |
| 42 | 73 |
| 44 | 74 |
| 43 | 75 ## Multicastによる画面配信 |
| 44 | 76 - 配信PC画面の変更があった部分のみをUpdateRectangleとしてマルチキャストで一度のみ送信する |
| 77 - RFBプロトコルでは画像データをRectangleで送信しているため、UpdateRectangleには複数のRectangleが入るような構成をとる | |
| 78 | |
| 79 <center><img src="./fig/UpdateRectangleStruct.svg" alt="message" width="450" height="350"></center> | |
| 43 | 80 |
| 44 | 81 ## Multicastの問題点 |
| 82 - wifiのMulticast Paketの最大サイズは64KBである | |
| 83 - HDや4Kの画面を更新するためのサイズは大きい | |
| 84 - 4Kの場合8MB x 8Byteで64MB | |
| 85 - 送信データの圧縮と64KB毎のパケット変換が必要 | |
| 39 | 86 |
| 44 | 87 ## RFBプロトコルのエンコードタイプ |
| 88 - ZRLEとはRFBプロトコルでサポートされているエンコードタイプの1つ | |
| 89 - zlib圧縮、タイリング、run lengthエンコードを組み合わせている | |
| 90 - 解凍に必要な辞書を書き出すことができないため、途中からデータを受け取ると正確に解凍できなくなる | |
| 91 | |
| 92 (タイリングとrun lengthの説明図) | |
| 93 | |
| 94 ## TreeVNCの画像データ圧縮方法 | |
| 45 | 95 - ZRLEを改変したZRLEEを使用している |
| 96 - 辞書の書き出しを行えるようにし、データを途中から受け取っても解凍することが可能 | |
| 97 - ZRLEを一度解凍し、辞書を書き出して再圧縮を行う | |
| 41 | 98 |
| 44 | 99 <center><img src="./fig/EncodeZRLEE.svg" alt="message" width="550" height="450"></center> |
| 100 | |
| 41 | 101 ## ブロッキング |
| 102 | |
| 44 | 103 |
| 104 ## paket lossする可能性 | |
| 43 | 105 |
| 106 | |
| 41 | 107 |
| 32 | 108 |
| 40 | 109 <!-- ## TreeVNC の構造 |
|
33
762fe0e406e4
add new imange and update slide
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
32
diff
changeset
|
110 - TreeVNCは接続してきたクライアントをNodeとし、木構造状に管理する |
|
762fe0e406e4
add new imange and update slide
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
32
diff
changeset
|
111 - ルートのノードをRoot Nodeと呼び、その下に新たなNodeを接続していく |
| 32 | 112 - Root Nodeが参照しているVNCServerからFrameBufferUpdateを取得し、各Nodeに送信する |
|
33
762fe0e406e4
add new imange and update slide
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
32
diff
changeset
|
113 - 木構造状に接続することで、画像データのコピーを各Nodeに負担させることができる |
| 32 | 114 |
|
37
eb2dbbcaa96e
slide Rewriting and add images
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
36
diff
changeset
|
115 <center><img src="./fig/treevnc-crop.svg" alt="message" width="450" height="350"></center> |
| 32 | 116 |
|
33
762fe0e406e4
add new imange and update slide
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
32
diff
changeset
|
117 |
|
762fe0e406e4
add new imange and update slide
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
32
diff
changeset
|
118 ## 木構造の再構成 |
|
762fe0e406e4
add new imange and update slide
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
32
diff
changeset
|
119 - Nodeが切断されたことを検知できなければ木構造が維持できない |
|
762fe0e406e4
add new imange and update slide
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
32
diff
changeset
|
120 - Root Nodeが木構造のネットワークトポロジーを管理しているため、Root NodeにNodeの切断を知らせる必要がある |
| 35 | 121 - 切断検知には画像データが入っているMulticastQueueを使用 |
|
33
762fe0e406e4
add new imange and update slide
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
32
diff
changeset
|
122 - MulticastQueueから画像データが一定時間取得されず、Timeoutを検知した場合切断したと判断する |
|
762fe0e406e4
add new imange and update slide
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
32
diff
changeset
|
123 |
|
762fe0e406e4
add new imange and update slide
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
32
diff
changeset
|
124 ## 画像データのエンコード方法 |
|
762fe0e406e4
add new imange and update slide
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
32
diff
changeset
|
125 - TreeVNCではZRLEというエンコードタイプを元にした、ZRLEEというエンコードを用いて画像データを圧縮を行う |
|
37
eb2dbbcaa96e
slide Rewriting and add images
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
36
diff
changeset
|
126 - ZRLEはZlibで圧縮されたデータとそのデータのバイト数がヘッダーとして送られる |
|
eb2dbbcaa96e
slide Rewriting and add images
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
36
diff
changeset
|
127 - Zlibとはデータの可逆圧縮アルゴリズムが実装されているライブラリ |
|
36
322aad31566d
fix slide and add images
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
35
diff
changeset
|
128 |
|
322aad31566d
fix slide and add images
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
35
diff
changeset
|
129 ## 画像データのエンコード方法 |
|
33
762fe0e406e4
add new imange and update slide
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
32
diff
changeset
|
130 - ZRLEでは解凍時に必要な辞書データを書き出すことができない |
|
762fe0e406e4
add new imange and update slide
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
32
diff
changeset
|
131 - ZRLEEはRoot Nodeで受け取ったZRLEのデータを一度解凍し、辞書データを付与して再圧縮している |
|
762fe0e406e4
add new imange and update slide
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
32
diff
changeset
|
132 |
|
37
eb2dbbcaa96e
slide Rewriting and add images
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
36
diff
changeset
|
133 <center><img src="./fig/EncodeZRLEE.svg" alt="message" width="550" height="450"></center> |
|
33
762fe0e406e4
add new imange and update slide
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
32
diff
changeset
|
134 |
| 32 | 135 ## 共有画面切り替え |
| 34 | 136 - 従来のVNCでは、配信者が切り替わるたびに再起動、再接続を行う必要があった |
| 137 - TreeVNCでは、画面上にあるShareScreenボタンを押すことで配信者の切り替えが実行できる | |
| 138 - ShareScreen実行後、Root Nodeに対しSERVER CHANGE REQUESTというメッセージが送信される | |
| 139 - メッセージを受け取ったRoot Nodeは配信を希望しているNodeのVNCサーバーと通信を行い、切り替え作業に入る | |
| 32 | 140 |
|
36
322aad31566d
fix slide and add images
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
35
diff
changeset
|
141 <center><img src="./fig/ShareScreenSS.svg" alt="message" width="400" height="300"></center> |
|
322aad31566d
fix slide and add images
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
35
diff
changeset
|
142 |
|
33
762fe0e406e4
add new imange and update slide
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
32
diff
changeset
|
143 ## 有線接続との接続の違い |
| 34 | 144 - 現状のTreeVNCでは画面配信のデータ量は多く、無線LAN接続を行うと画面配信の遅延が大きくなる |
| 145 - WifiのMulticast機能を利用し、UpdateRectangleを一度だけ送信することで無線LAN接続でも十分に遅延が抑えられると考える | |
| 146 - HDや4kの画面更新には64MB程度となり、これを圧縮しつつwifiのMulticast paketの最大サイズ64KBに変換、送信する必要がある | |
| 147 - paket lossがあった場合、再送処理は複雑であると予想できるため、まずBlokingによる実験を行う | |
|
33
762fe0e406e4
add new imange and update slide
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
32
diff
changeset
|
148 |
|
762fe0e406e4
add new imange and update slide
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
32
diff
changeset
|
149 ## RFBプロトコルのUpdateRectangleの構成 |
| 34 | 150 - 1つのUpdateRectangleには複数のRectangleが格納されている |
| 151 - RectangleはZlibで圧縮されたデータが指定された長さだけ格納されており、そのデータはさらに64x64 ByteのTileに分割されている | |
|
37
eb2dbbcaa96e
slide Rewriting and add images
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
36
diff
changeset
|
152 |
|
eb2dbbcaa96e
slide Rewriting and add images
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
36
diff
changeset
|
153 ## RFBプロトコルのUpdateRectangleの構成 |
| 34 | 154 - 無線接続の場合、一度に送信できるデータ量が64KBしかないため、それに合わせて更新された部分のRectangleを分割する必要がある |
| 155 - Phase0 行の途中から始まる部分 | |
| 156 - Phase1 行の最初から最後までの部分 | |
| 157 - Phase2 行の途中で終わる部分 | |
|
33
762fe0e406e4
add new imange and update slide
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
32
diff
changeset
|
158 |
|
37
eb2dbbcaa96e
slide Rewriting and add images
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
36
diff
changeset
|
159 <center><img src="./fig/FrameUpdateRectangleColor.svg" alt="message" width="550" height="450"></center> |
|
33
762fe0e406e4
add new imange and update slide
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
32
diff
changeset
|
160 |
|
762fe0e406e4
add new imange and update slide
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
32
diff
changeset
|
161 |
|
762fe0e406e4
add new imange and update slide
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
32
diff
changeset
|
162 ## 木構造とマルチキャストの共存 |
| 34 | 163 - ツリーに無線接続のNodeを加えてしまうと全体の配信遅延に繋がる |
| 164 - 無線接続時のMulticastの実装を提案 | |
| 165 - Multicastならば、Serverからの送信は一度で済むため、ツリー構造の形成が必要ない | |
| 166 - 従って新しいNodeが無線接続であっても、有線接続のツリーの配信には影響が出ない | |
| 32 | 167 |
|
37
eb2dbbcaa96e
slide Rewriting and add images
e165729 <e165729@ie.u-ryukyu.ac.jp>
parents:
36
diff
changeset
|
168 <center><img src="./fig/interface-crop.svg" alt="message" width="500" height="450"></center> |
| 40 | 169 --> |
| 32 | 170 |
| 171 ## まとめ | |
| 35 | 172 - WifiでMulticast paketを利用する手法についての考察を行なった |
| 173 - Wifiの速度とMulticastの信頼性が高ければ実用的である可能性がある | |
| 174 - Blockingは実装中、再圧縮の時間は実用的な時間で済むと予想されている | |
| 34 | 175 |
| 32 | 176 - 今後の課題 |
| 35 | 177 - Blockingの実装 |
| 178 - WifiのMulticast paket lossは接続環境や状況に依存すると思われるためさらなる実験が必要 | |
| 179 - Node接続じの有線接続と無線接続の判断、区別処理の実装 | |
| 180 |