Mercurial > hg > Papers > 2020 > riono-thesis
view Slide/slide.md @ 37:f7a79686256d default tip
update mid
author | riono <e165729@ie.u-ryukyu.ac.jp> |
---|---|
date | Mon, 17 Feb 2020 00:04:06 +0900 |
parents | a5e11f973269 |
children |
line wrap: on
line source
title: 画面配信システム TreeVNC のマルチキャストの導入 author: Ryo Yasuda, Shinji Kono profile: 並列信頼研 lang: Japanese code-engine: coderay <!-- <\!-- slideshow の command -\-> --> <!-- slide.htmlでは通常キーでのコマンドが存在している --> <!-- p,a,s : スライドを自動送り(1,2...) --> <!-- : スライドを逆方向に自動送り(...,2,1) --> <!-- n : Page数を on/off --> <!-- f : 右下ロゴの on/off --> <!-- t : slide.html.pdf に変更 --> <!-- c : 右下スライド移動用UIの on/off --> <!-- d : ロゴ部分の選択…? --> <!-- [URL](http://~~~) --> <!-- [FILE](file:///Users/ryokka/~~~) --> <!-- slideshow build スライド.md -t s6cr --> <!-- ## 目次 - **TreeVNC の概要** - **基本概念** - **構造** - 研究内容 - TreeVNC の改良 - 送信データの Blocking --> ## 画面配信システムの活用 - 講義やゼミではプロジェクタを使用して、先生が用意した資料を見ることが多い。その際接続不良など、物理的アクシデントが起きる恐れがある - 画面配信システムで代用する場合がある。画面配信システムのとしてはAppleTVやUstreamなどが挙げられる - AppleTVは画面共有先がTVに限定されている - Ustreamは画面の切り替えを行うことができない <center><img src="./fig/AppleTVRogo.svg " alt="message" width="200" height="200"> <img src="./fig/UstreamRogo.svg" alt="message" width="200" height="150"></center> ## 画面配信システムの活用 - 画面配信システムTreeVNCは、自身のPC画面を他者のPCと共有できるソフトウェアである - javaで書かれているためOSに依存せず、物理的な制限なしに使用可能 - TreeVNCを使用することで、参加者は手元のPCを使用しながら講義を受ける事が可能になる。切り替えの際も、ボタン一つで共有する画面の切替を可能としている ## TreeVNCの講義等での活用 - 講義では先生のPC画面を手元のPCで見ることで、コマンドを手元で打ち間違えや、メモを取る際にPCのみに集中を向けることができるようになった - ゼミにおいてもコードをつなげるために移動する必要がなく、各自の席で発表者の画面を見ることができる - 以上のようにTreeVNCは従来のプロジェクタなどよりも利便性が高い ## VNC - VNC(Virtual Network Computing)は、RFB(Remote Frame Buffer)プロトコルを用いてPCの遠隔操作を行うことを目的としたリモートデスクトップソフトウェア - サーバー側とクライアント側に分かれており、起動したサーバーにクライアントが接続することで遠隔操作を可能にしている - 全てのNodeが一台のサーバーに接続するため負担が大きい <center><img src="./fig/vnc-crop.svg" alt="message" width="450" height="350"></center> ## TreeVNCとは - TreeVNCは本研究室で開発している画面配信システム - 木構造の接続方式によりNode間で画像データのやりとりを行う - 各ノードが2回ずつ画像データをコピーすることで配信側の負荷を分散し、大人数での画面配信が可能 <center><img src="./fig/treevnc-crop.svg" alt="message" width="450" height="350"></center> ## 本研究の概要 - 画面配信は送信するデータ量が多いため、TreeVNCでは無線接続の場合、画面配信の遅延が大きくなってしまう - 現在のTreeVNCのデータ転送方法だと、無線接続で送信するには大きすぎる - 本研究ではMulticastを導入することで、Wifi環境下における画面配信の遅延対策の検討を行なった ## TreeVNCの画面配信方法 - RFB (Remote Frame Buffer) プロトコルを利用し、自身の画面をネットワークを通じて送信し他者の画面に表示する - 他人のPC画面が表示される側と、FrameBufferへの更新が行われる(自身のPC画面を送信する)側に分かれ、それぞれをRFBクライアント、RFBサーバと呼ぶ - FrameBufferは、メモリ上に置かれた画像データのこと - RFBクライアントに送信するデータは画面全てではなく、変更があった部分のFrameBufferを送る ## Multicastによる画面配信 - 配信PC画面の変更があった部分のみをUpdateRectangleとしてマルチキャストで一度のみ送信する - RFBプロトコルでは画像データをRectangleで送信しているため、UpdateRectangleには複数のRectangleが入るような構成をとる <center><img src="./fig/UpdateRectangleStruct.svg" alt="message" width="450" height="350"></center> ## Multicastの問題点 - wifiのMulticast Paketの最大サイズは64KBである - HDや4Kの画面を更新するためのサイズは大きい - 4Kの場合8MB x 8Byteで64MB - 送信データの圧縮と64KB毎のパケット変換が必要 ## RFBプロトコルのエンコードタイプ - ZRLEとはRFBプロトコルでサポートされているエンコードタイプの1つ - zlib圧縮、タイリング、run lengthエンコードを組み合わせている - 解凍に必要な辞書を書き出すことができないため、途中からデータを受け取ると正確に解凍できなくなる <center><img src="./fig/ZlibTiling.svg" alt="message" width="550" height="450"></center> ## TreeVNCの画像データ圧縮方法 - ZRLEを改変したZRLEEを使用している - 辞書の書き出しを行えるようにし、データを途中から受け取っても解凍することが可能 - ZRLEを一度解凍し、辞書を書き出して再圧縮を行う - zlibは適当なタイミングで圧縮を書き出し(flush)を行う必要がある - zlibのAPIを用いて、適当なタイミングでflushを行なっている - 1tileずつflushしてしまうと圧縮率を下げてしまう可能性がある <center><img src="./fig/EncodeZRLEE.svg" alt="message" width="550" height="450"></center> ## Blockingの考察 - 64KBのパケットに収めるため、ZRLEEで圧縮する前にBlockingを行い、Rectangleの再構成を行う - ZRLEを解凍したデータのRectangleは以下のような状況になっていると考えられ、Phaseで区別する - 行の途中から行の最後まで Phase0 - 行の最初から最後まで Phase1 - 行の最初から行の途中まで Phase2 <center><img src="./fig/FrameUpdateRectangleColor.svg" alt="message" width="500" height="400"></center> ## Blockingの考察 - 最大3つのRectangleの再構成を行いつつ、ZRLEEで変換を行いパケットの構成をする - UpdateRectangleには3つのRectangleが入る <center><img src="./fig/FrameUpdateRectangleColor.svg" alt="message" width="500" height="400"></center> ## paket lossする可能性 - wifiのMulticast paketは確実に送信されることが保証されておらず、paket lossする可能性がある - その対策としては以下の2つが取れる - 何もしない、定期的に全画面のデータが送信されるため問題ない考える - 再送要求を行う、処理が複雑であることが予想される - 現状では何もせず、全画面のデータの送信を待つ方式でも十分実用に耐えると考える <!-- ## TreeVNC の構造 - TreeVNCは接続してきたクライアントをNodeとし、木構造状に管理する - ルートのノードをRoot Nodeと呼び、その下に新たなNodeを接続していく - Root Nodeが参照しているVNCServerからFrameBufferUpdateを取得し、各Nodeに送信する - 木構造状に接続することで、画像データのコピーを各Nodeに負担させることができる <center><img src="./fig/treevnc-crop.svg" alt="message" width="450" height="350"></center> ## 木構造の再構成 - Nodeが切断されたことを検知できなければ木構造が維持できない - Root Nodeが木構造のネットワークトポロジーを管理しているため、Root NodeにNodeの切断を知らせる必要がある - 切断検知には画像データが入っているMulticastQueueを使用 - MulticastQueueから画像データが一定時間取得されず、Timeoutを検知した場合切断したと判断する ## 画像データのエンコード方法 - TreeVNCではZRLEというエンコードタイプを元にした、ZRLEEというエンコードを用いて画像データを圧縮を行う - ZRLEはZlibで圧縮されたデータとそのデータのバイト数がヘッダーとして送られる - Zlibとはデータの可逆圧縮アルゴリズムが実装されているライブラリ ## 画像データのエンコード方法 - ZRLEでは解凍時に必要な辞書データを書き出すことができない - ZRLEEはRoot Nodeで受け取ったZRLEのデータを一度解凍し、辞書データを付与して再圧縮している <center><img src="./fig/EncodeZRLEE.svg" alt="message" width="550" height="450"></center> ## 共有画面切り替え - 従来のVNCでは、配信者が切り替わるたびに再起動、再接続を行う必要があった - TreeVNCでは、画面上にあるShareScreenボタンを押すことで配信者の切り替えが実行できる - ShareScreen実行後、Root Nodeに対しSERVER CHANGE REQUESTというメッセージが送信される - メッセージを受け取ったRoot Nodeは配信を希望しているNodeのVNCサーバーと通信を行い、切り替え作業に入る <center><img src="./fig/ShareScreenSS.svg" alt="message" width="400" height="300"></center> ## 有線接続との接続の違い - 現状の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 行の途中で終わる部分 <center><img src="./fig/FrameUpdateRectangleColor.svg" alt="message" width="550" height="450"></center> ## 木構造とマルチキャストの共存 - ツリーに無線接続のNodeを加えてしまうと全体の配信遅延に繋がる - 無線接続時のMulticastの実装を提案 - Multicastならば、Serverからの送信は一度で済むため、ツリー構造の形成が必要ない - 従って新しいNodeが無線接続であっても、有線接続のツリーの配信には影響が出ない <center><img src="./fig/interface-crop.svg" alt="message" width="500" height="450"></center> --> ## まとめ - WifiでMulticast paketを利用する手法についての考察を行なった - Wifiの速度とMulticastの信頼性が高ければ実用的である可能性がある - Blockingは実装中、再圧縮の時間は実用的な時間で済むと予想されている - 今後の課題 - Blockingの実装 - WifiのMulticast paket lossは接続環境や状況に依存すると思われるためさらなる実験が必要 - Node接続じの有線接続と無線接続の判断、区別処理の実装