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

  • 谷成 雄

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

    目的と背景

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

    • 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%
  • 48台繋げる事によって、VNCに使われるCPUの使用率が100%になり、スループットが5分の1まで下がっている。

    • TreeVNCの設計

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

    • TreeVNCの設計

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

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

    通常のVNCの問題点

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

    • 今回の主な内容

    TreeVNCの設計

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

    木の構成手順

    		 requestHostName();
    プロキシに対してホストのアドレスを要求する関数。

    木の構成手順

    		 transferParentAddress();
    クライアントに接続先を教える関数。

    実際にクライアントにおくっているデータは
    parentAddress
    parentNum
    treeNum 　　　
    leaderFlag
    の４つである。
    リーダーは子供の中で一番若い番号の人がなる。
    リーダーフラグは木の再構成の際に使用する。

    木の構成手順

    		 connectAndAuthenticate();
    プロキシから受け取ったデータをもとに接続を開始する関数。

    木の構成手順

    		 新しいクライアントが来るたびに今まで説明した３つの関数を呼び出す。

    木の構成手順

    木の構成手順

    木の構成手順

    木の構成手順

    木の構成手順

    		 ここで接続先がクライアント１になっているがこれはプロキシ側で
    親の番号 = (自分の番号 - 1) / 親に対する子どもの数
    を計算してどの親に接続させれば良いかを決めてクライアントに報告している。
    このように番号で木を管理している。

    木の再構成手順

    		 クライアント１が落ちた時の再接続の処理についての説明。

    木の再構成手順

    		 lostHost();
    木を構成する際にリーダを決めたが、そのリーダだけが呼び出す関数。
    プロキシに対し落ちた親（クライアント１）の情報を報告する。

    木の再構成手順

    		 reportLastNode();
    ラストノードに対し落ちたクライアントの代わりをするように命令を出す。

    木の再構成手順

    		 connectAndAuthenticate();
    プロキシから受け取ったデータをもとに接続を開始する関数。
    この時クライアント６がクライアント１に変わる。

    木の再構成手順

    		 transferParentAddress();
    落ちた親の子供たちに対し新しい親のアドレスを報告する関数。

    木の再構成手順

    		 connectAndAuthenticate();
    プロキシから受け取ったデータをもとに接続を開始する関数。

    RFB protocol

  • Remote Frame Buffer Protocol :
    GUI操作によるリモートアクセス用の通信プロトコル。VNCで用いられている。
  • 1~5まではinitial seaquenceとなる。
  • 6以降は繰り返し行われる処理。画面のデータが転送されてくる。

    • 画像の更新(FramebufferUpdate)

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

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

    データの転送

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

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

    MulticastQueue

  • MulticastQueue:データを順序よく読み込ませるクラス
    • 次のデータがなければwaitする データがputされ次第読み込みを再開する

    MulticastQueueは、java.util.CountDownnLatchにより実装されている。

    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データは辞書を元にデータの解凍を行う
  • 辞書がなければデータを正しく解凍できない

    • ZRLEの問題

  • 辞書はZlibデータの最初に送られてくる。
  • もしも、ZRLEのデータを最初から送っているのなら、辞書も送ることができる。
  • データの途中から送ると辞書は送られず、正しく解凍を行うことができない。

    • 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

    • 質問