Mercurial > hg > Papers > 2019 > riono-sigos
changeset 34:5bfea3be9c5f
update slide ~13p
author | e165729 <e165729@ie.u-ryukyu.ac.jp> |
---|---|
date | Sun, 26 May 2019 18:01:14 +0900 |
parents | 762fe0e406e4 |
children | ebb35af869a7 |
files | Slide/slide.html Slide/slide.md Slide/slide.pdf.html |
diffstat | 3 files changed, 93 insertions(+), 111 deletions(-) [+] |
line wrap: on
line diff
--- a/Slide/slide.html Sun May 26 15:40:24 2019 +0900 +++ b/Slide/slide.html Sun May 26 18:01:14 2019 +0900 @@ -107,15 +107,9 @@ <!-- _S9SLIDE_ --> <h2 id="画面配信システムの活用">画面配信システムの活用</h2> <ul> - <li> - <p>講義や発表の場では、プロジェクタが使用されることが多い。その場合接続不良など、アクシデントが起きる恐れがある</p> - </li> - <li> - <p>画面配信システムTreeVNCは、自身のPC画面を他者のPCに表示するソフトウェアである</p> - </li> - <li> - <p>TreeVNCを使用することで、参加者は手元のPCを使用しながら講義を受ける事が可能になる。切り替えの際も、ボタン一つで共有する画面の切替を可能としている</p> - </li> + <li>講義や発表の場では、プロジェクタが使用されることが多い。その場合接続不良など、アクシデントが起きる恐れがある</li> + <li>画面配信システムTreeVNCは、自身のPC画面を他者のPCに表示するソフトウェアである</li> + <li>TreeVNCを使用することで、参加者は手元のPCを使用しながら講義を受ける事が可能になる。切り替えの際も、ボタン一つで共有する画面の切替を可能としている</li> </ul> @@ -125,7 +119,6 @@ <div class='slide'> <!-- _S9SLIDE_ --> <h2 id="treevncの現状">TreeVNCの現状</h2> - <ul> <li>問題点 <ul> @@ -157,15 +150,9 @@ <!-- _S9SLIDE_ --> <h2 id="treevnc">TreeVNC</h2> <ul> - <li> - <p>TreeVNC は本研究室で開発している画面配信システム</p> - </li> - <li> - <p>VNC(リモートデスクトップソフトウェア)を利用している</p> - </li> - <li> - <p>木構造の接続方式を採用し、配信側の負荷を分散し大人数での画面配信が可能</p> - </li> + <li>TreeVNC は本研究室で開発している画面配信システム</li> + <li>VNC(リモートデスクトップソフトウェア)を利用している</li> + <li>木構造の接続方式を採用し、配信側の負荷を分散し大人数での画面配信が可能</li> </ul> @@ -191,15 +178,9 @@ <!-- _S9SLIDE_ --> <h2 id="rfb-プロトコル">RFB プロトコル</h2> <ul> - <li> - <p>RFB (Remote Frame Buffer) プロトコルは、自身の画面をネットワークを通じて送信し他者の画面に表示するプロトコル</p> - </li> - <li> - <p>他人のPC画面が表示される側と、FrameBufferへの更新が行われる(自身のPC画面を送信する)側に分かれ、それぞれをRFBクライアント、RFBサーバと呼ぶ</p> - </li> - <li> - <p>FrameBufferは、メモリ上に置かれた画像データのこと</p> - </li> + <li>RFB (Remote Frame Buffer) プロトコルは、自身の画面をネットワークを通じて送信し他者の画面に表示するプロトコル</li> + <li>他人のPC画面が表示される側と、FrameBufferへの更新が行われる(自身のPC画面を送信する)側に分かれ、それぞれをRFBクライアント、RFBサーバと呼ぶ</li> + <li>FrameBufferは、メモリ上に置かれた画像データのこと</li> </ul> @@ -255,10 +236,10 @@ <!-- _S9SLIDE_ --> <h2 id="共有画面切り替え">共有画面切り替え</h2> <ul> - <li>従来の VNC では、配信者が切り替わるたびに再起動、再接続を行う必要があった</li> - <li>TreeVNC では、画面上にある ShareScreen ボタンを押すことで配信者の切り替えが実行できる</li> - <li>ShareScreen 実行後、Root Node に対し SERVER CHANGE REQUEST というメッセージが送信される。</li> - <li>メッセージを受け取った Root Node は配信を希望している Node の VNC サーバーと通信を行い、切り替え作業に入る。</li> + <li>従来のVNCでは、配信者が切り替わるたびに再起動、再接続を行う必要があった</li> + <li>TreeVNCでは、画面上にあるShareScreenボタンを押すことで配信者の切り替えが実行できる</li> + <li>ShareScreen実行後、Root Nodeに対しSERVER CHANGE REQUESTというメッセージが送信される</li> + <li>メッセージを受け取ったRoot Nodeは配信を希望しているNodeのVNCサーバーと通信を行い、切り替え作業に入る</li> </ul> @@ -268,6 +249,12 @@ <div class='slide'> <!-- _S9SLIDE_ --> <h2 id="有線接続との接続の違い">有線接続との接続の違い</h2> +<ul> + <li>現状のTreeVNCでは画面配信のデータ量は多く、無線LAN接続を行うと画面配信の遅延が大きくなる</li> + <li>WifiのMulticast機能を利用し、UpdateRectangleを一度だけ送信することで無線LAN接続でも十分に遅延が抑えられると考える</li> + <li>HDや4kの画面更新には64MB程度となり、これを圧縮しつつwifiのMulticast paketの最大サイズ64KBに変換、送信する必要がある</li> + <li>paket lossがあった場合、再送処理は複雑であると予想できるため、まずBlokingによる実験を行う</li> +</ul> @@ -277,11 +264,13 @@ <!-- _S9SLIDE_ --> <h2 id="rfbプロトコルのupdaterectangleの構成">RFBプロトコルのUpdateRectangleの構成</h2> <ul> - <li>無線接続の場合、一度に送信できるデータ量が 64kbyte しかないため、それに合わせてデータを分割する必要がある</li> - <li>大きなデータを小さい単位に分割する + <li>1つのUpdateRectangleには複数のRectangleが格納されている</li> + <li>RectangleはZlibで圧縮されたデータが指定された長さだけ格納されており、そのデータはさらに64x64 ByteのTileに分割されている</li> + <li>無線接続の場合、一度に送信できるデータ量が64KBしかないため、それに合わせて更新された部分のRectangleを分割する必要がある <ul> - <li>更新が行われた部分を1行ずつ圧縮していく</li> - <li>書き込みのために用意した関数に入る限界値まで圧縮を行ない、関数に書き込む</li> + <li>Phase0 行の途中から始まる部分</li> + <li>Phase1 行の最初から最後までの部分</li> + <li>Phase2 行の途中で終わる部分</li> </ul> </li> </ul> @@ -296,10 +285,10 @@ <!-- _S9SLIDE_ --> <h2 id="木構造とマルチキャストの共存">木構造とマルチキャストの共存</h2> <ul> - <li>ツリーに無線接続の Node を加えてしまうと配信の遅延に繋がる</li> - <li>Multicast の実装を提案</li> - <li>Multicast ならば、Server からの送信は一度で済むため、ツリー構造の形成が必要ない</li> - <li>従って新しい Node が 無線接続であっても、有線接続のツリーの配信には影響が出ない</li> + <li>ツリーに無線接続のNodeを加えてしまうと全体の配信遅延に繋がる</li> + <li>無線接続時のMulticastの実装を提案</li> + <li>Multicastならば、Serverからの送信は一度で済むため、ツリー構造の形成が必要ない</li> + <li>従って新しいNodeが無線接続であっても、有線接続のツリーの配信には影響が出ない</li> </ul> <center><img src="./fig/interface-crop.svg" alt="message" width="400" height="350" /></center> @@ -312,11 +301,12 @@ <!-- _S9SLIDE_ --> <h2 id="まとめ">まとめ</h2> <ul> - <li>TreeVNC の改良と Multicast 対応のためのデータの Blocking を実装した。 + <li></li> + <li> + <p>Multicast対応のためのデータのBlockingを実装した</p> + <ul> - <li>VNCServer 側が接続を切断した場合でもクライアントが正しく終了する様にした。</li> - <li>画面操作の許可を確認する authentication のポップアップが Root 側に表示されない様にした。</li> - <li>データの Blocking を行うことにより、無線接続での Multicast 対応を行えるようにした。</li> + <li>データの Blocking を行うことにより、無線接続での Multicast 対応を行えるようにした</li> </ul> </li> <li>今後の課題
--- a/Slide/slide.md Sun May 26 15:40:24 2019 +0900 +++ b/Slide/slide.md Sun May 26 18:01:14 2019 +0900 @@ -20,9 +20,7 @@ ## 画面配信システムの活用 - 講義や発表の場では、プロジェクタが使用されることが多い。その場合接続不良など、アクシデントが起きる恐れがある - - 画面配信システムTreeVNCは、自身のPC画面を他者のPCに表示するソフトウェアである - - TreeVNCを使用することで、参加者は手元のPCを使用しながら講義を受ける事が可能になる。切り替えの際も、ボタン一つで共有する画面の切替を可能としている @@ -44,9 +42,7 @@ ## TreeVNC - TreeVNC は本研究室で開発している画面配信システム - - VNC(リモートデスクトップソフトウェア)を利用している - - 木構造の接続方式を採用し、配信側の負荷を分散し大人数での画面配信が可能 ## VNC @@ -58,9 +54,7 @@ ## RFB プロトコル - RFB (Remote Frame Buffer) プロトコルは、自身の画面をネットワークを通じて送信し他者の画面に表示するプロトコル - - 他人のPC画面が表示される側と、FrameBufferへの更新が行われる(自身のPC画面を送信する)側に分かれ、それぞれをRFBクライアント、RFBサーバと呼ぶ - - FrameBufferは、メモリ上に置かれた画像データのこと ## TreeVNC の構造 @@ -86,37 +80,45 @@ <center><img src="./fig/EncodeZRLEE.svg" alt="message" width="400" height="300"></center> ## 共有画面切り替え -- 従来の VNC では、配信者が切り替わるたびに再起動、再接続を行う必要があった -- TreeVNC では、画面上にある ShareScreen ボタンを押すことで配信者の切り替えが実行できる -- ShareScreen 実行後、Root Node に対し SERVER CHANGE REQUEST というメッセージが送信される。 -- メッセージを受け取った Root Node は配信を希望している Node の VNC サーバーと通信を行い、切り替え作業に入る。 +- 従来のVNCでは、配信者が切り替わるたびに再起動、再接続を行う必要があった +- TreeVNCでは、画面上にあるShareScreenボタンを押すことで配信者の切り替えが実行できる +- ShareScreen実行後、Root Nodeに対しSERVER CHANGE REQUESTというメッセージが送信される +- メッセージを受け取ったRoot Nodeは配信を希望しているNodeのVNCサーバーと通信を行い、切り替え作業に入る ## 有線接続との接続の違い - +- 現状のTreeVNCでは画面配信のデータ量は多く、無線LAN接続を行うと画面配信の遅延が大きくなる +- WifiのMulticast機能を利用し、UpdateRectangleを一度だけ送信することで無線LAN接続でも十分に遅延が抑えられると考える +- HDや4kの画面更新には64MB程度となり、これを圧縮しつつwifiのMulticast paketの最大サイズ64KBに変換、送信する必要がある +- paket lossがあった場合、再送処理は複雑であると予想できるため、まずBlokingによる実験を行う ## RFBプロトコルのUpdateRectangleの構成 -- 無線接続の場合、一度に送信できるデータ量が 64kbyte しかないため、それに合わせてデータを分割する必要がある -- 大きなデータを小さい単位に分割する - - 更新が行われた部分を1行ずつ圧縮していく - - 書き込みのために用意した関数に入る限界値まで圧縮を行ない、関数に書き込む +- 1つのUpdateRectangleには複数のRectangleが格納されている +- RectangleはZlibで圧縮されたデータが指定された長さだけ格納されており、そのデータはさらに64x64 ByteのTileに分割されている +- 無線接続の場合、一度に送信できるデータ量が64KBしかないため、それに合わせて更新された部分のRectangleを分割する必要がある + - Phase0 行の途中から始まる部分 + - Phase1 行の最初から最後までの部分 + - Phase2 行の途中で終わる部分 <center><img src="./fig/FrameUpdateRectangle.svg" alt="message" width="400" height="250"></center> ## 木構造とマルチキャストの共存 -- ツリーに無線接続の Node を加えてしまうと配信の遅延に繋がる -- Multicast の実装を提案 -- Multicast ならば、Server からの送信は一度で済むため、ツリー構造の形成が必要ない -- 従って新しい Node が 無線接続であっても、有線接続のツリーの配信には影響が出ない +- ツリーに無線接続のNodeを加えてしまうと全体の配信遅延に繋がる +- 無線接続時のMulticastの実装を提案 +- Multicastならば、Serverからの送信は一度で済むため、ツリー構造の形成が必要ない +- 従って新しいNodeが無線接続であっても、有線接続のツリーの配信には影響が出ない <center><img src="./fig/interface-crop.svg" alt="message" width="400" height="350"></center> ## まとめ -- TreeVNC の改良と Multicast 対応のためのデータの Blocking を実装した。 - - VNCServer 側が接続を切断した場合でもクライアントが正しく終了する様にした。 - - 画面操作の許可を確認する authentication のポップアップが Root 側に表示されない様にした。 - - データの Blocking を行うことにより、無線接続での Multicast 対応を行えるようにした。 +- + +- Multicast対応のためのデータのBlockingを実装した + + - データの Blocking を行うことにより、無線接続での Multicast 対応を行えるようにした + + - 今後の課題 - Multicast の実装 - Multicast 実行時の遅延の評価
--- a/Slide/slide.pdf.html Sun May 26 15:40:24 2019 +0900 +++ b/Slide/slide.pdf.html Sun May 26 18:01:14 2019 +0900 @@ -91,15 +91,9 @@ <!-- _S9SLIDE_ --> <h2 id="画面配信システムの活用">画面配信システムの活用</h2> <ul> - <li> - <p>講義や発表の場では、プロジェクタが使用されることが多い。その場合接続不良など、アクシデントが起きる恐れがある</p> - </li> - <li> - <p>画面配信システムTreeVNCは、自身のPC画面を他者のPCに表示するソフトウェアである</p> - </li> - <li> - <p>TreeVNCを使用することで、参加者は手元のPCを使用しながら講義を受ける事が可能になる。切り替えの際も、ボタン一つで共有する画面の切替を可能としている</p> - </li> + <li>講義や発表の場では、プロジェクタが使用されることが多い。その場合接続不良など、アクシデントが起きる恐れがある</li> + <li>画面配信システムTreeVNCは、自身のPC画面を他者のPCに表示するソフトウェアである</li> + <li>TreeVNCを使用することで、参加者は手元のPCを使用しながら講義を受ける事が可能になる。切り替えの際も、ボタン一つで共有する画面の切替を可能としている</li> </ul> @@ -109,7 +103,6 @@ <div class='slide'> <!-- _S9SLIDE_ --> <h2 id="treevncの現状">TreeVNCの現状</h2> - <ul> <li>問題点 <ul> @@ -141,15 +134,9 @@ <!-- _S9SLIDE_ --> <h2 id="treevnc">TreeVNC</h2> <ul> - <li> - <p>TreeVNC は本研究室で開発している画面配信システム</p> - </li> - <li> - <p>VNC(リモートデスクトップソフトウェア)を利用している</p> - </li> - <li> - <p>木構造の接続方式を採用し、配信側の負荷を分散し大人数での画面配信が可能</p> - </li> + <li>TreeVNC は本研究室で開発している画面配信システム</li> + <li>VNC(リモートデスクトップソフトウェア)を利用している</li> + <li>木構造の接続方式を採用し、配信側の負荷を分散し大人数での画面配信が可能</li> </ul> @@ -175,15 +162,9 @@ <!-- _S9SLIDE_ --> <h2 id="rfb-プロトコル">RFB プロトコル</h2> <ul> - <li> - <p>RFB (Remote Frame Buffer) プロトコルは、自身の画面をネットワークを通じて送信し他者の画面に表示するプロトコル</p> - </li> - <li> - <p>他人のPC画面が表示される側と、FrameBufferへの更新が行われる(自身のPC画面を送信する)側に分かれ、それぞれをRFBクライアント、RFBサーバと呼ぶ</p> - </li> - <li> - <p>FrameBufferは、メモリ上に置かれた画像データのこと</p> - </li> + <li>RFB (Remote Frame Buffer) プロトコルは、自身の画面をネットワークを通じて送信し他者の画面に表示するプロトコル</li> + <li>他人のPC画面が表示される側と、FrameBufferへの更新が行われる(自身のPC画面を送信する)側に分かれ、それぞれをRFBクライアント、RFBサーバと呼ぶ</li> + <li>FrameBufferは、メモリ上に置かれた画像データのこと</li> </ul> @@ -239,10 +220,10 @@ <!-- _S9SLIDE_ --> <h2 id="共有画面切り替え">共有画面切り替え</h2> <ul> - <li>従来の VNC では、配信者が切り替わるたびに再起動、再接続を行う必要があった</li> - <li>TreeVNC では、画面上にある ShareScreen ボタンを押すことで配信者の切り替えが実行できる</li> - <li>ShareScreen 実行後、Root Node に対し SERVER CHANGE REQUEST というメッセージが送信される。</li> - <li>メッセージを受け取った Root Node は配信を希望している Node の VNC サーバーと通信を行い、切り替え作業に入る。</li> + <li>従来のVNCでは、配信者が切り替わるたびに再起動、再接続を行う必要があった</li> + <li>TreeVNCでは、画面上にあるShareScreenボタンを押すことで配信者の切り替えが実行できる</li> + <li>ShareScreen実行後、Root Nodeに対しSERVER CHANGE REQUESTというメッセージが送信される</li> + <li>メッセージを受け取ったRoot Nodeは配信を希望しているNodeのVNCサーバーと通信を行い、切り替え作業に入る</li> </ul> @@ -252,6 +233,12 @@ <div class='slide'> <!-- _S9SLIDE_ --> <h2 id="有線接続との接続の違い">有線接続との接続の違い</h2> +<ul> + <li>現状のTreeVNCでは画面配信のデータ量は多く、無線LAN接続を行うと画面配信の遅延が大きくなる</li> + <li>WifiのMulticast機能を利用し、UpdateRectangleを一度だけ送信することで無線LAN接続でも十分に遅延が抑えられると考える</li> + <li>HDや4kの画面更新には64MB程度となり、これを圧縮しつつwifiのMulticast paketの最大サイズ64KBに変換、送信する必要がある</li> + <li>paket lossがあった場合、再送処理は複雑であると予想できるため、まずBlokingによる実験を行う</li> +</ul> @@ -261,11 +248,13 @@ <!-- _S9SLIDE_ --> <h2 id="rfbプロトコルのupdaterectangleの構成">RFBプロトコルのUpdateRectangleの構成</h2> <ul> - <li>無線接続の場合、一度に送信できるデータ量が 64kbyte しかないため、それに合わせてデータを分割する必要がある</li> - <li>大きなデータを小さい単位に分割する + <li>1つのUpdateRectangleには複数のRectangleが格納されている</li> + <li>RectangleはZlibで圧縮されたデータが指定された長さだけ格納されており、そのデータはさらに64x64 ByteのTileに分割されている</li> + <li>無線接続の場合、一度に送信できるデータ量が64KBしかないため、それに合わせて更新された部分のRectangleを分割する必要がある <ul> - <li>更新が行われた部分を1行ずつ圧縮していく</li> - <li>書き込みのために用意した関数に入る限界値まで圧縮を行ない、関数に書き込む</li> + <li>Phase0 行の途中から始まる部分</li> + <li>Phase1 行の最初から最後までの部分</li> + <li>Phase2 行の途中で終わる部分</li> </ul> </li> </ul> @@ -280,10 +269,10 @@ <!-- _S9SLIDE_ --> <h2 id="木構造とマルチキャストの共存">木構造とマルチキャストの共存</h2> <ul> - <li>ツリーに無線接続の Node を加えてしまうと配信の遅延に繋がる</li> - <li>Multicast の実装を提案</li> - <li>Multicast ならば、Server からの送信は一度で済むため、ツリー構造の形成が必要ない</li> - <li>従って新しい Node が 無線接続であっても、有線接続のツリーの配信には影響が出ない</li> + <li>ツリーに無線接続のNodeを加えてしまうと全体の配信遅延に繋がる</li> + <li>無線接続時のMulticastの実装を提案</li> + <li>Multicastならば、Serverからの送信は一度で済むため、ツリー構造の形成が必要ない</li> + <li>従って新しいNodeが無線接続であっても、有線接続のツリーの配信には影響が出ない</li> </ul> <center><img src="./fig/interface-crop.svg" alt="message" width="400" height="350" /></center> @@ -296,11 +285,12 @@ <!-- _S9SLIDE_ --> <h2 id="まとめ">まとめ</h2> <ul> - <li>TreeVNC の改良と Multicast 対応のためのデータの Blocking を実装した。 + <li></li> + <li> + <p>Multicast対応のためのデータのBlockingを実装した</p> + <ul> - <li>VNCServer 側が接続を切断した場合でもクライアントが正しく終了する様にした。</li> - <li>画面操作の許可を確認する authentication のポップアップが Root 側に表示されない様にした。</li> - <li>データの Blocking を行うことにより、無線接続での Multicast 対応を行えるようにした。</li> + <li>データの Blocking を行うことにより、無線接続での Multicast 対応を行えるようにした</li> </ul> </li> <li>今後の課題