# HG changeset patch # User Nobuyasu Oshiro # Date 1315591241 -32400 # Node ID d33d9d7770b2debe16c23cce461bda51fc85614a # Parent d91f1fc9c1231da1b4d3f0b8190cb44be5ffcf3b modify RemoteframebufferUpdate, ZRLEE diff -r d91f1fc9c123 -r d33d9d7770b2 presen/index.html --- a/presen/index.html Fri Sep 09 22:02:45 2011 +0900 +++ b/presen/index.html Sat Sep 10 03:00:41 2011 +0900 @@ -83,24 +83,35 @@

琉球大学 並列信頼研究室

- -
-

目的と背景

+

本日の内容

+
  • 友人と作ったJavaによる画面共有システム「TreeVNC」について
  • +
  • TreeVNCを作るにあたって学んだJavaでの並列プログラミングの仕方やVNCの話
  • +
    + +
    +

    TreeVNCの目的と背景

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

    VNCを用いての画面共有

    +

    VNCによる画面共有

  • 画面を共有する方法 -> VNC
  • VNC: Virtual Network Computing
    ネットワークを介してコンピュータを遠隔操作するプログラム
  • VNCのリモートPCの画面を写す機能を利用する。
  • +

    VNCを用いての画面共有

    +
  • まず、iMacで複数のPCからVNCをかけてみた。
  • +
  • -> 10台と繋ぐ前にVNCでの画面がカクカクに...
  • +
  • さらにCPU使用率も跳ね上がった。
  • +
    + +

    通常のVNCの問題点

    @@ -115,6 +126,7 @@
    +

    実際に測ってみた

    @@ -133,7 +145,7 @@ 1台 - 20M + 20M(最大速度) 55% @@ -148,9 +160,15 @@
    +

    通常のVNCの問題点

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

    VNCの問題点の解決策

    - クライアントを木構造で接続させる
    + クライアントを木構造で接続させるTreeVNC

    @@ -194,7 +212,7 @@

    - +
    @@ -202,7 +220,7 @@ - +
    通常のVNC
    最大負荷 N * データ量 (クライアントの数に比例) N*データ量 (クライアントの数に比例) (M+1) * データ量
    @@ -212,8 +230,9 @@

    TreeVNCの設計

    +
  • 木構造での接続
  • TreeVNCのクライアントは最初にTop Proxyに接続を行う。
  • -
  • データは木の下へと流れていく。
  • +
  • データは木の下へと流していくようにする。
  • tightVNC ViewerのJava版(ver 1.3)を元にTreeVNCの実装を行う。
  • @@ -221,7 +240,7 @@

    -

    発表内容

    +

    今回の主な内容

    • RFB Protocol
    • データ転送量
    • @@ -234,6 +253,23 @@

      RFB protocol

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

      画像の更新(FramebufferUpdate)

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

      VNC のシーケンス図

      -
      - - - - -
      - - - -
    • 1~5まではinitial seaquenceとなる。
    • -
    • 6以降は繰り返し行われる処理。画面のデータが転送されてくる。
    • -
      -
      -
      - -

      RFB Protocol

    • FramebufferUpdateRequest:
    • 画面に差分が発生したらサーバから教えて貰うためのリクエスト
    • - +
      +
      @@ -322,15 +341,19 @@
      + +
      -
    • このリクエストはTop Proxyだけが行う。
    • +
    • このリクエストはTop Proxyだけが行う。
    • RFB Protocol

      -
    • FramebufferUpdate: 画面の更新データ
    • - +
    • FramebufferUpdateRequest:画面の更新データ
    • + + - +
      @@ -358,11 +381,11 @@
      -
    • 以下number-of-rectanglesの数だけ矩形のデータが続く
    • +
    • 以下number-of-rectanglesの数だけ矩形のデータが続く
    • + +
      - +
      @@ -412,9 +435,13 @@
      バイト数
      型   
      - + +
      + +
      -
      @@ -520,7 +547,7 @@

      データ転送量

      -
    • クライアントが60台の時の通常のVNCと、2分木構成にしたTreeVNCの通信網への負荷の理論値を考える。
    • +
    • クライアントが60台とした時、通常のVNCと、2分木構成にしたTreeVNCの通信網への負荷の理論値を考える。
    • @@ -534,7 +561,7 @@

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

      -
    • N = 60、 M = 1 となる。
    • +
    • N = 60、 M = 2 、使用するエンコードはZRLEとする。
    • 724 * 449 の画面分のデータ(0.8M)を送信するとする。
    • @@ -576,7 +603,7 @@

      エンコード

      -
    • MacintoshでVNCを行うとZRLEを使うことができる。
    • +
    • MacintoshでZRLEを使ってVNCを行うことができる
    • データ量がRAWデータの約4分の1ですむ。
    • TreeVNCではこのZRLEを扱っている。
    • @@ -603,23 +630,25 @@
      length U8 arrayzlibDataZlibData
      - -
    • Zlibデータ
    • -
        -
      • Zlibデータは辞書を元にデータの解凍を行う
      • -
      -
    • 辞書がなければデータを正しく解凍できない
    • -
      +
    • VNCでZRLEを使う場合は単一のzrleストリームを使ってデータの解凍を行う。
    • +
    • 問題が発生
    • +

    ZRLEの問題

    +
  • Zlibデータは辞書を元にデータの解凍を行う
  • +
  • 辞書がなければデータを正しく解凍できない
  • +
    +
    +

    ZRLEの問題

  • 辞書はZlibデータの最初に送られてくる。
  • -
  • ZRLEのデータを最初から送ることができれば、辞書も送ることができる。
  • +
  • もしも、ZRLEのデータを最初から送っているのなら、辞書も送ることができる。
  • データの途中から送ると辞書は送られず、正しく解凍を行うことができない。
  • +
  • Zlibデータを解凍するjava.util.zip.Deflaterがエラーを吐く
  • @@ -644,7 +673,7 @@ int len2 = zip(nDeflater, out, 0, bufs); -
  • このエンコードはZRLEEと名付けた。
  • +
  • この圧縮し直したデータはZRLEEと名付けた。
  • - + @@ -148,9 +160,15 @@
    +

    通常のVNCの問題点

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

    VNCの問題点の解決策

    - クライアントを木構造で接続させる
    + クライアントを木構造で接続させるTreeVNC

    @@ -194,7 +212,7 @@

    @@ -727,8 +756,9 @@

    圧縮したデータの転送

  • 一度ZRLEEに圧縮してしまえば、データはそのまま流すことができる。
  • +
  • -> 気にするのはスループットだけでいい。
  • また、データの転送は複数いる子へ並列に行われる。
  • -

    + 

  • MulticastQueueクラスを用いてデータの転送を行った。
  • diff -r d91f1fc9c123 -r d33d9d7770b2 presen/index.html~ --- a/presen/index.html~ Fri Sep 09 22:02:45 2011 +0900 +++ b/presen/index.html~ Sat Sep 10 03:00:41 2011 +0900 @@ -83,24 +83,35 @@

    琉球大学 並列信頼研究室

    - -
    -

    目的と背景

    +

    本日の内容

    +
  • 友人と作ったJavaによる画面共有システム「TreeVNC」について
  • +
  • TreeVNCを作るにあたって学んだJavaでの並列プログラミングの仕方やVNCの話
  • +
    + +
    +

    TreeVNCの目的と背景

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

    VNCを用いての画面共有

    +

    VNCによる画面共有

  • 画面を共有する方法 -> VNC
  • VNC: Virtual Network Computing
    ネットワークを介してコンピュータを遠隔操作するプログラム
  • VNCのリモートPCの画面を写す機能を利用する。
  • +

    VNCを用いての画面共有

    +
  • まず、iMacで複数のPCからVNCをかけてみた。
  • +
  • -> 10台と繋ぐ前にVNCでの画面がカクカクに...
  • +
  • さらにCPU使用率も跳ね上がった。
  • +
    + +

    通常のVNCの問題点

    @@ -115,6 +126,7 @@
    +

    実際に測ってみた

    @@ -133,7 +145,7 @@
    1台20M20M(最大速度) 55%
    - +
    @@ -202,7 +220,7 @@ - +
    通常のVNC
    最大負荷 N * データ量 (クライアントの数に比例) N*データ量 (クライアントの数に比例) (M+1) * データ量
    @@ -212,8 +230,9 @@

    TreeVNCの設計

    +
  • 木構造での接続
  • TreeVNCのクライアントは最初にTop Proxyに接続を行う。
  • -
  • データは木の下へと流れていく。
  • +
  • データは木の下へと流していくようにする。
  • tightVNC ViewerのJava版(ver 1.3)を元にTreeVNCの実装を行う。
  • @@ -221,7 +240,7 @@

    -

    発表内容

    +

    今回の主な内容

    • RFB Protocol
    • データ転送量
    • @@ -234,6 +253,23 @@

      RFB protocol

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

      画像の更新(FramebufferUpdate)

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

      VNC のシーケンス図

      -
      - - - - -
      - - - -
    • 1~5まではinitial seaquenceとなる。
    • -
    • 6以降は繰り返し行われる処理。画面のデータが転送されてくる。
    • -
      -
      -
      - -

      RFB Protocol

    • FramebufferUpdateRequest:
    • 画面に差分が発生したらサーバから教えて貰うためのリクエスト
    • @@ -520,7 +539,7 @@

      データ転送量

      -
    • クライアントが60台の時の通常のVNCと、2分木構成にしたTreeVNCの通信網への負荷の理論値を考える。
    • +
    • クライアントが60台とした時、通常のVNCと、2分木構成にしたTreeVNCの通信網への負荷の理論値を考える。
    • @@ -534,7 +553,7 @@

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

      -
    • N = 60、 M = 1 となる。
    • +
    • N = 60、 M = 1 、使用するエンコードはZRLEとする。
    • 724 * 449 の画面分のデータ(0.8M)を送信するとする。
    • @@ -644,7 +663,7 @@ int len2 = zip(nDeflater, out, 0, bufs);
      -
    • このエンコードはZRLEEと名付けた。
    • +
    • この圧縮し直したデータはZRLEEと名付けた。
    • @@ -727,8 +746,9 @@

      圧縮したデータの転送

    • 一度ZRLEEに圧縮してしまえば、データはそのまま流すことができる。
    • +
    • -> 気にするのはスループットだけでいい。
    • また、データの転送は複数いる子へ並列に行われる。
    • -

      + 

    • MulticastQueueクラスを用いてデータの転送を行った。
    • @@ -1239,7 +1259,7 @@
    • 今回のTreeVNCは大学の授業「programming4」で作り始めた。
    • Javaは基本知識だけ、VNCの仕組みについては全く知らない状態からのスタートあった。
    • 木の再構成、MulticastやZRLEの問題にも出会ったがなんとかクリアすることができた。
    • -
    • Javaでの分散プログラミングは考えていたよりも簡単であった。
    • +
    • Javaでの分散プログラミングは考えていたよりも楽であった。
    • @@ -1255,6 +1275,7 @@
      --> +