+
- 以下number-of-rectanglesの数だけ矩形のデータが続く
+ 以下number-of-rectanglesの数だけ矩形のデータが続く
-
+
バイト数 |
型 |
@@ -412,9 +435,13 @@
-
+
+
+
+
+ |
+
-
@@ -520,7 +547,7 @@
データ転送量
- クライアントが60台の時の通常のVNCと、2分木構成にしたTreeVNCの通信網への負荷の理論値を考える。
+ クライアントが60台とした時、通常のVNCと、2分木構成にしたTreeVNCの通信網への負荷の理論値を考える。
クライアントの数を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 array |
- zlibData |
+ ZlibData |
|
-
- 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と名付けた。
@@ -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使用率も跳ね上がった。
+
+
+
@@ -133,7 +145,7 @@
|
1台 |
- 20M |
+ 20M(最大速度) |
55% |
@@ -148,9 +160,15 @@
+ 通常のVNCの問題点
+ サーバへのCPU負荷が高い
+ 1本の通信網への負荷が高い
+
+
+
VNCの問題点の解決策
- クライアントを木構造で接続させる
+ クライアントを木構造で接続させるTreeVNC
@@ -194,7 +212,7 @@
-
+
|
通常のVNC |
@@ -202,7 +220,7 @@
最大負荷 |
- 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の通信網への負荷の理論値を考える。
クライアントの数を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 @@
-->
+ | | |