# HG changeset patch # User Taninari YU # Date 1391433294 -32400 # Node ID 2d6118b663678e1dc7ee2ad9d2d8febdf5c5ef60 # Parent b6a6413ac3ca3531bb2eaa8d0ee04fcecbda3f07 update diff -r b6a6413ac3ca -r 2d6118b66367 paper/abstract.tex --- a/paper/abstract.tex Mon Feb 03 16:56:17 2014 +0900 +++ b/paper/abstract.tex Mon Feb 03 22:14:54 2014 +0900 @@ -1,8 +1,9 @@ \begin{abstract} 各クライアントをツリー状に接続し、親が配信したデータを木の上から下へとリレーさせることのできる分散版VNC(TreeVNC)のアプリケーションを実装した。 -通常のVNCでは配信者へ負荷が集中する設計となっている。例えば、大学の講義等で通常のVNCを用いて画面共有を行った時、クライアントの増加に比例して配信者への負荷が増えてしまう。 -この問題を解決する為に、ツリー構造にクライアントを接続させ、データを上から下へ流していくことでスケーラビリティを持たせた。 -スケーラビリティを持つサービスとは、利用者が増加してもサービスの質を落とすこなく利用できるサービスのことである。 +通常のVNCでは配信者へ負荷が集中する設計となっている。例えば、大学の講義等で従来のVNCを用いて画面共有を行った時、クライアントの増加に比例して配信者への負荷が増えてしまう。 +この問題を解決する為に、ツリー構造にクライアントを接続させ、データを上から下へ流していくことを提案した。 +これにより、利用者が増加しても質を落とすことないスケーラビリティを持ったサービスを作成することができる。 TreeVNCを使用した結果、クライアントの数を増やしてもサーバ側への負荷を抑えスループットを落とすことなく利用する事ができた。 -更に、発表者をボタン一つで切り替えられるようにUserInterfaceの拡張を行い、マルチディスプレイを使用している場合、一つのディスプレイのデータを受け取ることができるようにマルチディスプレイのサポートも行った。 +本論文では、発表者の切り替えとマルチディスプレイの対応を行った。 +%発表者をボタン一つで切り替えられるようにUserInterfaceの拡張を行い、マルチディスプレイを使用している場合、一つのディスプレイのデータを受け取ることができるようにマルチディスプレイのサポートも行った。 \end{abstract} diff -r b6a6413ac3ca -r 2d6118b66367 paper/chapter1.tex --- a/paper/chapter1.tex Mon Feb 03 16:56:17 2014 +0900 +++ b/paper/chapter1.tex Mon Feb 03 22:14:54 2014 +0900 @@ -1,16 +1,17 @@ -\chapter{序論} +\chapter{研究背景と目的} \pagenumbering{arabic} -普段授業を行う際、プロジェクタなどの投影機を使用して授業を進める風景をよく目にする。しかし、広い部屋だと後ろの席に座っている生徒が見えにくいなどの不便を感じることがよくある。 -もし、授業を受けている学生の手元にパソコンがあるならば、手元のパソコンに先生の説明しているスライドを表示して授業を進めることでどこの席に座っていても、手元の画面に表示されるので見えづらいという問題は解決される。\\ -みんなの手元に先生の画面を配信するシステムとして、ビデオケーブルを引いて画面を配信する方法があり、このような方法で画面を配信するのが一般的である。しかし、この方法で画面共有をするには、工事を行ってビデオケーブル引かなければならないので、コストがかかってしまう。\\ -ビデオケーブルを引かずに、WEBページに授業のスライドを載せることで、擬似的に画面を共有することもできる。しかし、この場合は、ページが同期していないのでどのスライドを説明してるのかわからなくなるといった問題がある。 -プログラミングの授業などでは、先生がどのような作業をしているかがとても重要になってくるが、これはWEBページを使用しても実現することができない。\\ -これらの問題を解決するために、オープンソースなアプリケーションであるVNCを用いることで、無料で画面を共有することができる。 +授業を行う際、プロジェクタなどの投影機を使用して授業を進めることがよくある。しかし、広い部屋だと後ろの席に座っている生徒が見えにくいなどの不便を感じることがよくある。 +もし、授業を受けている学生の手元にパソコンがあるならば、手元のパソコンに先生の説明しているスライドを表示して授業を進めることでどこの席に座っていても、手元の画面に表示されるので見えづらいという問題は解決される。 +みんなの手元に先生の画面を配信するシステムとして、ビデオケーブルを引いて画面を配信する方法があり、このような方法で画面を配信するのが一般的である。しかし、この方法で画面共有をするには、工事を行ってビデオケーブル引かなければならないので、コストがかかってしまう。 +ビデオケーブルを引かずに、WEBページに授業のスライドを載せることで、ブラウザを共有することもできる。しかし、この場合は、ページが同期していないのでどのスライドを説明してるのかわからなくなるといった問題がある。 +プログラミングの授業などでは、先生がどのような作業をしているかがとても重要になってくるが、これはWEBページを使用しても実現することができない。 +これらの問題を解決するために、オープンソースなアプリケーションであるVNCを用いることで、画面を共有することができる。 +VNCとは、RFBプロトコルを使用して、画面のデータを配信するシステムである。RFBプロトコルとは しかし、VNCは多人数で同時に接続してしまうと処理性能が落ちて授業の進行に画面がついていかなくなったり、アプリケーションの処理自体が止まってしまったりしてしまう。 -この問題の原因は一つのコンピュータに多人数が繋がるときに生じる問題である。\\ -そこで、多人数で画面共有ができるようにクライアントをツリー構造に接続させ、上から順番にデータを流していく方法によって、VNCサーバに対する負荷を分散させることができると考えた。 -更に、ゼミでVNCを使用することを想定する。従来のVNCでは、発表者が変わるごとに新しくVNCに接続し直す必要がある。このような手間を省くことで、ゼミをスムーズに進行させることができる。\\ -本研究では、多人数で画面共有ができるようにクライアントをツリー構造に接続させ、上から順番にデータを流していく方法で、VNCサーバに対する負荷を分散させるTreeVNCを作成し、更に、ゼミなどで使いやすいようにユーザインタフェースの提案と実装を行う。\\ +この問題の原因は一つのコンピュータに多人数が繋がるときに生じる問題である。 +そこで、多人数で画面共有ができるようにクライアントをツリー状に接続させ、上から順番にデータを流していく方法によって、VNCサーバに対する負荷を分散させることができると考えた。 +更に、ゼミでVNCを使用することを想定する。従来のVNCでは、発表者が変わるごとに新しくVNCに接続し直す必要がある。接続の手間を省くことで、ゼミをスムーズに進行させることができる。 +本研究では、多人数で画面共有ができるようにクライアントをツリー構造に接続させ、上から順番にデータを流していく方法で、VNCサーバに対する負荷を分散させるTreeVNCを作成し、更に、ゼミなどで使いやすいようにユーザインタフェースの提案と実装を行う。 %先生のスライドを生徒の手元にあるパソコンに表示することができる。しかし、多人数の生徒が先生のパソコンに同時に接続してしまうと処理性能が落ちて授業の進行に画面がついていかなくなってしまう。 %更に当研究室では、VNCを使用してゼミを進めている。従来のVNCを使用すると発表者が変わるごとに新しくVNCを立ち上げ　直す必要がある。このような手間がなくなるとスムーズにゼミを進めることができる。\\ %　本研究では、多人数で画面共有ができるようにクライアントをツリー構造に接続させ、上から順番にデータを流していく方法でVNCサーバに対する負荷を分散させるTreeVNCを作成し、更にゼミなどで使いやすいようにユーザインタフェースの提案と実装を行う。 diff -r b6a6413ac3ca -r 2d6118b66367 paper/chapter2.tex --- a/paper/chapter2.tex Mon Feb 03 16:56:17 2014 +0900 +++ b/paper/chapter2.tex Mon Feb 03 22:14:54 2014 +0900 @@ -3,13 +3,16 @@ この章では、従来画面共有で使用されているTightVNCとそれに使われてるRFBプロトコルについて説明する。その上で、多人数で使用する際の問題点を説明する。 \section{RFBプロトコル} -RFB(remote frame buffer)プロトコル\cite{rfbProtocol}とは、画面共有システムなどに用いられている、リモートのグラフィカルユーザーインターフェースにアクセスするためのプロトコルである。 -ユーザが居る側をRFBクライアント側と呼び、フレームバッファ(画像データ)への更新が行われる側はRFBサーバと呼ぶ。\\ -RFBプロトコルでは、最初にサーバ・クライアント間でハンドシェイクが行われる。ハンドシェイクでは、プロトコルバージョンの確認・接続に対しての認証が行われる。\\ -ハンドシェイク後には、クライアントに向けて初期メッセージが送信される。初期メッセージにはフレームバッファの大きさやデスクトップに付けられた名前などが含まれている。\\ -RFBサーバ側はフレームバッファの更新が行われるたびに、RFBクライアントに対してフーレムバッファの更新データを矩形で送信する。更にRFBクライアントのフレームバッファアップートリクエストが来るとそれに答え返信する。\\ -RFBプロトコルは、描画データに使われっるエンコードが多数用意されており、また独自のエンコードを実装することもできるシンプルなプロトコルである。\\ +RFB(remote frame buffer)プロトコル\cite{rfbProtocol}とは、自身の画面を送信し、ネットワーク越しに他者の画面に表示するプロトコルである。 +ユーザが居る側をRFBクライアント側と呼び、Framebufferへの更新が行われる側はRFBサーバと呼ぶ。 +Framebufferとは、メモリ上に置かれた画像データのことである。 RFBプロトコルの概要を図\ref{fig:rfb}に示す。 +RFBプロトコルでは、最初にプロトコルバージョンの確認や認証が行われる(図\ref{fig:rfb}中,1: ,2: ,3: ,4:)。 +%RFBプロトコルでは、最初にサーバ・クライアント間でハンドシェイクが行われる。ハンドシェイクでは、プロトコルバージョンの確認・接続に対しての認証が行われる。 +その後、クライアントに向けてFramebufferの大きさやデスクトップに付けられた名前などが含まれている初期メッセージが送信される。(図\ref{fig:rfb}中,5:) +%ハンドシェイク後には、クライアントに向けて初期メッセージが送信される。初期メッセージにはフレームバッファの大きさやデスクトップに付けられた名前などが含まれている。 +RFBサーバ側はFramebufferの更新が行われるたびに、RFBクライアントに対してFramebufferの変更部分だけを送信する。更にRFBクライアントのFramebufferUpdateRequestが来るとそれに答え返信する。 +RFBプロトコルは、描画データに使われるエンコードが多数用意されており、また独自のエンコードを実装することもできるプロトコルである。 \begin{figure}[!htbp] \begin{center} \includegraphics[width=110mm]{./images/rfbprotocol.pdf} @@ -22,9 +25,30 @@ \newpage \section{TightVNC} -TightVNC(Tight Virtual Network Computing)\cite{tightvnc}はRFBプロトコルを用いて作成された、画面共有をするためのオープンソースなアプリケーションである。 -TightVNCはサーバ側とクライアント(ビューア)側に分かれていて、サーバを起動し、クライアントがサーバに接続を行い画面共有を可能とする。 -TightVNCの特徴として、圧縮された画像データを扱うことができることが挙げられる。そのため、低速回線環境でも動作できるようになっている。しかしエンコードとデコードを行う分CPUのパワーが必要になる。\\ +TightVNC(Tight Virtual Network Computing)\cite{tightvnc}はJAVAを用いて作成されたRFBプロトコルのクライアントである。 +本研究で作成したTreeVNCはTightVNCを元に作成されている。 + + + +\section{授業でVNCを使用するときの問題点} +VNCを多人数で使用する際は、サーバに対してクライアントの接続が一極集中してしまうことが問題である。 +実験として、iMacで複数のPCからVNCをかけ検証してみた。 +10台接続するとVNCクライアントでの画面の更新が遅くなり、さらにCPU使用率も跳ね上がっていた。 + +\begin{table}[htbp] +\caption{スループットとCPU使用率} +\label{tb:cpuuserate} +\begin{center} + \begin{tabular}{|c|c|c|} \hline + & スループット(Byte) & CPU使用率 \\ \hline + 1台 & 20M(最大速度) & 55\% \\ \hline + 10台 & 5M & 100\% \\ \hline + \end{tabular} +\end{center} +\end{table} + +一本の通信網への負荷が高く、サーバのCPUへの負荷が高いというのが問題である。\\ + \section{VNC Reflector} VNCReflectorはサーバへの負荷を減らすように設計されているVNCソフトの一つである。 @@ -37,31 +61,10 @@ Proxyに対しては負荷がかかる。 -\section{授業でVNCを使用するときの問題点} -VNCを多人数で使用する際は、サーバに対してクライアントの接続が一極集中してしまうことが問題である。 -実験としてまず、iMacで複数のPCからVNCをかけ検証してみた。 -10台接続するとVNCクライアントでの画面の更新が遅くなり、さらにCPU使用率も跳ね上がっていた。 - -\begin{table}[htbp] -\caption{スループットとCPU使用率} -\label{tb:cpuuserate} -\begin{center} - \begin{tabular}{|c|c|c|} \hline - & スループット(Byte) & CPU使用率 \\ \hline - １台 & 20M(最大速度) & 55\% \\ \hline - ４８台 & 5M & 100\% \\ \hline - \end{tabular} -\end{center} -\end{table} - -一本の通信網への負荷が高く、サーバのCPUへの負荷が高いというのが問題である。\\ - - - \section{ゼミでVNCを使用するときの問題点} -ゼミでVNCを利用することを想定する。ゼミでは通常発表者が複数人いるので、発表者が切り替わる。VNCを用いて発表を行う場合、発表者が切り替わるごとに接続し直さなければならない。 -それに伴い接続し直す際の認証が毎回発生する。\\ -また、高解像度のマルチディスプレイを使用している人などがいる場合は、送信される画像データの量が多くなりすぎてしまいメモリを圧迫してしまうことがある。 +ゼミでは通常発表者が複数人いるので、発表者が切り替わる。VNCを用いて発表を行う場合、発表者が切り替わるごとに接続し直さなければならない。 +それに伴い接続し直す際の認証が毎回発生する。 +また、高解像度のマルチディスプレイを使用している人がいる場合は、送信される画像データの量が多くなりすぎてしまいメモリを圧迫してしまうことがある。 %\begin{figure}[!htbp] @@ -72,10 +75,10 @@ %\label{fig:auth} %\end{figure} -\section{BroadcastとMulticast} +\section{BroadcastとMulticastの可能性} Broadcastは同じネットワークアドレス(同一セグメント)上のすべての端末に対して、同時にデータを送信することである(図\ref{fig:broadcast})。 Multicastは同じマルチキャストアドレスを持った端末に同時にデータを送信することである(図\ref{fig:multicast})。 -画像データを配信する際にBroadcastやMulticastを用いて、画像データを送信すると、木構造を構成する必要がなくなり、画像データ送信も一回送信するだけで良い。そこで、Broadcastを用いた実装について考察してみた。 +画像データを配信する際にBroadcastやMulticastを用いて、画像データを送信すると、木構造を構成する必要がなくなり、画像データ送信も一回だけで良い。そこで、Broadcastを用いた実装について考察してみるo。 \begin{figure}[!htbp] \begin{center} \includegraphics[width=110mm]{./images/broadcast.pdf} @@ -92,18 +95,52 @@ \label{fig:multicast} \end{figure} -\subsection{Braodcastパケットの性質} -Broacdcastパケットの性質として大きすぎるデータの送信ができないという性質がある。どの程度の大きさのパケットまで送れるのかをテストしてみた結果64000byteまでだと送信することができることがわかった。\\ -もう一つの性質にパケットが消失(ロスト)しても特定することができないという性質がある。この問題に対しては後述する。 +\subsection{Broadcastパケットの性質} +Broacdcastパケットの性質として大きすぎるデータの送信ができないという性質がある。どの程度の大きさのパケットまで送れるのかをテストしてみた結果64000byteまでだと送信することができることがわかった。 +もう一つの性質にパケットが消失(ロスト)しても特定することができないという性質がある。 MulticastについてもBroadcastと同じ性質を持っている。 -\subsection{パケットの分割} -VNCでは画像データが更新される際に矩形単位で更新データを送信する。\\ -画面全体の更新やマルテディスプレイの更新などの大きいデータの更新ではどうしてもデータサイズが大きくなってしまう。例えば1920*1080の解像度のディスプレイのデータ量は6220800byte(1920*1080*3)である。\\ -Broadcastでは、このような大きなデータを受け取った際は、64000byte以下に分割して送らなければならない。私が作成しているTreeVNCではRoot Nodeに送られてきた画像データを一旦解凍し、再圧縮してNodeに送っているため、解凍した後に分割して、64000byte以下にして圧縮後送信することで実現できる。 - \subsection{消失したパケットの検出} Broadcastの性質で説明したとおり、Broadcastではデータが消失したことをクライアントが検出することができない。そこでプロトコルを拡張し、データごとにシリアル番号を振り、連続でない値が来た場合、正しくデータが届いていないと判断することができる。 \subsection{Acknowledgeの設計} データが消失したのを検出した際、どのような対応をするのかが問題になる。シリアル番号を振っているのでプロキシに消失したデータのシリアル番号を指定することで、消失したデータの再送が可能となる。この際、再送にBroadcastを用いると、データの消失が起こるので、消失したデータを再送する際はTCPコネクションを用いて送信を行うのが良い。 + +\subsection{Broadcastを使用した送信} +Broadcastを使用する場合は一回に送信するパケットのサイズを64000byte以下にしなければならない。もし、1920*1080のサイズの画像データを送信する際、約600万byte(1920*1080*3)となってしまう。これでは送信することができないのでデータを分割し64000byte以下にして送信しなければならない。 +作成したTreeVNCでは、サーバから受け取った画像データをRoot Nodeが一旦解凍して、再圧縮し、Nodeへ送信するという方式を取っている。 +一旦解凍した後はRawDataとなるのでデータを分割することができる。TreeVNCではZRLEエンコーディングを使用して、これを解凍すると左から右へ上から下への順の64*64のタイル群のRawDataとなる。 +解凍されたRawDataを図\ref{fig:rawdata}に示す。 + + +\begin{figure}[!htbp] +\begin{center} +\includegraphics[width=110mm]{./images/rawdata.pdf} +\end{center} +\caption{RawDataの構造} +\label{fig:rawdata} +\end{figure} + +テストで、\ref{fig:comparenormalandtree}のように2列づつに分割して送信するプログラムを書いた(Listing\ref{src:blocking})。 +毎回バッファをコピーして送っているため画面共有に支障をきたすほど処理が遅くなってしまった。 + +BroadcastとMulticastでどのくらいパケットロスするのかもテストを行った。 +BroadcastとMulticastを用いてそれぞれのbyte数を100packetずつ送信しパケットロス率を表したのが表\ref{tb:testofbroadcastandmulticast}である。 +表\ref{tb:testofbroadcastandmulticast}にあるようにMulticastを用いても、4000byteを100packet続けて送信すると37\%もパケットロスしてしまう。 + +\begin{table}[htbp] +\caption{BroadcastとMulticastのテスト} +\label{tb:testofbroadcastandmulticast} +\begin{center} + \begin{tabular}{|c|c|c|} \hline + & 256byte & 4000byte \\ \hline + Broadcasst & 47\% &87\% \\ \hline + Multicast & 0\% &37\% \\ \hline + \end{tabular} +\end{center} +\end{table} + +結果として、データ分割の処理が重い、且つ予想以上のパケットロス率という結果をになったので、BraodcastやMulticastを用いた実装を行うことはもう少し工夫が必要になることがわかった。 + + + diff -r b6a6413ac3ca -r 2d6118b66367 paper/chapter3.tex --- a/paper/chapter3.tex Mon Feb 03 16:56:17 2014 +0900 +++ b/paper/chapter3.tex Mon Feb 03 22:14:54 2014 +0900 @@ -1,7 +1,7 @@ \chapter{画面共有システムTreeVNCの設計} \section{木構造を用いたTreeVNCの設計} -まず、多人数が参加している授業でVNCを使う場合に起こる問題は、一つのコンピュータに多人数が繋がり、処理が集中してしまって、性能が大幅に落ちてしまうところである(図\ref{fig:vnc})。 +多人数が参加している授業でVNCを使う場合に起こる問題は、一つのコンピュータに多人数が繋がり、処理が集中してしまって、性能が大幅に落ちてしまうところである(図\ref{fig:vnc})。 多人数の同時接続を可能にするには、一極集中で接続するのではなく、Node同士で負荷を分散させることによって実現できるのではないかと考えた。\\ 負荷分散を行う際、Node同士どのようなトポロジを組むのが適切か検討した結果、上から流れてきたデータを下のNodeへと伝えていくことのできる木構造が良いと考えた。\\ 　今回行った設計ではNodeを木構造に接続させデータを流すためにサーバとNodeの間にRoot Node(サーバとNodeの通信を仲介するもの)を設置する方式をとった。Root Nodeは主にNodeの管理とServerから流れてきた画像データの管理を担当する。\\ @@ -28,9 +28,8 @@ \newpage \section{TreeVNCの原理} -TreeVNCがどのような負荷分散を行った結果、どのように負荷が分散されているのかを説明する。\\ -通常のVNCでは、一極集中型でサーバに接続してしまうのでサーバに負荷がかかって性能を低下させたり停止してしまっている。そこでNodeを木構造に配置させることで、負荷がなくなっているように見える。しかし、実は負荷がスイッチにかかっていて、消えているわけではない。 -通常のVNCとTreeVNCの構造を比較した図を(図\ref{fig:comparenormalandtree})に示す。\\ +従来VNCでは、一極集中型でサーバに接続してしまうのでサーバに負荷がかかって性能を低下させたり停止してしまっている。そこでNodeを木構造に配置させることで、サーバへの負荷が減る。 +従来VNCとTreeVNCの構造を比較した図を(図\ref{fig:comparenormalandtree})に示す。\\ \begin{figure}[!htbp] \begin{center} @@ -118,8 +117,8 @@ \newpage \section{表示画面の切り替え} -VNCを使用して画面共有を行う場合、授業などでは講師の画面を共有していれば問題ない。しかし、ゼミなどの発表者が多数いる場合は画面共有の対象をを切り替えなければならない。画面共有対象の切り替えを行う場合、発表者ごとにサーバを立ち上げ直さなければならないという問題が発生する。そこで、ユーザ側からRoot Nodeにリクエストを出して、画面共有の対象を切り替える機能が必要になる。 -画面を切り替えるときは、Root Nodeだけが接続を切り替え、Nodeたちはそのデータを受け取るだけで良い(図\ref{fig:change})。 +VNCを使用して画面共有を行う場合、授業では、唯一講師の画面を共有する。しかし、ゼミなど発表者が多数いる場合は画面共有の対象を切り替えたいことがある。画面共有対象の切り替えを行う場合、発表者ごとにサーバを立ち上げ直さなければならないという問題が発生する。そこで、ユーザ側からRoot Nodeにリクエストを出して、画面共有の対象を切り替える機能が必要になる。 +画面を切り替えるときは、Root Nodeだけが接続を切り替え、他のNodeのトポロジの変更はない(図\ref{fig:change})。 \begin{figure}[!htbp] \begin{center} @@ -128,14 +127,14 @@ \caption{表示画面の切り替え} \label{fig:change} \end{figure} -画面の切替をどのユーザが行うのかという問題がある。Root Nodeに対してユーザが毎回IPアドレスを入力して切り替えるのは手間がかかる。そこで、Node側に画面切り替えボタンを設置し、ボタンを押すとRoot Nodeに自分の画面へ切り替えるように命令を出しRoot Nodeが了承すると画面が切り替わるように設計した。 +画面の切替をどのユーザが行うのかという問題がある。Root Nodeに対してユーザが毎回IPアドレスを入力して切り替えるのはUserInterface的によくない。そこで、Node側に画面切り替えを行うボタンを設置し、ボタンを押すとRoot Nodeに自分の画面へ切り替えるように命令を出しRoot Nodeが了承すると画面が切り替わるように設計した。 \newpage \section{マルチディスプレイの対応} -マルチディスプレイを用いてVNCを行うと、すべてのディスプレイのデータが繋がって表示されてしまう。通常発表などに使用されるディスプレイは一つである。すべての画面のデータを送ってしまうとその分だけ無駄なデータを送っていることになる。そこで、発表用に使用する画面のデータだけを送ることのできるようにディスプレイが指定できるようになることが必要になる。 +マルチディスプレイを用いてVNCを行うと、すべてのディスプレイのデータが繋がって表示されてしまう。通常発表などに使用されるディスプレイは一つである。すべての画面のデータを送ってしまうとその分だけ無駄なデータを送っていることになる。そこで、発表用に使用する画面のデータだけを送ることのできるようにディスプレイを指定する機能が必要になる。 -\section{再接続} +\section{木の再構成} 木を構成することはできたが途中のNodeが切断してしまった場合に木を再構成しなければならない。 木を再構成する手順は以下の用に行う。 　\begin{enumerate} @@ -230,39 +229,30 @@ \newpage \subsection{TimeOut} -MultiCastQueueを使ってのデータの取得には問題が発生した。 -それは、接続してきたNodeがデータを取得しない状況、例えばサスペンド状態になったときにRoot Nodeのメモリの中にデータが残り続けるというものである。 -メモリに残り続けたデータはやがてメモリオーバーフローを引き起こしてしまうのである。その様子を図\ref{fig:TimeOut}に示す。 -TimeOutスレッドがNodeの代わりにデータを取得することで、MulticastQueueの中からデータが削除されRoot Nodeのメモリを圧迫することがなくなった。(図\ref{fig:TimeOut2}) +MultiCastQueueを使ってデータ取得ときに問題が発生した。 +接続してきたNodeがデータを取得しない状況、例えばサスペンド状態になったときにRoot Nodeのメモリの中にデータが残り続けるというものである。 +メモリにデータが残り続けるとMemory Over Flowを起こしてしまう。 +その様子を図\ref{fig:TimeOut}を用いて説明する。 +Parentは流れてきたFramebufferUpdateをMulticastQueueの中に追加して行く。 +MulticastQueは要素ごとにCountDownLatchを持っていて、Childがデータを読み込むとCountDownを行い。Countが0になるとデータを削除する。 +ParentはChildが画像を受け取るまでMulticastQueueの中に持っているFramebufferUpdateを削除することができない。 +Childがサスペンド状態になった場合、MulticastQueueの中にあるFramebufferUpdateを削除することができないのでメモリを圧迫してしまいMemory Over Flowを起こしてしまう。 +そこで、ある一定の時間が経過すると代わりにデータを取得してくれるTimeOut用のスレッドを作成した。 +TimeOutスレッドはサスペンドしているNodeの代わりにFramebufferUpdateを取得する。 + \begin{figure}[tb] \begin{center} - \includegraphics[scale = 0.5]{images/TimeOut.pdf} + \includegraphics[scale = 0.9]{images/TimeOut.pdf} \end{center} \caption{ -Nodeサスペンド時のRoot Nodeのメモリの様子。 -データが残り続けメモリを圧迫してしまう。 +データが残り続けメモリを圧迫する様子。 } \label{fig:TimeOut} \end{figure} -そこで、ある一定の時間が経過すると代わりにデータを取得してくれるTimeOut用のスレッドを作成した。 -TimeOutスレッドはサスペンドしているNodeの代わりにデータを取得する。 - -\begin{figure}[tb] -\begin{center} -\includegraphics[scale = 0.5]{images/TimeOut2.pdf} -\end{center} -\caption{ -TimeOutが代わりにデータを取得する -} -\label{fig:TimeOut2} -\end{figure} - - - - +\newpage \section{圧縮の問題} diff -r b6a6413ac3ca -r 2d6118b66367 paper/chapter4.tex --- a/paper/chapter4.tex Mon Feb 03 16:56:17 2014 +0900 +++ b/paper/chapter4.tex Mon Feb 03 22:14:54 2014 +0900 @@ -3,19 +3,14 @@ \section{TightVNCのアップデートへの対応} TightVNCは現在も開発が続いていて、アップデートされている。このアップデートに対応するために、私が作成しているTreeVNCにも対応させる必要がある。\\ 卒業論文後から私は２種類のアップデートを行った。その２種類のアップデートの対応について説明する。\\ -まず、はじめに行ったアップデートはVersionが1.xから2.xへ変わるメジャーアップデートと呼ばれる大型アップデートである。\\ +はじめに行ったアップデートはVersionが1.3.10から2.5.0へ変わるメジャーアップデートと呼ばれる大型アップデートである。\\ このアップデートでは、パッケージ構成が追加され、元のソースコードがほとんど残っていない状態であった。このような大型なアップデートに対応するには、新しいTightVNCを元にして、作成したTreeVNCの機能を一つづつ移行していく必要がある。このソースコードのアップデートに加えソースコードの質を高めるためにリファクタリングを行った。 リファクタリングとは、将来の仕様変更に柔軟に対応できるようにソースコードの手直しを行うことである。 \section{UIの実装} -授業やゼミなどで使用してみて、必要な機能の提案が出てきたので、実装を行った。 - -\subsection{マルチディスプレイへの対応} -VNCでは画面の情報を矩形型にして送信する。もし複数のディスプレイが存在する場合すべてのディスプレイの情報が送られてくる。しかし、発表などに使用するディスプレイは一つである場合が多い。\\ -必要な画像が一つのディスプレイなのに、すべてのディスプレイのデータを送ると無駄なデータが発生する。そこで、ディスプレイを指定して、その画像だけ送信する機能を追加することで、無駄なデータ送信を省くことができる。 - +\subsection{FramebufferUpdateの概要} RFBプロトコルでは、FramebufferUpdateによって、矩形状の画像データが送信されてくる。\\ FrameBufferUpdateの概要を(表\ref{tb:framebufferupdate},表\ref{tb:framebufferupdate2})に示す。 @@ -77,6 +72,11 @@ \caption{画面更新時に来る可能性のないUpdateRectangle} \label{fig:sendscreenimage} \end{figure} +\subsection{マルチディスプレイへの対応} +VNCでは画面の情報を矩形型にして送信する。もし複数のディスプレイが存在する場合すべてのディスプレイの情報が送られてくる。しかし、発表などに使用するディスプレイは一つである場合が多い。\\ +必要な画像が一つのディスプレイなのに、すべてのディスプレイのデータを送ると無駄なデータが発生する。そこで、ディスプレイを指定して、その画像だけ送信する機能を追加することで、無駄なデータ送信を省くことができる。 + + 以上のことを踏まえ、FramebufferUpdateで送信されてきたheaderを確認し、x-positionを確認することで、どの画面の画像データを送信するかを選択することができる。\\ 例えば、図\ref{fig:rawdata}では、左側の画面を送信したいときは、x-positionが1920より小さい場合送信し、右側を送信したい場合は1920以上のデータを送信するようにフィルタリングすることで実現できる。 @@ -95,25 +95,9 @@ \label{fig:changevncserver} \end{figure} -図\ref{fig:changevncserver}で使用されている関数の説明を表\ref{tab:changevnc_functions}に示す。 +初めに、Root Nodeに対して画面を切り替える命令(1:changeVNCServer("10.3"))を出す。命令を受け取ったRoot Nodeは引数で受けっとた +IPのコンピュータに対して、接続要求を出す(2:requestVNC())。要求を受け取ったコンピュータはが認証を承諾するとRoot Nodeに対して、接続要求を承諾したことを通知する(3:acceptConnection())。Root Nodeは元から通信していたネットワーク接続を閉じる命令を出す(4:CloseConnection())。最後に繋がっているNodeに新しい画面に切り替わったことを通知する(5:newServer())。 -\begin{table}[!htbp] - \caption{画面切り替えの関数} - \label{tab:changevnc_functions} - \begin{center} - \begin{tabular}{|c||p{25zw}|} \hline - 名称 & 説明 \\ \hline \hline - changeVNCServer("10.3") & 受け取った引数のアドレスへ切り替えるための命令を出す関数。 \\ \hline - requestVNC() & changeVNCServer()で指定されたホストに対して接続要求を出す関数。\\ \hline - acceptConnection() & Root Nodeから接続要求が来たコンピュータが、要求に対して許可したことをRoot Nodeへ報告する関数。 \\ \hline - CloseConnection() & 今まで使用していた画面共有のストリームを閉じるための関数 \\ \hline - newServer() & Nodeに画面が切り替わったことを報告する関数。この命令でNodeは新しいストリームを受け取るようになる。 \\ \hline - \end{tabular} - \end{center} -\end{table} - - -\newpage newServer()の内部処理ををListing\ref{src:changescreen}に示す。これは、Root Nodeが子供に対して、画面の切り替えが起こったことを知らせるソースコードである。\\ clientListは、現在接続されているクライアント情報が入っている。クライアントにそれぞれTCP接続を行い、サーバが変わったので接続し直させる命令を送信する。 @@ -127,10 +111,9 @@ \end{lstlisting} -\newpage \section{Authentication} Root Nodeがサーバに対してVNC接続を行う際、ハンドシェイクが必要となる。 -ハンドシェイクの手順として、まず始めにRoot Nodeがサーバに接続を行うと、 +ハンドシェイクの手順として、始めにRoot Nodeがサーバに接続を行うと、 サーバがサポートする最新のプロトコルバージョンが送られてくる。 Root Nodeはサーバから送られてきたプロトコルバージョン以下の使用できるバージョンを サーバに対し送る。現時点で公開されているプロトコルバージョンは3.3、3.7、3.8だけである。 @@ -179,95 +162,12 @@ \newpage -\section{BroadcastとMulticast} -４章で述べたとおり、Broadcastを使用する場合は一回に送信するパケットのサイズを64000byte以下にしなければならない。もし、1920*1080のサイズの画像データを送信する際、約600万byte(1920*1080*3)となってしまう。これでは送信することができないのでデータを分割し64000byte以下にして送信しなければならない。\\ -作成したTreeVNCでは、サーバから受け取った画像データをRoot Nodeが一旦解凍して、再圧縮し、Nodeたちに送信するという方式を取っている。\\ -一旦解凍した後はRawDataとなるのでデータを分割することができる。TreeVNCではZRLEエンコーディングを使用して、これを解凍すると左から右へ上から下への順の64*64のタイル郡のRawDataとなる。\\ -解凍されたRawDataを図\ref{fig:rawdata}に示す。 - - -\begin{figure}[!htbp] -\begin{center} -\includegraphics[width=110mm]{./images/rawdata.pdf} -\end{center} -\caption{RawDataの構造} -\label{fig:rawdata} -\end{figure} - -ひとまずテストで、\ref{fig:comparenormalandtree}のように2列づつに分割して送信するプログラムを書いた(Listing\ref{src:blocking})。\\ -毎回バッファをコピーして送っているため画面共有に支障をきたすほど処理が遅くなってしまった。\\ -\newpage -\begin{lstlisting}[language=java,frame=lrbt,label=src:blocking,caption=画像データを分割するプログラム,numbers=left] - LinkedList output = new LinkedList(); - int width = header.getShort(8); - int height = header.getShort(10); - int y = header.getShort(6); - int dataLen = width * 64 * 3 * 2; - int temp = 0; - int count = height / 128; - - if (width \% 64 == 0) - dataLen += (width / 64) * 2; - else - dataLen += (((width / 64) + 1) * 2); - - for (int i = 0; i < count; i++) { - int tempDataLen = dataLen - temp; - - while (tempDataLen > INFLATE_BUFSIZE) { - output.addLast(input.poll()); - tempDataLen -= INFLATE_BUFSIZE; - } - if (tempDataLen == INFLATE_BUFSIZE) { - output.addLast(input.poll()); - createHeader(header, i, height, y); - zipSplitData(header, output); - output.clear(); - temp = INFLATE_BUFSIZE; - } else { - ByteBuffer tempBuf = input.poll(); - - ByteBuffer buf1 = ByteBuffer.allocate(INFLATE_BUFSIZE); - if(tempBuf.remaining()>tempDataLen) - tempBuf.get(buf1.array(), 0, tempDataLen); - buf1.limit(tempDataLen); - output.addLast(buf1); - createHeader(header, i, height, y); - zipSplitData(header, output); - output.clear(); - - buf1 = ByteBuffer.allocate(INFLATE_BUFSIZE); - tempBuf.get(buf1.array(), 0, tempBuf.remaining()); - - buf1.limit(INFLATE_BUFSIZE - tempDataLen); - output.addLast(buf1); - temp = INFLATE_BUFSIZE - tempDataLen; - } -\end{lstlisting} - -BroadcastとMulticastでどのくらいパケットロスするのかもテストを行った。\\ -BroadcastとMulticastを用いてそれぞれのbyte数を100packetずつ送信しパケットロス率を表したのが表\ref{tb:testofbroadcastandmulticast}である。\\ -表\ref{tb:testofbroadcastandmulticast}にあるようにMulticastを用いても4000byteを100packet送信すると37\%もパケットロスしてしまう。 - -\begin{table}[htbp] -\caption{BroadcastとMulticastのテスト} -\label{tb:testofbroadcastandmulticast} -\begin{center} - \begin{tabular}{|c|c|c|} \hline - & 256byte & 4000byte \\ \hline - Broadcasst & 47\% &87\% \\ \hline - Multicast & 0\% &37\% \\ \hline - \end{tabular} -\end{center} -\end{table} - -結果として、データ分割の処理が重い、且つ予想以上のパケットロス率という結果をになったので、BraodcastやMulticastを用いた実装を行うことはもう少し工夫が必要になることがわかった。 \section{接続先自動検索システムの実装} -Broadcastを用いてTreeVNCのRoot Nodeを検索するシステムを実装した。 - Listing\ref{src:gethost}はBroadcastを使用して、データを送信するプログラムである。 +起動しているRoot NodeはBroadcastパケットが流れてくるのを待っている(Listing\ref{src:gethost})。 +Javaでは、Broadcastパケットを作成す際は、java.net.DatagramPacketを使用する。 \begin{lstlisting}[language=java,frame=lrbt,label=src:gethost,caption=Broadcastを用いてサーバを探すプログラム,numbers=left] public GetHostClient(String _str) { str = _str; @@ -283,7 +183,10 @@ } } \end{lstlisting} -Listing\ref{src:gethost}は、Broadcast Packetを受け取ると、受け取ったIPアドレスに対し、ReplyBroadCast()の内部でTCPコネクションを張り、現在起動しているVNCServerの一覧を送る。 + +Listing\ref{src:gethost}のif文の中でstrと受け取った値(recvPacket.getData())を比較しているが、このstrを任意に決めることで、strの情報を知らない人には一覧情報が提供されなくなる。 +一覧情報が提供されない場合はIPアドレスを直接指定しなければ接続することができないので、IPアドレスとstrを知らない人は接続することができないので、プライベートな画面共有を行うこともできるように実装している。 +Broadcast Packetを受け取ると、受け取ったIPアドレスに対し、TCPコネクションを張り、現在起動しているVNC Serverの一覧を送る(replayBroadcast())。 \begin{lstlisting}[language=java,frame=lrbt,label=src:getbroadcast,caption=Broadcastを受け取るプログラム,numbers=left] byte[] buf = new byte[BufSize]; byte[] resorve = new byte[BufSize]; @@ -298,7 +201,7 @@ inputStream = new ByteArrayInputStream(recvPacket.getData()); inputStream.read(resorve); if(str.equals(castString(resorve))) - replyBroadCast(); + replyBroadcast(); if(stopFlag) break; } catch (IOException e) { e.printStackTrace(); diff -r b6a6413ac3ca -r 2d6118b66367 paper/chapter6.tex --- a/paper/chapter6.tex Mon Feb 03 16:56:17 2014 +0900 +++ b/paper/chapter6.tex Mon Feb 03 22:14:54 2014 +0900 @@ -52,11 +52,11 @@ } \end{lstlisting} -\subsection{capistrano} -今回の実験では、48台のサーバ上でCUI版のTreeVNCを立ち上げる必要がある。実験する度に、各サーバに一つ一つにログインしてアプリケーションを立ち上げるのは手間がかかりすぎてしまう。capistranoを使用することで、この問題を解決することができる。\\ -capistranoは複数のサーバ上で同時に処理を実行するためのオープンソースなソフトウェアであり、Rubyを用いて作成されている。\\ +\subsection{Capistrano} +今回の実験では、48台のサーバ上でCUI版のTreeVNCを立ち上げる必要がある。実験する度に、各サーバに一つ一つにログインしてアプリケーションを立ち上げるのは手間がかかりすぎてしまう。Capistranoを使用することで、この問題を解決することができる。\\ +Capistranoは複数のサーバ上で同時に処理を実行するためのオープンソースなソフトウェアであり、Rubyを用いて作成されている。\\ -capistranoを実行する際に使用するスクリプトをListing\ref{src:capistrano}に示す。\\ +Capistranoを実行する際に使用するスクリプトをListing\ref{src:capistrano}に示す。\\ スクリプトはListing\ref{src:cap_run}として実行することができる。\\ @@ -79,7 +79,7 @@ 木の深さが深くなってしまうと、データが下に届くまでに遅延が発生してしまう可能性がある。 そこで、木の深さによる遅延がどの程度発生するのかを測定してみた。\\ \subsection{遅延の測定方法} -Rfbプロトコルでは、送られてくるデータの先頭にどのような処理をするかの命令番号が入っている。\\ +RFBプロトコルでは、送られてくるデータの先頭にどのような処理をするかの命令番号が入っている。\\ 表\ref{tb:message}は送られてくるメッセージの一覧である。\\ 命令番号11(CheckDelay)はプロトコルを拡張して作成した命令である。 @@ -117,16 +117,16 @@ \subsection{遅延の測定結果} 2分木で木を構成した場合、Node数が48台だと深さが6となる。\\ Root Nodeを起動し、並列計算環境48台を起動し、Root Nodeから一番下のNodeまでどのくらいの時間がかるのかを測定した。\\ -\ref{tab:delay} はデータを20回ほど測定し平均値を取った遅延の表である。\\ +\ref{tab:delay} はデータを20回ほど測定し最遅値を取った遅延の表である。\\ \begin{table}[!htbp] \caption{データ送信の遅延} \label{tab:delay} \begin{center} \begin{tabular}{|c||c|} \hline -段数 & 遅延 \\ \hline \hline -2 & 約1ミリ秒\\ \hline -4 & 約58ミリ秒\\ \hline -6 & 約139ミリ秒\\ \hline +段数 & 最遅値 \\ \hline \hline +2 & 32ミリ秒\\ \hline +4 & 244ミリ秒\\ \hline +6 & 446ミリ秒\\ \hline \end{tabular} \end{center} \end{table} @@ -134,7 +134,7 @@ 並列計算環境のVMは高速なネットワークでつながっているので、遅延が少ない可能性がある。 そこで、実際にOSの授業で、どの程度の遅延があるのかを測ってみた。\\ OSの際は25Nodeであったので、段数にすると5段である。 -結果は、5段目で約48ミリ秒と並列計算環境より良い結果が出た。\\ +結果は、164ミリ秒と並列計算環境より良い結果が出た。\\ diff -r b6a6413ac3ca -r 2d6118b66367 paper/conclusion.tex --- a/paper/conclusion.tex Mon Feb 03 16:56:17 2014 +0900 +++ b/paper/conclusion.tex Mon Feb 03 22:14:54 2014 +0900 @@ -21,8 +21,13 @@ \subsection{Multicast対応} Broadcastはパケットロス率が高すぎるので使用することは難しいが、Multicastのロス率だと、うまくいく見込がある。 Multicastを使用する際は、一回に送るデータ量は64000Byteである必要がある。 -私が行ったデータのBlockingは64000byte毎にByteBufferのコピーを行っていたので、処理が重くなっていた。しかし、コピーせずBufferをwrapすることで、処理が軽くなる。 +私が行ったデータのBlockingは64000byte毎にByteBufferのコピーを行っていたので、処理が重くなっていた。しかし、コピーせずBufferをwrapすることで、処理が軽くなるのでMulticastに対応できる可能性がある。 \subsection{画面範囲の指定} ディスプレイの指定はできるようになったが、現在は画面の範囲指定ができていない。 -画像データは一旦Root Nodeで解凍されるのでその際に画像を加工することで、画面の範囲を指定できるようになる。 +画像データは、一旦Root Nodeで解凍されるので、headerの情報を読み込み、適切なサイズに画像を加工し、headerを適切な値に変更することで、画面の範囲を指定できるようになる。 +TreeVNCでは、画像の配信にMulticastQueueを使用している。 +高解像度のディスプレイを使用すると、MulticastQueueのデータ量が増えてしまい、Memory Over Flowを起こす可能性がある。 +画面範囲の指定ができるようになれば、Mac Book Retina等の高解像度ディスプレイでも安定して画面共有をすることができるようになる。 + + diff -r b6a6413ac3ca -r 2d6118b66367 paper/images/TimeOut.pdf Binary file paper/images/TimeOut.pdf has changed diff -r b6a6413ac3ca -r 2d6118b66367 paper/images/TimeOut.xbb --- a/paper/images/TimeOut.xbb Mon Feb 03 16:56:17 2014 +0900 +++ b/paper/images/TimeOut.xbb Mon Feb 03 22:14:54 2014 +0900 @@ -1,8 +1,8 @@ %%Title: ./images/TimeOut.pdf %%Creator: extractbb 20120420 -%%BoundingBox: 0 0 451 331 -%%HiResBoundingBox: 0.000000 0.000000 451.000000 331.000000 -%%PDFVersion: 1.4 +%%BoundingBox: 0 0 321 318 +%%HiResBoundingBox: 0.000000 0.000000 321.000000 318.000000 +%%PDFVersion: 1.3 %%Pages: 1 -%%CreationDate: Sun Feb 2 15:23:54 2014 +%%CreationDate: Mon Feb 3 20:55:57 2014 diff -r b6a6413ac3ca -r 2d6118b66367 paper/images/TimeOut2.xbb --- a/paper/images/TimeOut2.xbb Mon Feb 03 16:56:17 2014 +0900 +++ b/paper/images/TimeOut2.xbb Mon Feb 03 22:14:54 2014 +0900 @@ -1,8 +1,8 @@ %%Title: ./images/TimeOut2.pdf %%Creator: extractbb 20120420 -%%BoundingBox: 0 0 451 331 -%%HiResBoundingBox: 0.000000 0.000000 451.000000 331.000000 +%%BoundingBox: 0 0 433 313 +%%HiResBoundingBox: 0.000000 0.000000 433.000000 313.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Sun Feb 2 15:23:54 2014 +%%CreationDate: Mon Feb 3 20:55:57 2014 diff -r b6a6413ac3ca -r 2d6118b66367 paper/images/ZRLE.xbb --- a/paper/images/ZRLE.xbb Mon Feb 03 16:56:17 2014 +0900 +++ b/paper/images/ZRLE.xbb Mon Feb 03 22:14:54 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 356.000000 262.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Sun Feb 2 15:23:54 2014 +%%CreationDate: Mon Feb 3 20:55:57 2014 diff -r b6a6413ac3ca -r 2d6118b66367 paper/images/ZRLE2.xbb --- a/paper/images/ZRLE2.xbb Mon Feb 03 16:56:17 2014 +0900 +++ b/paper/images/ZRLE2.xbb Mon Feb 03 22:14:54 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 356.000000 262.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Sun Feb 2 15:23:54 2014 +%%CreationDate: Mon Feb 3 20:55:57 2014 diff -r b6a6413ac3ca -r 2d6118b66367 paper/images/ZRLEE.xbb --- a/paper/images/ZRLEE.xbb Mon Feb 03 16:56:17 2014 +0900 +++ b/paper/images/ZRLEE.xbb Mon Feb 03 22:14:54 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 414.000000 354.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Sun Feb 2 15:23:54 2014 +%%CreationDate: Mon Feb 3 20:55:57 2014 diff -r b6a6413ac3ca -r 2d6118b66367 paper/images/ZRLEE2.xbb --- a/paper/images/ZRLEE2.xbb Mon Feb 03 16:56:17 2014 +0900 +++ b/paper/images/ZRLEE2.xbb Mon Feb 03 22:14:54 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 476.934000 281.961000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Sun Feb 2 15:23:54 2014 +%%CreationDate: Mon Feb 3 20:55:57 2014 diff -r b6a6413ac3ca -r 2d6118b66367 paper/images/auth.xbb --- a/paper/images/auth.xbb Mon Feb 03 16:56:17 2014 +0900 +++ b/paper/images/auth.xbb Mon Feb 03 22:14:54 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 360.000000 194.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Sun Feb 2 15:23:54 2014 +%%CreationDate: Mon Feb 3 20:55:57 2014 diff -r b6a6413ac3ca -r 2d6118b66367 paper/images/broadcast.xbb --- a/paper/images/broadcast.xbb Mon Feb 03 16:56:17 2014 +0900 +++ b/paper/images/broadcast.xbb Mon Feb 03 22:14:54 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 458.000000 303.000000 %%PDFVersion: 1.3 %%Pages: 1 -%%CreationDate: Sun Feb 2 15:23:54 2014 +%%CreationDate: Mon Feb 3 20:55:57 2014 diff -r b6a6413ac3ca -r 2d6118b66367 paper/images/changeserver.xbb --- a/paper/images/changeserver.xbb Mon Feb 03 16:56:17 2014 +0900 +++ b/paper/images/changeserver.xbb Mon Feb 03 22:14:54 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 280.000000 251.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Sun Feb 2 15:23:54 2014 +%%CreationDate: Mon Feb 3 20:55:57 2014 diff -r b6a6413ac3ca -r 2d6118b66367 paper/images/changevncserver.pdf Binary file paper/images/changevncserver.pdf has changed diff -r b6a6413ac3ca -r 2d6118b66367 paper/images/changevncserver.xbb --- a/paper/images/changevncserver.xbb Mon Feb 03 16:56:17 2014 +0900 +++ b/paper/images/changevncserver.xbb Mon Feb 03 22:14:54 2014 +0900 @@ -1,8 +1,8 @@ %%Title: ./images/changevncserver.pdf %%Creator: extractbb 20120420 -%%BoundingBox: 0 0 624 493 -%%HiResBoundingBox: 0.000000 0.000000 624.000000 493.000000 +%%BoundingBox: 0 0 606 475 +%%HiResBoundingBox: 0.000000 0.000000 606.000000 475.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Sun Feb 2 15:23:54 2014 +%%CreationDate: Mon Feb 3 20:55:57 2014 diff -r b6a6413ac3ca -r 2d6118b66367 paper/images/compare_encoding.xbb --- a/paper/images/compare_encoding.xbb Mon Feb 03 16:56:17 2014 +0900 +++ b/paper/images/compare_encoding.xbb Mon Feb 03 22:14:54 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 432.000000 302.000000 %%PDFVersion: 1.3 %%Pages: 1 -%%CreationDate: Sun Feb 2 15:23:54 2014 +%%CreationDate: Mon Feb 3 20:55:57 2014 diff -r b6a6413ac3ca -r 2d6118b66367 paper/images/comparenormalandtree.xbb --- a/paper/images/comparenormalandtree.xbb Mon Feb 03 16:56:17 2014 +0900 +++ b/paper/images/comparenormalandtree.xbb Mon Feb 03 22:14:54 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 492.000000 252.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Sun Feb 2 15:23:54 2014 +%%CreationDate: Mon Feb 3 20:55:57 2014 diff -r b6a6413ac3ca -r 2d6118b66367 paper/images/countdownlatch.xbb --- a/paper/images/countdownlatch.xbb Mon Feb 03 16:56:17 2014 +0900 +++ b/paper/images/countdownlatch.xbb Mon Feb 03 22:14:54 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 308.000000 230.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Sun Feb 2 15:23:54 2014 +%%CreationDate: Mon Feb 3 20:55:57 2014 diff -r b6a6413ac3ca -r 2d6118b66367 paper/images/createtree.xbb --- a/paper/images/createtree.xbb Mon Feb 03 16:56:17 2014 +0900 +++ b/paper/images/createtree.xbb Mon Feb 03 22:14:54 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 541.000000 395.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Sun Feb 2 15:23:54 2014 +%%CreationDate: Mon Feb 3 20:55:57 2014 diff -r b6a6413ac3ca -r 2d6118b66367 paper/images/multicast.xbb --- a/paper/images/multicast.xbb Mon Feb 03 16:56:17 2014 +0900 +++ b/paper/images/multicast.xbb Mon Feb 03 22:14:54 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 458.000000 303.000000 %%PDFVersion: 1.3 %%Pages: 1 -%%CreationDate: Sun Feb 2 15:23:54 2014 +%%CreationDate: Mon Feb 3 20:55:57 2014 diff -r b6a6413ac3ca -r 2d6118b66367 paper/images/multicastqueue.pdf Binary file paper/images/multicastqueue.pdf has changed diff -r b6a6413ac3ca -r 2d6118b66367 paper/images/multicastqueue.xbb --- a/paper/images/multicastqueue.xbb Mon Feb 03 16:56:17 2014 +0900 +++ b/paper/images/multicastqueue.xbb Mon Feb 03 22:14:54 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 480.000000 267.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Sun Feb 2 15:23:54 2014 +%%CreationDate: Mon Feb 3 20:55:57 2014 diff -r b6a6413ac3ca -r 2d6118b66367 paper/images/multicastqueue2.xbb --- a/paper/images/multicastqueue2.xbb Mon Feb 03 16:56:17 2014 +0900 +++ b/paper/images/multicastqueue2.xbb Mon Feb 03 22:14:54 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 480.000000 267.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Sun Feb 2 15:23:54 2014 +%%CreationDate: Mon Feb 3 20:55:57 2014 diff -r b6a6413ac3ca -r 2d6118b66367 paper/images/rawdata.xbb --- a/paper/images/rawdata.xbb Mon Feb 03 16:56:17 2014 +0900 +++ b/paper/images/rawdata.xbb Mon Feb 03 22:14:54 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 286.000000 118.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Sun Feb 2 15:23:54 2014 +%%CreationDate: Mon Feb 3 20:55:57 2014 diff -r b6a6413ac3ca -r 2d6118b66367 paper/images/reconnection.xbb --- a/paper/images/reconnection.xbb Mon Feb 03 16:56:17 2014 +0900 +++ b/paper/images/reconnection.xbb Mon Feb 03 22:14:54 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 558.000000 307.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Sun Feb 2 15:23:54 2014 +%%CreationDate: Mon Feb 3 20:55:57 2014 diff -r b6a6413ac3ca -r 2d6118b66367 paper/images/reconnection2.xbb --- a/paper/images/reconnection2.xbb Mon Feb 03 16:56:17 2014 +0900 +++ b/paper/images/reconnection2.xbb Mon Feb 03 22:14:54 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 487.000000 300.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Sun Feb 2 15:23:54 2014 +%%CreationDate: Mon Feb 3 20:55:57 2014 diff -r b6a6413ac3ca -r 2d6118b66367 paper/images/rfbProtocol.xbb --- a/paper/images/rfbProtocol.xbb Mon Feb 03 16:56:17 2014 +0900 +++ b/paper/images/rfbProtocol.xbb Mon Feb 03 22:14:54 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 434.000000 631.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Sun Feb 2 15:23:54 2014 +%%CreationDate: Mon Feb 3 20:55:57 2014 diff -r b6a6413ac3ca -r 2d6118b66367 paper/images/sendscreenimage.xbb --- a/paper/images/sendscreenimage.xbb Mon Feb 03 16:56:17 2014 +0900 +++ b/paper/images/sendscreenimage.xbb Mon Feb 03 22:14:54 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 268.000000 123.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Sun Feb 2 15:23:54 2014 +%%CreationDate: Mon Feb 3 20:55:57 2014 diff -r b6a6413ac3ca -r 2d6118b66367 paper/images/structureofTreeVNC.xbb --- a/paper/images/structureofTreeVNC.xbb Mon Feb 03 16:56:17 2014 +0900 +++ b/paper/images/structureofTreeVNC.xbb Mon Feb 03 22:14:54 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 492.000000 252.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Sun Feb 2 15:23:54 2014 +%%CreationDate: Mon Feb 3 20:55:57 2014 diff -r b6a6413ac3ca -r 2d6118b66367 paper/images/treestructure.xbb --- a/paper/images/treestructure.xbb Mon Feb 03 16:56:17 2014 +0900 +++ b/paper/images/treestructure.xbb Mon Feb 03 22:14:54 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 309.000000 256.000000 %%PDFVersion: 1.3 %%Pages: 1 -%%CreationDate: Sun Feb 2 15:23:54 2014 +%%CreationDate: Mon Feb 3 20:55:57 2014 diff -r b6a6413ac3ca -r 2d6118b66367 paper/images/treestructure_jp.xbb --- a/paper/images/treestructure_jp.xbb Mon Feb 03 16:56:17 2014 +0900 +++ b/paper/images/treestructure_jp.xbb Mon Feb 03 22:14:54 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 309.000000 256.000000 %%PDFVersion: 1.3 %%Pages: 1 -%%CreationDate: Sun Feb 2 15:23:54 2014 +%%CreationDate: Mon Feb 3 20:55:57 2014 diff -r b6a6413ac3ca -r 2d6118b66367 paper/images/vnc.xbb --- a/paper/images/vnc.xbb Mon Feb 03 16:56:17 2014 +0900 +++ b/paper/images/vnc.xbb Mon Feb 03 22:14:54 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 360.000000 194.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Sun Feb 2 15:23:54 2014 +%%CreationDate: Mon Feb 3 20:55:57 2014 diff -r b6a6413ac3ca -r 2d6118b66367 paper/master_paper.pdf Binary file paper/master_paper.pdf has changed