# HG changeset patch # User e165729 # Date 1559112742 -32400 # Node ID b48db21c9d6628984b7723654f2b493e7b3241bf # Parent a36e5abf494d0f0700f2e98465468712af3018e6 comment out to diff -r a36e5abf494d -r b48db21c9d66 Slide/slide.html --- a/Slide/slide.html Wed May 29 15:09:45 2019 +0900 +++ b/Slide/slide.html Wed May 29 15:52:22 2019 +0900 @@ -166,7 +166,7 @@ @@ -175,7 +175,12 @@
-

マルチキャストについて

+

Multicastについて

+ @@ -184,6 +189,11 @@

解決手順

+
    +
  • +
  • +
  • +
@@ -213,139 +223,67 @@
  • FrameBufferは、メモリ上に置かれた画像データのこと
  • - - -
    - -
    - -

    TreeVNC の構造

    -
      -
    • TreeVNCは接続してきたクライアントをNodeとし、木構造状に管理する
    • -
    • ルートのノードをRoot Nodeと呼び、その下に新たなNodeを接続していく
    • -
    • Root Nodeが参照しているVNCServerからFrameBufferUpdateを取得し、各Nodeに送信する
    • -
    • 木構造状に接続することで、画像データのコピーを各Nodeに負担させることができる
    • -
    - -
    message
    - - - -
    + -

    木構造の再構成

    - - - - -
    - -
    - -

    画像データのエンコード方法

    - - - - -
    - -
    - -

    画像データのエンコード方法

    - - -
    message
    - +
    message
    -
    +## 木構造の再構成 +- Nodeが切断されたことを検知できなければ木構造が維持できない +- Root Nodeが木構造のネットワークトポロジーを管理しているため、Root NodeにNodeの切断を知らせる必要がある +- 切断検知には画像データが入っているMulticastQueueを使用 +- MulticastQueueから画像データが一定時間取得されず、Timeoutを検知した場合切断したと判断する -
    - -

    共有画面切り替え

    - +## 画像データのエンコード方法 +- TreeVNCではZRLEというエンコードタイプを元にした、ZRLEEというエンコードを用いて画像データを圧縮を行う +- ZRLEはZlibで圧縮されたデータとそのデータのバイト数がヘッダーとして送られる +- Zlibとはデータの可逆圧縮アルゴリズムが実装されているライブラリ -
    message
    +## 画像データのエンコード方法 +- ZRLEでは解凍時に必要な辞書データを書き出すことができない +- ZRLEEはRoot Nodeで受け取ったZRLEのデータを一度解凍し、辞書データを付与して再圧縮している + +
    message
    - +## 共有画面切り替え +- 従来のVNCでは、配信者が切り替わるたびに再起動、再接続を行う必要があった +- TreeVNCでは、画面上にあるShareScreenボタンを押すことで配信者の切り替えが実行できる +- ShareScreen実行後、Root Nodeに対しSERVER CHANGE REQUESTというメッセージが送信される +- メッセージを受け取ったRoot Nodeは配信を希望しているNodeのVNCサーバーと通信を行い、切り替え作業に入る -
    +
    message
    -
    - -

    有線接続との接続の違い

    - +## 有線接続との接続の違い +- 現状のTreeVNCでは画面配信のデータ量は多く、無線LAN接続を行うと画面配信の遅延が大きくなる +- WifiのMulticast機能を利用し、UpdateRectangleを一度だけ送信することで無線LAN接続でも十分に遅延が抑えられると考える +- HDや4kの画面更新には64MB程度となり、これを圧縮しつつwifiのMulticast paketの最大サイズ64KBに変換、送信する必要がある +- paket lossがあった場合、再送処理は複雑であると予想できるため、まずBlokingによる実験を行う +## RFBプロトコルのUpdateRectangleの構成 +- 1つのUpdateRectangleには複数のRectangleが格納されている +- RectangleはZlibで圧縮されたデータが指定された長さだけ格納されており、そのデータはさらに64x64 ByteのTileに分割されている + +## RFBプロトコルのUpdateRectangleの構成 +- 無線接続の場合、一度に送信できるデータ量が64KBしかないため、それに合わせて更新された部分のRectangleを分割する必要がある + - Phase0 行の途中から始まる部分 + - Phase1 行の最初から最後までの部分 + - Phase2 行の途中で終わる部分 + +
    message
    -
    - -
    - -

    RFBプロトコルのUpdateRectangleの構成

    - - - - -
    +## 木構造とマルチキャストの共存 +- ツリーに無線接続のNodeを加えてしまうと全体の配信遅延に繋がる +- 無線接続時のMulticastの実装を提案 +- Multicastならば、Serverからの送信は一度で済むため、ツリー構造の形成が必要ない +- 従って新しいNodeが無線接続であっても、有線接続のツリーの配信には影響が出ない -
    - -

    RFBプロトコルのUpdateRectangleの構成

    - - -
    message
    - - - -
    - -
    - -

    木構造とマルチキャストの共存

    - - -
    message
    +
    message
    +--> diff -r a36e5abf494d -r b48db21c9d66 Slide/slide.md --- a/Slide/slide.md Wed May 29 15:09:45 2019 +0900 +++ b/Slide/slide.md Wed May 29 15:52:22 2019 +0900 @@ -53,13 +53,19 @@ ## 本研究の概要 - 画面配信は送信するデータ量が多いため、TreeVNCでは無線接続の場合、画面配信の遅延が大きくなってしまう - 現在のTreeVNCのデータ転送方法だと、無線接続で送信するには大きすぎる -- 本研究ではマルチキャストを導入することで、Wifi環境下における画面配信の遅延対策の検討する +- 本研究ではMulticastを導入することで、Wifi環境下における画面配信の遅延対策の検討を行なった -## マルチキャストについて +## Multicastについて +- WifiのMulticast機能を利用することで無線LAN接続時でも画面遅延を軽減できると考える +- 配信PC画面の変更があった部分のみをマルチキャストで送信する +- wifiのMulticast Paketの最大サイズは64KBとなっているため、データの圧縮が必要 + ## 解決手順 - +- +- +- ## VNC - VNC(Virtual Network Computing)は、RFBプロトコルを用いてPCの遠隔操作を行うことを目的としたリモートデスクトップソフトウェア @@ -73,7 +79,7 @@ - 他人のPC画面が表示される側と、FrameBufferへの更新が行われる(自身のPC画面を送信する)側に分かれ、それぞれをRFBクライアント、RFBサーバと呼ぶ - FrameBufferは、メモリ上に置かれた画像データのこと -## TreeVNC の構造 + ## まとめ - WifiでMulticast paketを利用する手法についての考察を行なった diff -r a36e5abf494d -r b48db21c9d66 Slide/slide.pdf.html --- a/Slide/slide.pdf.html Wed May 29 15:09:45 2019 +0900 +++ b/Slide/slide.pdf.html Wed May 29 15:52:22 2019 +0900 @@ -150,7 +150,7 @@ @@ -159,7 +159,12 @@
    -

    マルチキャストについて

    +

    Multicastについて

    +
      +
    • WifiのMulticast機能を利用することで無線LAN接続時でも画面遅延を軽減できると考える
    • +
    • 配信PC画面の変更があった部分のみをマルチキャストで送信する
    • +
    • wifiのMulticast Paketの最大サイズは64KBとなっているため、データの圧縮が必要
    • +
    @@ -168,6 +173,11 @@

    解決手順

    +
      +
    • +
    • +
    • +
    @@ -197,139 +207,67 @@
  • FrameBufferは、メモリ上に置かれた画像データのこと
  • - - -
    - -
    - -

    TreeVNC の構造

    -
      -
    • TreeVNCは接続してきたクライアントをNodeとし、木構造状に管理する
    • -
    • ルートのノードをRoot Nodeと呼び、その下に新たなNodeを接続していく
    • -
    • Root Nodeが参照しているVNCServerからFrameBufferUpdateを取得し、各Nodeに送信する
    • -
    • 木構造状に接続することで、画像データのコピーを各Nodeに負担させることができる
    • -
    - -
    message
    - - - -
    + -

    木構造の再構成

    -
      -
    • Nodeが切断されたことを検知できなければ木構造が維持できない
    • -
    • Root Nodeが木構造のネットワークトポロジーを管理しているため、Root NodeにNodeの切断を知らせる必要がある
    • -
    • 切断検知には画像データが入っているMulticastQueueを使用
    • -
    • MulticastQueueから画像データが一定時間取得されず、Timeoutを検知した場合切断したと判断する
    • -
    - - - -
    - -
    - -

    画像データのエンコード方法

    -
      -
    • TreeVNCではZRLEというエンコードタイプを元にした、ZRLEEというエンコードを用いて画像データを圧縮を行う
    • -
    • ZRLEはZlibで圧縮されたデータとそのデータのバイト数がヘッダーとして送られる
    • -
    • Zlibとはデータの可逆圧縮アルゴリズムが実装されているライブラリ
    • -
    - - - -
    - -
    - -

    画像データのエンコード方法

    -
      -
    • ZRLEでは解凍時に必要な辞書データを書き出すことができない
    • -
    • ZRLEEはRoot Nodeで受け取ったZRLEのデータを一度解凍し、辞書データを付与して再圧縮している
    • -
    - -
    message
    - +
    message
    -
    +## 木構造の再構成 +- Nodeが切断されたことを検知できなければ木構造が維持できない +- Root Nodeが木構造のネットワークトポロジーを管理しているため、Root NodeにNodeの切断を知らせる必要がある +- 切断検知には画像データが入っているMulticastQueueを使用 +- MulticastQueueから画像データが一定時間取得されず、Timeoutを検知した場合切断したと判断する -
    - -

    共有画面切り替え

    -
      -
    • 従来のVNCでは、配信者が切り替わるたびに再起動、再接続を行う必要があった
    • -
    • TreeVNCでは、画面上にあるShareScreenボタンを押すことで配信者の切り替えが実行できる
    • -
    • ShareScreen実行後、Root Nodeに対しSERVER CHANGE REQUESTというメッセージが送信される
    • -
    • メッセージを受け取ったRoot Nodeは配信を希望しているNodeのVNCサーバーと通信を行い、切り替え作業に入る
    • -
    +## 画像データのエンコード方法 +- TreeVNCではZRLEというエンコードタイプを元にした、ZRLEEというエンコードを用いて画像データを圧縮を行う +- ZRLEはZlibで圧縮されたデータとそのデータのバイト数がヘッダーとして送られる +- Zlibとはデータの可逆圧縮アルゴリズムが実装されているライブラリ -
    message
    +## 画像データのエンコード方法 +- ZRLEでは解凍時に必要な辞書データを書き出すことができない +- ZRLEEはRoot Nodeで受け取ったZRLEのデータを一度解凍し、辞書データを付与して再圧縮している + +
    message
    - +## 共有画面切り替え +- 従来のVNCでは、配信者が切り替わるたびに再起動、再接続を行う必要があった +- TreeVNCでは、画面上にあるShareScreenボタンを押すことで配信者の切り替えが実行できる +- ShareScreen実行後、Root Nodeに対しSERVER CHANGE REQUESTというメッセージが送信される +- メッセージを受け取ったRoot Nodeは配信を希望しているNodeのVNCサーバーと通信を行い、切り替え作業に入る -
    +
    message
    -
    - -

    有線接続との接続の違い

    -
      -
    • 現状のTreeVNCでは画面配信のデータ量は多く、無線LAN接続を行うと画面配信の遅延が大きくなる
    • -
    • WifiのMulticast機能を利用し、UpdateRectangleを一度だけ送信することで無線LAN接続でも十分に遅延が抑えられると考える
    • -
    • HDや4kの画面更新には64MB程度となり、これを圧縮しつつwifiのMulticast paketの最大サイズ64KBに変換、送信する必要がある
    • -
    • paket lossがあった場合、再送処理は複雑であると予想できるため、まずBlokingによる実験を行う
    • -
    +## 有線接続との接続の違い +- 現状のTreeVNCでは画面配信のデータ量は多く、無線LAN接続を行うと画面配信の遅延が大きくなる +- WifiのMulticast機能を利用し、UpdateRectangleを一度だけ送信することで無線LAN接続でも十分に遅延が抑えられると考える +- HDや4kの画面更新には64MB程度となり、これを圧縮しつつwifiのMulticast paketの最大サイズ64KBに変換、送信する必要がある +- paket lossがあった場合、再送処理は複雑であると予想できるため、まずBlokingによる実験を行う +## RFBプロトコルのUpdateRectangleの構成 +- 1つのUpdateRectangleには複数のRectangleが格納されている +- RectangleはZlibで圧縮されたデータが指定された長さだけ格納されており、そのデータはさらに64x64 ByteのTileに分割されている + +## RFBプロトコルのUpdateRectangleの構成 +- 無線接続の場合、一度に送信できるデータ量が64KBしかないため、それに合わせて更新された部分のRectangleを分割する必要がある + - Phase0 行の途中から始まる部分 + - Phase1 行の最初から最後までの部分 + - Phase2 行の途中で終わる部分 + +
    message
    -
    - -
    - -

    RFBプロトコルのUpdateRectangleの構成

    -
      -
    • 1つのUpdateRectangleには複数のRectangleが格納されている
    • -
    • RectangleはZlibで圧縮されたデータが指定された長さだけ格納されており、そのデータはさらに64x64 ByteのTileに分割されている
    • -
    - - - -
    +## 木構造とマルチキャストの共存 +- ツリーに無線接続のNodeを加えてしまうと全体の配信遅延に繋がる +- 無線接続時のMulticastの実装を提案 +- Multicastならば、Serverからの送信は一度で済むため、ツリー構造の形成が必要ない +- 従って新しいNodeが無線接続であっても、有線接続のツリーの配信には影響が出ない -
    - -

    RFBプロトコルのUpdateRectangleの構成

    -
      -
    • 無線接続の場合、一度に送信できるデータ量が64KBしかないため、それに合わせて更新された部分のRectangleを分割する必要がある -
        -
      • Phase0 行の途中から始まる部分
      • -
      • Phase1 行の最初から最後までの部分
      • -
      • Phase2 行の途中で終わる部分
      • -
      -
    • -
    - -
    message
    - - - -
    - -
    - -

    木構造とマルチキャストの共存

    -
      -
    • ツリーに無線接続のNodeを加えてしまうと全体の配信遅延に繋がる
    • -
    • 無線接続時のMulticastの実装を提案
    • -
    • Multicastならば、Serverからの送信は一度で済むため、ツリー構造の形成が必要ない
    • -
    • 従って新しいNodeが無線接続であっても、有線接続のツリーの配信には影響が出ない
    • -
    - -
    message
    +
    message
    +-->