Java による授業向け画面共有システムの設計と実装

  • 谷成 雄

    • 琉球大学 並列信頼研究室

    目的と背景

  • 大学の講義中、スクリーンに映されている画面は後ろの席程見えずらい。
  • その問題を手元のPCにも写せるようにすることで解決しようと考えた。
  • 60人以上での画面共有を行うシステムを目標とする。

    • VNCによる画面共有

  • 今回、VNCを用いて画面共有システムを作成する。
  • VNC: Virtual Network Computing
    ネットワークを介してコンピュータを遠隔操作するプログラム
  • VNC用いた授業用画面共有システムTreeVNCの設計と実装を行った。

    • 通常のVNCの問題点
  • VNC Serverの負荷が重い。
  • Server側の通信網1本への通信負荷が高い。
    		•

    通常のVNCの問題点

  • 1台と48台でVNCをかけた時のスループットとサーバ側のCPU使用率

    • スループット(単位:Byte) CPU使用率
    1台 20M(VNCでの最大速度) 55%
    48台 4M(1台あたり) 100%
  • VNCに使われるCPUの使用率が100%になり、スループットが5分の1まで下がっている。

    • 通常のVNCの問題点

  • サーバへのCPU負荷が高い
  • 1本の通信網への負荷が高い

    • TreeVNCの設計

  • 木構造での接続
  • クライアントの管理を行うTop Proxyを置く。
  • データは木の下へと流していくようにする。
    		•

    木の構成手順

    		 　２分木の場合の木の構成について説明する。
    クライアントは一旦Top Proxyに接続して、自分の接続先をProxyから取得する。

    木の構成手順

    		 親を決定する方法はTop Proxyで
    parentNumber = (myNumber - 1) / treeBranch
     を計算してクライアントにどの親に接続すればよいかを知らせる。

    木の構成手順

    		 親を決定する方法はTop Proxyで
    parentNumber = (myNumber - 1) / treeBranch
     を計算してクライアントにどの親に接続すればよいかを知らせる。

    木の構成手順

    		 親を決定する方法はTop Proxyで
    parentNumber = (myNumber - 1) / treeBranch
     を計算してクライアントにどの親に接続すればよいかを知らせる。

    木の再構成手順

    		 クライアント１が落ちたときの説明
    クライアント１が落ちたとき子供のリーダー(クライアント３)がTop Proxyに親が落ちたことを報告する。
    Top Proxyからラストノードに対して、落ちたノードの代わりをするように命令が行く。

    木の再構成手順

    		 命令を受けたラストノードが落ちたノードの代わりとなる。
    子供たちが新しい親に対して接続を行う。

    TreeVNCの設計

    通常のVNC TreeVNC
  • クライアントが増えてもかかる負荷一定。
  • 通信網1本に対する負荷が減り、安定した通信ができる(有線)。

    • TreeVNCの設計

    通常のVNC TreeVNC
    通常のVNC TreeVNC
    通信量 N*データ量 (クライアントの数に比例) (M+1) * データ量

    クライアントの数をN、木構造の子供の数をMとする

    画像の更新(FramebufferUpdate)

  • 転送される画面(フレームバッファ)のデータは変更があった部分(差分)だけが矩形単位で送られる。

    • 赤枠 で囲まれている矩形のデータだけが送られてくる。

    データの転送

  • クライアントから接続されるとsenderスレッドが作られる。
  • senderスレッドによりデータの転送は並列に行われる。
    • 　

  • MulticastQueueクラスを用いた並列な転送を行った。
    • 　　　

    MulticastQueue

  • クライアントは、自分のペースでデータを読み込みたい。
  • TreeVNCではVNCサーバとの接続はこのZRLEを扱う。

    • MulticastQueue

  • putでデータの入力
  • pollでデータの取り出し
  • Proxyは常に最新のデータの参照を渡す
    		•
  • クライアントは最新のデータから読み込み始める。
    		•

    MulticastQueueの問題点

  • クライアントがデータを読み込まない時...
  • 読み込まれないデータはProxyのメモリに残り続ける。

    • MulticastQueueの問題点

  • TimeOut(TO)スレッドを走らせ、最新のデータから取得できるようする。
  • どこからも参照されないデータはProxyのメモリから削除される。

    • エンコード

  • MAC OS XではZRLEを使ってVNCを行うことができる
  • ZRLEはデータ量がRAWデータの約4分の1ですむ。
  • TreeVNCではVNCサーバとの接続はこのZRLEを扱う。

    • ZRLE

  • ZRLE : Zlib Run-Length Encoding
  • 最初の4バイトにはZlibのデータの長さが、続いてZlibのデータが送られてくる。
    • バイト数 
    型　
    		 説明
    4 U32 length
    length U8 array ZlibData
  • Zlibデータは辞書を元にデータの解凍を行う
  • 辞書がなければデータを正しく解凍できない

    • ZRLEE

  • そこで、ProxyがZRLEを使ってデータを受け取り圧縮し直して木の下へ流していくことにした。
  • この圧縮し直したデータはZRLEEと名付けた。

    • ZRLEEの疑問点

  • ZRLEEには毎回辞書が付与されている。

  • ZRLEに比べるとデータ量は増えないのか...?
  • -> ZRLEと比較してみるとデータ量は少なくなった。

    • ZRLEEのデータ量

    1920*1080の描画にかかったデータ量

    ZRLE ZRLEE
    データ量 3.4M 3.2M
  • ZRLEよりデータ量が多くなるどころか少ない。
  • 原因

    • データ転送量

    矩形の大きさと描画に必要なデータ量(単位:Byte)

    矩形の大きさ \ エンコード RAW ZRLE
    724 * 449 1.3M 0.8M
    1920 * 64 0.5M 0.15M
    1920 * 1080 8.2M 3.4M


    RAW、ZRLE、ZRLEEエンコードのデータ量の比較

    既存のプログラムとの比較

  • VNC Reflector

    • 質問タイム