Mercurial > hg > Papers > 2012 > yuu-thesis
annotate paper/chapter4.tex @ 12:53afd895a367
change chapter4.tex
author | Yu Taninari <e085734@ie.u-ryukyu.ac.jp> |
---|---|
date | Thu, 23 Feb 2012 22:11:54 +0900 |
parents | 92a06963b6a9 |
children | 6fd4463ca136 |
rev | line source |
---|---|
7 | 1 \chapter{TreeVNCの設計} |
2 | 2 \label{chap:introduction} |
3 \pagenumbering{arabic} | |
4 | |
5 \section{BroadCast} | |
6 後で書く | |
7 \section{TreeVNCの設計方針} | |
3 | 8 まず、多人数が参加している授業でVNCを使う場合に起こる問題は、最初で述べたように、一つのコンピュータに多人数が繋がり、 |
9 処理性能が大幅に落ちてしまうところが問題である。 | |
10 | |
11 この問題を解決する為に、クライアント同士を接続させ、画面描画のデータを受け取ったクライアントが次のクライアントに | |
12 データを流すという方法で画面共有を行う方法を考えた。 | |
13 画面共有を行っているクライアントが一種のVNCサーバ自体にもなる。 | |
14 | |
2 | 15 また、クライアント同士の接続はツリー構造で行うことで管理がしやすくなると考えた。 |
3 | 16 クライアント同士の接続の管理はツリーの一番上にいるPC(Top)で行い(図を入れたい)、このTopだけがVNCサーバへ接続を行うようにする。 |
17 | |
18 今回作成したTreeVNCは、上記の実装でツリー状にクライアントを接続していくように実装を行い画面の共有だけを行うように実装した。 | |
19 | |
20 TreeVNCはTightVNCのjava版のビューアを元に作成を行った。実装の細かい内容は以下で説明する。TreeVNCはTightVNCのjava版のビューアを元に作成を行った。 | |
21 | |
22 | |
12 | 23 \newpage |
24 \section{木の生成} | |
25 今回は、ホストに対しクライアントがツリー状に繋がっていくように実装した。ツリー\\ | |
26 の構成は以下の手順で行う。 | |
27 \begin{enumerate} | |
28 \item クライアントが接続する際、ホストに接続をしているプロキシ(今後このプロ\\ | |
29 キシのことをTopと記述する)に接続する。 | |
30 \item Topはクライアントにどこに接続すれば良いかを知らせる。 | |
31 \item クライアントはTopから指定されたノードに接続を行う。 | |
32 \end{enumerate} | |
33 \subsection{Topの仕事} | |
34 Topはjava.util.LinkedListでクライアントの情報を保持している。 | |
35 | |
36 TopはtreeBranch(木の分木数)を定数で持っていて | |
37 クライアントが接続してくるごとにcounterをインクリメントしていき | |
38 LinkedListの(counter - 1)/treeBranche番目に入っている親の情報を | |
39 接続してきたクライアントに教えることで木を構成することができる。 | |
40 \newpage | |
41 \section{木の再構成} | |
42 \newpage | |
43 \section{クライアントとの通信} | |
44 TreeVNCは、受け取った画面の描画データをそのまま自分に繋がっている次のクライアン\ | |
45 トに送信する。 | |
46 描画データを受け取ったクライントはまた次のクライアントへデータをそのまま送信す\\ | |
47 る。 | |
48 内部では、まず受け取った描画データの読み込みを先に行いBytebufferでコピーを行う\\ | |
49 。 | |
50 次にクライアントへの送信と自身のビューアへの描画を並列に行う。 | |
51 | |
52 \subsection{FramebufferrUpdate} | |
53 RFB プロトコルでの画面の描画の更新は、FramebufferUpdateで行われる。 | |
54 FramebufferUpdateを受け取ることで画面の再描画が行われる。 | |
55 FrameBufferUpdateでは、メッセージタイプと画面の矩形の数がまず送られ、 | |
56 次にx座標、y座標、横幅、縦幅、エンコードのタイプ、描画データが矩形の数だけ送ら\\ | |
57 れてくる。 | |
58 描画データはエンコードのタイプに従った方法で送られてくる。 | |
59 | |
3 | 60 \subsection{MulticastQueue} |
61 画面が更新された際に更新をクライアントに伝えなければならない。ノードが多数ある場合、一人一人に更新を知らせるのではなく、同時に画面の更新を知らせたい。 | |
62 同時に更新を知らせるために、CountDownLatchを用いてMultiCastQueueを作成した。 | |
63 | |
64 CountDownLatch一回CountDownされたときに待機しているスレッドを解放するように宣言する。更新情報が来るまでawaitを用いてスレッドを待機させる。更新情報が来たときCountDownを行う。すると、スレッドが開放されるので同時に更新情報を参照することができる。 | |
65 \newpage | |
2 | 66 |
3 | 67 \begin{figure}[tb] |
68 \begin{center} | |
69 \includegraphics[scale = 0.5]{fig/multicastqueue.eps} | |
70 \end{center} | |
71 \caption{ | |
72 クライアントへは並列にデータを送信する。 | |
73 } | |
74 \label{figure:splaying} | |
75 \end{figure} | |
76 | |
77 \subsection{TimeOut} | |
78 MultiCastQueueを使ってのデータの取得には問題が発生した。 | |
79 それは、接続してきたクライアントがデータを取得しない状況、例えばサスペンド状態になったときにTopのメモリの中にデータが残り続けるというものである。 | |
80 メモリに残り続けたデータはやがてメモリオーバーフローを引き起こしてしまうのである。その様子を図2.2に示す。 | |
81 | |
82 \begin{figure}[!htbp] | |
83 \begin{center} | |
84 \includegraphics[scale = 0.5]{fig/TimeOut2.eps} | |
85 \end{center} | |
86 \caption{ | |
87 クライアントサスペンド時のTopのメモリの様子。 | |
88 データが残り続けメモリを圧迫してしまう。 | |
89 } | |
90 \label{figure:splaying} | |
91 \end{figure} | |
92 | |
93 そこで、ある一定の時間がたつと代わりにデータを取得してくれるTimeOut用のスレッドを作成した。 | |
94 TimeOutスレッドはサスペンドしているクライアントの代わりにデータを取得する。 | |
95 | |
96 \begin{figure}[!htbp] | |
97 \begin{center} | |
98 \includegraphics[scale = 0.5]{fig/TimeOut3.eps} | |
99 \end{center} | |
100 \caption{TimeOutが代わりにデータを取得する} | |
101 \label{figure:splaying} | |
102 \end{figure} | |
103 | |
104 TimeOutスレッドがクライアントの代わりにデータを取得することで、MulticastQueueの中からデータが削除されTopのメモリを圧迫することがなくなった。 | |
105 | |
106 \section{圧縮の問題} | |
107 VNCで扱うRFB プロトコルには、使えるエンコーディングのタイプの1つとしてZRLE(Zlib Run-Length Encoding)がある。 | |
108 ZRLEはZlibで圧縮されたデータとそのデータのバイト数がヘッダーとして付けられ送られてくる。 | |
109 Zlibはフリーのデータ圧縮及び解凍を行うライブラリである。 | |
110 可逆圧縮アルゴリズムの圧縮と解凍が行えるjava.util.zip.deflaterとjava.util.zip.inflaterを実装している。 | |
111 | |
112 \subsection{java.util.zip.deflaterの実装の問題} | |
113 Zlib圧縮は辞書を持っていて、その辞書に登録されているデータを元に解凍が行われる。 | |
114 しかし、java.util.zip.deflaterは現在持っている辞書を書き出すこと(flush)ができないことが分かった。 | |
115 辞書を書きだすことができない為、Zlib圧縮されたデータを途中から受け取ってもデータが正しく解凍を行うことができない。 | |
116 %元々のZlibの規約にはこの辞書をflushする機能があったがJavaには実装されていなかった。 | |
117 | |
118 \subsection{ZRLEE} | |
119 そこで、TopがZRLEで受け取ったデータをunzipし、データをzipし直して最後にfinish() | |
120 をいれることで初めからデータを読んでいなくても解凍を行えるようにした(毎回新しい辞書を使うようにした)。 | |
121 このエンコードはZRLEEエンコードと定義した。 | |
122 一度ZRLEEエンコードに変換してしまえば、そのデータをそのまま流すだけで良い。 | |
123 よって変換はTopが行う一回だけですむ。 | |
124 ただし、deflater,inflaterでは前回までの通信で得た辞書をクリアしないといけないため、 | |
125 Topとクライアント側では毎回新しく作る必要がある(クライアント側はinflaterだけ)。 | |
126 また、ZRLEEはクライアント側が対応していなければならないという問題がある。 | |
127 | |
11 | 128 |
8 | 129 \subsubsection{ZRLEとZRLEEのデータ圧縮率の比較} |
130 RAW,ZRLE,ZRLEEのデータ量の比較を行った。 | |
131 図6は1920 * 1080の画面の全描画にかかるデータ量を測った結果を示した図である。 | |
132 ZRLEEの方がデータ量が少なくですんでいる。 | |
133 これは、ZRLE(Zlib)が初めに送られた辞書を用いての解凍が余り有効的に働いていない | |
134 場合があるからだと思われる。 | |
135 つまりVNCの場合はZRLEEの様に毎回辞書のデータを付加させて送ってもデータ量に差が | |
136 でない可能性があることが分かった。 | |
137 | |
138 | |
139 \begin{figure}[!htbp] | |
140 \begin{center} | |
141 \includegraphics[scale = 0.5]{fig/compare_encoding.eps} | |
142 \end{center} | |
143 \caption{ | |
144 RAW,ZRLE,ZRLEEによる1画面(1920*1080)描画にかかるデータ量。 | |
145 x軸はピクセル数、y軸はバイト数を表している。 | |
146 } | |
147 \label{figure:splaying} | |
148 \end{figure} | |
149 | |
10
d18e410d728a
add files and change chapter4.tex
Yu Taninari <e085734@ie.u-ryukyu.ac.jp>
parents:
3
diff
changeset
|
150 |
8 | 151 \newpage |
152 | |
11 | 153 |
2 | 154 \section{UserInterface} |
8 | 155 \subsection{プロキシの検索} |
156 TreeVNCはクライアントが起動した際にBroadcastをしようして、 | |
157 同じセグメント内にプロキシが起動しているかを調べる。 | |
158 プロキシはクライアントからBroadcastのリクエストが飛んでくると、 | |
159 ソケットを張ってクライアントに自分の情報を教える。 | |
160 \subsection{TreeVNCの使い方} | |
161 今回作成したTreeVNCはクライアントが使いやすいように設計を行った。 | |
162 TreeVNCはまずプロキシを起動させる事が必要である。 | |
163 プロキシを始動するには-pオプションを指定してやる事で | |
164 localhostに対してVNCをかける事ができる。 | |
2 | 165 |
11 | 166 |
8 | 167 別のコンピュータの画面共有を行いたい場合は-pオプションを指定してやるか |
168 、第一引数にIpAddress,第に引数にportを指定してやる事で別のコンピュータの | |
169 画面共有も行う事ができる。 | |
170 | |
171 クライアントは引数なしで実行すると(ダブルクリックで実行できる) | |
172 現在つなぐ事のできるプロキシの一覧が表示されるので、選択してつなぐ事ができる。 | |
173 | |
174 しかし、Broadcastを使用してプロキシの検索を行っているので、 | |
175 別セグメントで起動しているプロキシを見つける事ができない。 | |
176 そこで、TreeVNCを起動する際に-cオプションを付けてやる事で、 | |
177 アドレス入力欄が表示され、そこに接続したいプロキシのアドレスを | |
178 入力する事で、別セグメントのプロキシとも通信をできるようにした。 | |
179 | |
2 | 180 \section{lionAuthenticate} |