# HG changeset patch # User Nobuyasu Oshiro # Date 1315438869 -32400 # Node ID 7e05f4f580b7f4d6e346173cdef428bfb3dda88e # Parent c193ee47050dcd3949b6d6c107fe44259da23783 modify index.html diff -r c193ee47050d -r 7e05f4f580b7 OpenSourceConference/index.html --- a/OpenSourceConference/index.html Thu Sep 08 05:55:10 2011 +0900 +++ b/OpenSourceConference/index.html Thu Sep 08 08:41:09 2011 +0900 @@ -10,6 +10,10 @@ margin-right: auto; text-align: center; } +.textcenter { +text-align: center; +} + 2011/9/6 @@ -530,6 +534,11 @@
  • N = 60、 M = 1 となる。
  • 724 * 449 の画面分のデータ(0.8M)を送信するとする。
    • + + +
    +

    データ転送量

    +
  • @@ -542,9 +551,6 @@
    2.4M
    -
    - -
    @@ -552,51 +558,118 @@ -

    -
    TreeVNC
    - + + - +
    - - + + +

    クライアント:60台 TreeVNCは2分木でTreeを構成

    +     +
    + +
    +

    エンコード

    +
  • MacintoshでVNCを行うとZRLEを使うことができる。
    • +
  • データ量がRAWデータの約4分の1のデータ量ですむ。
    • +
  • TreeVNCではこのZRLEを扱っている。
    • -

    データ量の見積もり

    -
  • ZRLEエンコードの場合
    • -
  • 最初の4bitにどれだけのデータ量が送られてくるのかという情報が送られてくる。
    • +

    ZRLE

    +
  • ZRLE : Zlib Run-Length Encoding
    • + +
  • 最初の4バイトにはZlibのデータの長さが、続いてZlibのデータが送られてくる。
    • - +
    - + - - -
    バイト数
    型　　　[値]
    型　
    		 説明
    4 U32 length
    length U8 array zlibData
    - -
    + +
    +

    ZRLEの問題

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

    ZRLEE

    +
  • そこで、Top ProxyにZRLEのデータを再度圧縮し直すことで辞書を付けてもらうことにした。
    • + + 
    +Deflater nDeflater = deflater; // new Deflater();
+LinkedList out = new LinkedList();
+unzip(inflater, inputs, 0 , out, INFLATE_BUFSIZE);
+// dump32(inputs);
+int len2 = zip(nDeflater, out, 0, bufs);
+
    +     +
  • 一度再圧縮してしまえば後はどこからデータを流しても問題ない。
    • + + + + + +
    + + + +
    +
    + +
    +

    ZRLEE

    +
  • クライアント側は毎回新しい解凍器(Deflater)を使うようにする。
    • + 
    +	    if (rfb.updateRectEncoding==RfbProto.EncodingZRLEE) zrleInStream = null;
+	    if (zrleInStream == null)
+	    zrleInStream = new ZlibInStream();
+
    +
    + +
    +

    ZRLEの問題

    +
  • 解凍に必要な辞書を取り出すことができないため、ZRLEのデータはそのまま投げるだけでは正しく解凍されない。
    • +
  • そこで、VNC Serverへ接続するTop ProxyはZRLEで送られてきたデータを毎回新しく圧縮し直すという方法をとった。
    • +
  • 一度圧縮し直されたデータはそのまま流すことができる。よってクライアント側では圧縮し直す必要はない。
    • @@ -656,23 +729,6 @@
    -

    エンコードの問題　

    -
  • ZRLE : Zlib Run-Length Encoding

    • データをZlib圧縮扱うエンコーディング。 -
    Macintoshでもこのエンコードは使うことができる。 -
  • Rawエンコードより約1/8倍少ないデータ量ですむ。
    • -
  • 解凍器(Deflater)は辞書を持っていて、その辞書を元に解凍を行う。
    • -
  • この辞書を吐き出す(flush)する機能がJavaにはなかった。
    • -
    - -
    -

    ZRLEの問題

    -
  • 解凍に必要な辞書を取り出すことができないため、ZRLEのデータはそのまま投げるだけでは正しく解凍されない。
    • -
  • そこで、VNC Serverへ接続するTop ProxyはZRLEで送られてきたデータを毎回新しく圧縮し直すという方法をとった。
    • -
  • 一度圧縮し直されたデータはそのまま流すことができる。よってクライアント側では圧縮し直す必要はない。
    • -
  • このエンコードはZRLEE(Economy)として扱うことにした。
    • -
    - -

    TreeVNCの利点と欠点