# HG changeset patch # User Taninari YU # Date 1391453401 -32400 # Node ID aec4085dd5db4ab21f5149f3ce68dc030cf85f15 # Parent 2d6118b663678e1dc7ee2ad9d2d8febdf5c5ef60 update diff -r 2d6118b66367 -r aec4085dd5db paper/abstract.tex --- a/paper/abstract.tex Mon Feb 03 22:14:54 2014 +0900 +++ b/paper/abstract.tex Tue Feb 04 03:50:01 2014 +0900 @@ -1,9 +1,9 @@ \begin{abstract} -各クライアントをツリー状に接続し、親が配信したデータを木の上から下へとリレーさせることのできる分散版VNC(TreeVNC)のアプリケーションを実装した。 -通常のVNCでは配信者へ負荷が集中する設計となっている。例えば、大学の講義等で従来のVNCを用いて画面共有を行った時、クライアントの増加に比例して配信者への負荷が増えてしまう。 -この問題を解決する為に、ツリー構造にクライアントを接続させ、データを上から下へ流していくことを提案した。 +各クライアントをツリー状に接続し、親が配信したデータを木の上から下へと流すことで負荷分散をすることができる分散版VNC(TreeVNC)のアプリケーションを実装を行った。VNCとはネットワークを介して画面を共有することができるアプリケーションである。 +従来のVNCでは配信者へ負荷が集中する設計となっている。大学の講義等でVNCを用いて画面共有を行うと、クライアントの増加に比例して配信者への負荷が増え処理性能が低下してしまう。 +この問題を解決する為に、ツリー構造にクライアントを接続させ、データを上から下へと流していく方法を提案した。 これにより、利用者が増加しても質を落とすことないスケーラビリティを持ったサービスを作成することができる。 -TreeVNCを使用した結果、クライアントの数を増やしてもサーバ側への負荷を抑えスループットを落とすことなく利用する事ができた。 +実際にTreeVNCを使用した結果、クライアントの数を増やしてもサーバ側への負荷を抑え、スループットを落とすことなく利用することができた。 本論文では、発表者の切り替えとマルチディスプレイの対応を行った。 %発表者をボタン一つで切り替えられるようにUserInterfaceの拡張を行い、マルチディスプレイを使用している場合、一つのディスプレイのデータを受け取ることができるようにマルチディスプレイのサポートも行った。 \end{abstract} diff -r 2d6118b66367 -r aec4085dd5db paper/chapter1.tex --- a/paper/chapter1.tex Mon Feb 03 22:14:54 2014 +0900 +++ b/paper/chapter1.tex Tue Feb 04 03:50:01 2014 +0900 @@ -1,16 +1,16 @@ \chapter{研究背景と目的} \pagenumbering{arabic} -授業を行う際、プロジェクタなどの投影機を使用して授業を進めることがよくある。しかし、広い部屋だと後ろの席に座っている生徒が見えにくいなどの不便を感じることがよくある。 -もし、授業を受けている学生の手元にパソコンがあるならば、手元のパソコンに先生の説明しているスライドを表示して授業を進めることでどこの席に座っていても、手元の画面に表示されるので見えづらいという問題は解決される。 -みんなの手元に先生の画面を配信するシステムとして、ビデオケーブルを引いて画面を配信する方法があり、このような方法で画面を配信するのが一般的である。しかし、この方法で画面共有をするには、工事を行ってビデオケーブル引かなければならないので、コストがかかってしまう。 -ビデオケーブルを引かずに、WEBページに授業のスライドを載せることで、ブラウザを共有することもできる。しかし、この場合は、ページが同期していないのでどのスライドを説明してるのかわからなくなるといった問題がある。 +授業を行う際、プロジェクタなどの投影機を使用して授業を進める場合が多い。しかし、広い部屋だと後ろの席に座っている生徒が見えにくいなどの不便を感じることがよくある。 +もし、授業を受けている学生の手元にパソコンがあるならば、手元のパソコンに先生の説明しているスライドを表示して授業を進めることでどこの席に座っていても、手元の画面に表示されているので見えづらいという問題は解決される。 +みんなの手元に先生の画面を配信するシステムとして、ビデオケーブルを引いて画面を配信する方法がある。しかし、この方法で画面共有をするには、工事を行ってビデオケーブル引かなければならないので、コストがかかってしまう。 +ビデオケーブルを引かずに、WEBページに授業のスライドを載せることで、Webページを共有することができる。しかし、この場合は、ページが同期していないので、どのスライドを説明してるのかわからなくなるといった問題が発生する。 プログラミングの授業などでは、先生がどのような作業をしているかがとても重要になってくるが、これはWEBページを使用しても実現することができない。 -これらの問題を解決するために、オープンソースなアプリケーションであるVNCを用いることで、画面を共有することができる。 -VNCとは、RFBプロトコルを使用して、画面のデータを配信するシステムである。RFBプロトコルとは -しかし、VNCは多人数で同時に接続してしまうと処理性能が落ちて授業の進行に画面がついていかなくなったり、アプリケーションの処理自体が止まってしまったりしてしまう。 -この問題の原因は一つのコンピュータに多人数が繋がるときに生じる問題である。 -そこで、多人数で画面共有ができるようにクライアントをツリー状に接続させ、上から順番にデータを流していく方法によって、VNCサーバに対する負荷を分散させることができると考えた。 -更に、ゼミでVNCを使用することを想定する。従来のVNCでは、発表者が変わるごとに新しくVNCに接続し直す必要がある。接続の手間を省くことで、ゼミをスムーズに進行させることができる。 +これらの問題は、オープンソースなアプリケーションであるVNCを用いることで解決することができる。 +VNCとは、RFBプロトコルを使用して、画面のデータを配信するシステムであり、RFBプロトコルは自身の画面をネットワークを介して他の画面に配信するためのプロトコルである。 +VNCは多人数で同時に接続してしまうと処理性能が落ちて授業の進行に画面がついていかなくなったり、アプリケーションの処理自体が止まってしまったりしてしまうという問題がある。 +この現象は一つのコンピュータに多人数が繋がるときに生じる問題である。 +クライアントをツリー状に接続させ、上から順番にデータを流していく方法によって、VNCサーバに対する負荷を分散させることができ、問題が解決できると考えた。 +ゼミでVNCを使用することを想定する。従来のVNCでは、発表者が変わるごとに新しくVNCに接続し直す必要がある。接続の手間を省くことで、ゼミをスムーズに進行させることができる。 本研究では、多人数で画面共有ができるようにクライアントをツリー構造に接続させ、上から順番にデータを流していく方法で、VNCサーバに対する負荷を分散させるTreeVNCを作成し、更に、ゼミなどで使いやすいようにユーザインタフェースの提案と実装を行う。 %先生のスライドを生徒の手元にあるパソコンに表示することができる。しかし、多人数の生徒が先生のパソコンに同時に接続してしまうと処理性能が落ちて授業の進行に画面がついていかなくなってしまう。 %更に当研究室では、VNCを使用してゼミを進めている。従来のVNCを使用すると発表者が変わるごとに新しくVNCを立ち上げ　直す必要がある。このような手間がなくなるとスムーズにゼミを進めることができる。\\ @@ -19,9 +19,9 @@ \newpage \section{本論文の構成} -本論文では、第２章でこれまでの画面共有システムについて説明し、その中で使用されているプロトコルについて述べ、VNCを授業で使用する際の問題点を挙げる。\\ -第３章では、第２章で挙げた問題点に対して考察を行い、Tree構造を使用した設計やユーザインターフェースの提案を行う。\\ -第４章では、第３章で設計した木構造を利用したTreeVNCの詳細な設計と実装方法そして、実装時の問題点とその解決方法ついて述べる。\\ +本論文では、第２章でこれまでの画面共有システムについて説明し、その中で使用されているプロトコルについて述べ、VNCを授業で使用する際の問題点を挙げる。 +第３章では、第２章で挙げた問題点に対して考察を行い、Tree構造を使用した設計やユーザインターフェースの提案を行う。 +第４章では、第３章で設計した木構造を利用したTreeVNCの詳細な設計と実装方法そして、実装時の問題点とその解決方法ついて述べる。 第５章では、卒業論文で作成したTreeVNCとの違いについて述べる。 第６章では、画面共有システムTreeVNCの評価を行い、作成したユーザインタフェースの妥当性について述べる。 第７章では、本研究のまとめとこれからの課題について述べる。 diff -r 2d6118b66367 -r aec4085dd5db paper/chapter2.tex --- a/paper/chapter2.tex Mon Feb 03 22:14:54 2014 +0900 +++ b/paper/chapter2.tex Tue Feb 04 03:50:01 2014 +0900 @@ -1,3 +1,4 @@ + \chapter{画面共有システム} この章では、従来画面共有で使用されているTightVNCとそれに使われてるRFBプロトコルについて説明する。その上で、多人数で使用する際の問題点を説明する。 @@ -51,7 +52,7 @@ \section{VNC Reflector} -VNCReflectorはサーバへの負荷を減らすように設計されているVNCソフトの一つである。 +VNC Reflectorはサーバへの負荷を減らすように設計されているVNCソフトの一つである。 Javaを用いて実装されており、フリーで入手することができる。 Vnc Reflectorは、Vncサーバとクライアントとの間に入り、VNCサーバとの通信を代わり に行うプログラムである。 @@ -78,7 +79,7 @@ \section{BroadcastとMulticastの可能性} Broadcastは同じネットワークアドレス(同一セグメント)上のすべての端末に対して、同時にデータを送信することである(図\ref{fig:broadcast})。 Multicastは同じマルチキャストアドレスを持った端末に同時にデータを送信することである(図\ref{fig:multicast})。 -画像データを配信する際にBroadcastやMulticastを用いて、画像データを送信すると、木構造を構成する必要がなくなり、画像データ送信も一回だけで良い。そこで、Broadcastを用いた実装について考察してみるo。 +画像データを配信する際にBroadcastやMulticastを用いて、画像データを送信すると、木構造を構成する必要がなくなり、画像データ送信も一回だけで良い。Broadcastを用いた実装について考察してみる。 \begin{figure}[!htbp] \begin{center} \includegraphics[width=110mm]{./images/broadcast.pdf} @@ -96,20 +97,20 @@ \end{figure} \subsection{Broadcastパケットの性質} -Broacdcastパケットの性質として大きすぎるデータの送信ができないという性質がある。どの程度の大きさのパケットまで送れるのかをテストしてみた結果64000byteまでだと送信することができることがわかった。 +Broacdcastパケットの性質として大きすぎるデータの送信ができないという性質がある。どの程度の大きさのパケットまで送れるかをテストしてみたところ、64000byteまでだと送信可能であることがわかった。 もう一つの性質にパケットが消失(ロスト)しても特定することができないという性質がある。 MulticastについてもBroadcastと同じ性質を持っている。 \subsection{消失したパケットの検出} -Broadcastの性質で説明したとおり、Broadcastではデータが消失したことをクライアントが検出することができない。そこでプロトコルを拡張し、データごとにシリアル番号を振り、連続でない値が来た場合、正しくデータが届いていないと判断することができる。 +Broadcastの性質で説明したとおり、Broadcastではデータが消失したことをクライアントが検出することができない。そこでプロトコルを拡張し、データごとにシリアル番号を振り、連続でない値が来た場合、正しくデータが届いていないと判断し、データの消失を検出することができる。 \subsection{Acknowledgeの設計} -データが消失したのを検出した際、どのような対応をするのかが問題になる。シリアル番号を振っているのでプロキシに消失したデータのシリアル番号を指定することで、消失したデータの再送が可能となる。この際、再送にBroadcastを用いると、データの消失が起こるので、消失したデータを再送する際はTCPコネクションを用いて送信を行うのが良い。 +データが消失したのを検出した際、どのような対応をとるのかが問題になる。シリアル番号を振っているのでサーバ対して、消失したデータのシリアル番号を指定することで、消失したデータの再送が可能となる。この際、再送にBroadcastを用いると、またデータの消失が起こるので、消失したデータを再送する際はTCPコネクションを用いて送信を行うのが良い。 \subsection{Broadcastを使用した送信} -Broadcastを使用する場合は一回に送信するパケットのサイズを64000byte以下にしなければならない。もし、1920*1080のサイズの画像データを送信する際、約600万byte(1920*1080*3)となってしまう。これでは送信することができないのでデータを分割し64000byte以下にして送信しなければならない。 +Broadcastを使用する場合は一度に送信するパケットのサイズを64000byte以下にしなければならない。もし、1920*1080のサイズの画像データを送信する際、約600万byte(1920*1080*3)となってしまう。これでは送信することができないのでデータを分割し64000byte以下にして送信しなければならない。 作成したTreeVNCでは、サーバから受け取った画像データをRoot Nodeが一旦解凍して、再圧縮し、Nodeへ送信するという方式を取っている。 -一旦解凍した後はRawDataとなるのでデータを分割することができる。TreeVNCではZRLEエンコーディングを使用して、これを解凍すると左から右へ上から下への順の64*64のタイル群のRawDataとなる。 +一旦解凍した後はRawDataとなるのでデータを分割することができる。TreeVNCではZRLEエンコーディングを使用している。ZRLE解凍すると左から右へ上から下への順の64*64のタイル群のRawDataとなる。 解凍されたRawDataを図\ref{fig:rawdata}に示す。 @@ -121,11 +122,11 @@ \label{fig:rawdata} \end{figure} -テストで、\ref{fig:comparenormalandtree}のように2列づつに分割して送信するプログラムを書いた(Listing\ref{src:blocking})。 -毎回バッファをコピーして送っているため画面共有に支障をきたすほど処理が遅くなってしまった。 +テストで、図\ref{fig:comparenormalandtree}のように2列づつに分割して送信するプログラムを書いた。 +書いたテストプログラムでは、毎回バッファをコピーして送っているため処理が重かった。 -BroadcastとMulticastでどのくらいパケットロスするのかもテストを行った。 -BroadcastとMulticastを用いてそれぞれのbyte数を100packetずつ送信しパケットロス率を表したのが表\ref{tb:testofbroadcastandmulticast}である。 +BroadcastとMulticastでどのくらいパケットロスするかのテストも行った。 +BroadcastとMulticastを用いてそれぞれのbyte数を100packetずつ送信しパケットのロス率を測った。その結果を表したのが表\ref{tb:testofbroadcastandmulticast}である。 表\ref{tb:testofbroadcastandmulticast}にあるようにMulticastを用いても、4000byteを100packet続けて送信すると37\%もパケットロスしてしまう。 \begin{table}[htbp] @@ -140,7 +141,9 @@ \end{center} \end{table} -結果として、データ分割の処理が重い、且つ予想以上のパケットロス率という結果をになったので、BraodcastやMulticastを用いた実装を行うことはもう少し工夫が必要になることがわかった。 + + +結果として、データ分割の処理が重い、且つ予想以上のパケットロス率という結果をになったので、BraodcastやMulticastを用いた実装にはもう少し工夫が必要だということがわかった。 diff -r 2d6118b66367 -r aec4085dd5db paper/chapter3.tex --- a/paper/chapter3.tex Mon Feb 03 22:14:54 2014 +0900 +++ b/paper/chapter3.tex Tue Feb 04 03:50:01 2014 +0900 @@ -1,8 +1,8 @@ \chapter{画面共有システムTreeVNCの設計} \section{木構造を用いたTreeVNCの設計} -多人数が参加している授業でVNCを使う場合に起こる問題は、一つのコンピュータに多人数が繋がり、処理が集中してしまって、性能が大幅に落ちてしまうところである(図\ref{fig:vnc})。 -多人数の同時接続を可能にするには、一極集中で接続するのではなく、Node同士で負荷を分散させることによって実現できるのではないかと考えた。\\ +多人数が参加している授業でVNCを使う場合に起こる問題は、一つのコンピュータに多人数で同時につながり、処理が集中してしまって、性能が大幅に落ちてしまうところである(図\ref{fig:vnc})。 +多人数の同時接続を可能にするには、一極集中で接続するのではなく接続を分散させることが必要である。そこで、Node同士で接続を行うことによって負荷分散をすることが実現できるのではないかと考えた。\\ 負荷分散を行う際、Node同士どのようなトポロジを組むのが適切か検討した結果、上から流れてきたデータを下のNodeへと伝えていくことのできる木構造が良いと考えた。\\ 　今回行った設計ではNodeを木構造に接続させデータを流すためにサーバとNodeの間にRoot Node(サーバとNodeの通信を仲介するもの)を設置する方式をとった。Root Nodeは主にNodeの管理とServerから流れてきた画像データの管理を担当する。\\ 木構造で設計したものを(図\ref{fig:treestructure})に示す。\\ @@ -28,8 +28,7 @@ \newpage \section{TreeVNCの原理} -従来VNCでは、一極集中型でサーバに接続してしまうのでサーバに負荷がかかって性能を低下させたり停止してしまっている。そこでNodeを木構造に配置させることで、サーバへの負荷が減る。 -従来VNCとTreeVNCの構造を比較した図を(図\ref{fig:comparenormalandtree})に示す。\\ +従来のVNCとTreeVNCの構造を比較した図を(図\ref{fig:comparenormalandtree})に示す。\\ \begin{figure}[!htbp] \begin{center} @@ -41,8 +40,8 @@ (表\ref{tb:oneporttraffic})はポート一本あたりの通信量である。\\ -表から推察できるように、ポート一本あたりの負荷は通常のVNCの場合はNode数に比例して増えている。しかしTreeVNCの場合はTreeの子供の数が一定なので、Node数に関係なく一定である。\\ -送信する量も通常のVNCの場合Node数に比例した量のデータ送信しなければならいので、CPUに負荷がかかり性能が低下したり停止したりしている。\\ +表から推察できるように、ポート一本あたりの負荷は従来のVNCの場合はNode数に比例して増えている。しかしTreeVNCの場合はTreeの子供の数が一定なので、Node数に関係なく一定である。\\ +送信する量も通常のVNCの場合、Node数に比例した量のデータ送信しなければならいので、CPUに負荷がかかり性能が低下したり停止したりしている。\\ 対してTreeVNCはが増えても配信するデータは一定なので性能が低下せず使用することができる。 \begin{table}[htbp] @@ -50,21 +49,21 @@ \label{tb:oneporttraffic} \begin{center} \begin{tabular}{|c|c|c|} \hline - & 通常のVNC & TreeVNC \\ \hline + & 従来のVNC & TreeVNC \\ \hline 通信量 & N * データ量 & (M + 1) * データ量 \\ \hline \end{tabular} \end{center} \end{table} - +\newpage %\section{画面拡大縮小} %\section{画面描画範囲の指定} \subsection{木の生成} -負荷を分散させるために木構造を用いるので、Nodeをツリー状に接続する仕組みが必要である。TreeVNCでは、以下の点順で、木の構成を行う。\\ +負荷を分散させるために木構造を用いるので、Nodeをツリー状に接続する仕組みが必要である。TreeVNCでは、以下の手順で、木の構成を行う。 図\ref{fig:createtree}は、２分木で木を構成する際の手続きを示したシーケンスダイアグラムである。\\ -1.初めにNodeはRoot Nodeに接続先IPを尋ねる(Where connect)。\\ +1.初めにNodeはRoot Nodeに接続先IPを尋ねる(Where to connect?)。\\ 2.Root Nodeは、Nodeに接続するべきホストのIPを引き渡す(Answer)。\\ 3.Nodeは指定されたホストに接続する(Connect)。 @@ -118,7 +117,7 @@ \newpage \section{表示画面の切り替え} VNCを使用して画面共有を行う場合、授業では、唯一講師の画面を共有する。しかし、ゼミなど発表者が多数いる場合は画面共有の対象を切り替えたいことがある。画面共有対象の切り替えを行う場合、発表者ごとにサーバを立ち上げ直さなければならないという問題が発生する。そこで、ユーザ側からRoot Nodeにリクエストを出して、画面共有の対象を切り替える機能が必要になる。 -画面を切り替えるときは、Root Nodeだけが接続を切り替え、他のNodeのトポロジの変更はない(図\ref{fig:change})。 +TreeVNCで画面を切り替えるときは、Root Nodeだけが接続を切り替え、他のNodeのトポロジの変更はない(図\ref{fig:change})。 \begin{figure}[!htbp] \begin{center} @@ -131,16 +130,15 @@ \newpage \section{マルチディスプレイの対応} -マルチディスプレイを用いてVNCを行うと、すべてのディスプレイのデータが繋がって表示されてしまう。通常発表などに使用されるディスプレイは一つである。すべての画面のデータを送ってしまうとその分だけ無駄なデータを送っていることになる。そこで、発表用に使用する画面のデータだけを送ることのできるようにディスプレイを指定する機能が必要になる。 +マルチディスプレイを用いてVNCを行うと、すべてのディスプレイのデータが繋がって表示されてしまう。通常、発表などに使用されるディスプレイは一つである。すべての画面のデータを送ってしまうとその分だけ無駄なデータを送っていることになる。そこで、発表用に使用する画面のデータだけを送ることのできるようにディスプレイを指定する機能が必要になる。 \section{木の再構成} -木を構成することはできたが途中のNodeが切断してしまった場合に木を再構成しなければならない。 -木を再構成する手順は以下の用に行う。 +TreeVNCは木構造で接続しているので親Nodeが切断してしまった場合に木を再構成しなければならない。 +木を再構成する手順は以下のようにして行う。 　\begin{enumerate} \item 子供のリーダー(最初に親につないだ子供)が親が落ちたことをRoot Nodeに対して報告する。 -　\item Root Nodeは報告を受けると番号の一番大きいNode(最後のNode)に対して落ちた親の代\ -わりになるように報告する。 +　\item Root Nodeは報告を受けると番号の一番大きいNode(最後のNode)に対して落ちた親の代わりになるように報告する。 　\item Root Nodeから命令を受けたNodeは指定されたNodeに接続をしなおす。 　\item Root NodeはNodeのリストを更新して、親が落ちた子供たちに新しい親の情報を教える。 　\item 親が切断された子供たちは、Root Nodeからもらった情報を元に新しい親に対して接続を行う。 @@ -180,7 +178,7 @@ 6:replyChildlen()は、親が切断した子供たちに対して新しい親の情報を報告する関数である。\\ -7:reConnection()はRoot Nodeから来た情報をもとにVNC接続を行う関数である。 +7:reConnection()はRoot Nodeから来た情報をもとにVNC接続を行う関数である。\\ 以上の関数を用いることでNodeが落ちても木を再構成することができる。 @@ -234,11 +232,11 @@ メモリにデータが残り続けるとMemory Over Flowを起こしてしまう。 その様子を図\ref{fig:TimeOut}を用いて説明する。 Parentは流れてきたFramebufferUpdateをMulticastQueueの中に追加して行く。 -MulticastQueは要素ごとにCountDownLatchを持っていて、Childがデータを読み込むとCountDownを行い。Countが0になるとデータを削除する。 +MulticastQueueは要素ごとにCountDownLatchを持っていて、Childがデータを読み込むとCountDownを行い、Countが0になるとデータを削除する。 ParentはChildが画像を受け取るまでMulticastQueueの中に持っているFramebufferUpdateを削除することができない。 Childがサスペンド状態になった場合、MulticastQueueの中にあるFramebufferUpdateを削除することができないのでメモリを圧迫してしまいMemory Over Flowを起こしてしまう。 そこで、ある一定の時間が経過すると代わりにデータを取得してくれるTimeOut用のスレッドを作成した。 -TimeOutスレッドはサスペンドしているNodeの代わりにFramebufferUpdateを取得する。 +TimeOutスレッドはサスペンドしているNodeの代わりにFramebufferUpdateを取得する。TimeOutスレッドによりMemory Over Flowを防ぐことができる。 \begin{figure}[tb] @@ -256,8 +254,8 @@ \section{圧縮の問題} -VNCで扱うRFB プロトコルには、使えるエンコーディングのタイプの1つとしてZRLE(Zlib Run-Length Encoding)がある。 -ZRLEはZlibで圧縮されたデータとそのデータのバイト数がヘッダーとして付けられ送られてくる。 +RFBの使えるエンコーディングタイプの1つとして、ZRLE(Zlib Run-Length Encoding)がある。 +ZRLEはZlibで圧縮されたデータとそのデータ長さがヘッダーとして付けられ送られてくる。 Zlibはフリーのデータ圧縮及び解凍を行うライブラリである。 可逆圧縮アルゴリズムの圧縮と解凍が行えるjava.util.zip.deflaterとjava.util.zip.inflaterを実装している。 @@ -314,9 +312,9 @@ \subsection{接続先自動検索システム} -NodeがRoot Nodeに接続する際、Root NodeのIPアドレスを指定する必要がある。IPアドレスを毎回入力するのは手間がかかる上、間違うと接続することができない。\\ -そこで、Nodeが起動した際に、起動しているTreeVNCのRoot Nodeを検索し、IPアドレスの情報を取得し、一覧にして選択させることによって直接アドレスを手入力する必要がなくなる。\\ -TreeVNCのRoot Nodeを検索する際には、Broadcast通信を用いることによって実現することができる。\\ +NodeがRoot Nodeに接続する際、Root NodeのIPアドレスを指定する必要がある。IPアドレスを毎回入力するのは手間がかかる上、間違う可能性もあるのでよくない。 +そこで、Nodeが起動した際に、起動しているTreeVNCのRoot Nodeを検索し、IPアドレスの情報を取得し、一覧にして選択して接続できるようにすることで、直接アドレスを手入力する必要がなくなる。 +TreeVNCのRoot Nodeを検索する際には、Broadcast通信を用いることによって実現することができる。 diff -r 2d6118b66367 -r aec4085dd5db paper/chapter4.tex --- a/paper/chapter4.tex Mon Feb 03 22:14:54 2014 +0900 +++ b/paper/chapter4.tex Tue Feb 04 03:50:01 2014 +0900 @@ -1,12 +1,14 @@ \chapter{画面共有システムTreeVNCの実装} \section{TightVNCのアップデートへの対応} -TightVNCは現在も開発が続いていて、アップデートされている。このアップデートに対応するために、私が作成しているTreeVNCにも対応させる必要がある。\\ -卒業論文後から私は２種類のアップデートを行った。その２種類のアップデートの対応について説明する。\\ -はじめに行ったアップデートはVersionが1.3.10から2.5.0へ変わるメジャーアップデートと呼ばれる大型アップデートである。\\ -このアップデートでは、パッケージ構成が追加され、元のソースコードがほとんど残っていない状態であった。このような大型なアップデートに対応するには、新しいTightVNCを元にして、作成したTreeVNCの機能を一つづつ移行していく必要がある。このソースコードのアップデートに加えソースコードの質を高めるためにリファクタリングを行った。 +TightVNCは現在も開発が続いていて、アップデートされている。このアップデートに対応するために、私が作成しているTreeVNCにも対応させる必要がある。 +卒業論文後から私は２種類のアップデートを行った。その２種類のアップデートの対応について説明する。 +はじめに行ったアップデートはVersionが1.3.10からVersion2.5.0へ変わる大型アップデートである。 +このアップデートでは、パッケージ構成が追加され、元のソースコードがほとんど残っていない状態であった。このような大型なアップデートに対応するには、新しいTightVNCを元にして、作成したTreeVNCの機能を一つずつ移行していく必要がある。 +アップデートに加えソースコードの質を高めるためにリファクタリングを行った。 リファクタリングとは、将来の仕様変更に柔軟に対応できるようにソースコードの手直しを行うことである。 - +次に行ったアップデートはVersion2.5.0からVersion2.7.2へ変わるアップデートである。 +このアップデートは、パッケージ構成も変わらず、変更が少量であったので、Mercuriaのmerge機能を用いて手軽にアップデートすることができた。 \section{UIの実装} @@ -27,7 +29,7 @@ \end{center} \end{table} -この後にnumber-of-rectanglesの数だけ矩形のピクセルデータが続く。各矩形は(表\ref{tb:framebufferupdate2})に示す。 +この後にnumber-of-rectanglesの数だけ矩形のピクセルデータが続く。ピクセルデータを(表\ref{tb:framebufferupdate2})に示す。 \begin{table}[htbp] \caption{FramebufferUpdate} @@ -46,7 +48,7 @@ ここまでがheaderとして送信されるデータである。矩形の画像なのでx-position、y-position、width、heightの４つの値で画像の位置と大きさを決めることができる。\\ headerに続いて、実際の画像データが送信されてくる。\\ -画像データはZRLEエンコーディングで送信される。最初の4バイトはデータの大きさを表現して、次にその大きさ分のzlibDataが送信される(表\ref{tb:ZRLE})。 +画像データはZRLEエンコーディングで送信される。最初の4バイトはデータの長さを表現して、次にその大きさ分のzlibDataが送信される(表\ref{tb:ZRLE})。 \begin{table}[htbp] \caption{ZRLEデータ} @@ -60,8 +62,8 @@ \end{center} \end{table} +\subsection{マルチディスプレイへの対応} 送られてきたzlibDataは展開されると左から右、上から下へ並んだ、64*64ピクセルのタイル群画像データとなる。 - ここで、画像データがどのように送られてくるのかを調べてみたところ、２つディスプレイがあるとすると、両ディスプレイにまたがった画像更新が来ることがないことがわかった。\\ 図\ref{fig:rawdata}の黒い部分が画像データだとすると、図\ref{fig:rawdata}のようなFramebufferUpdateは送られてくることはない。 @@ -72,9 +74,8 @@ \caption{画面更新時に来る可能性のないUpdateRectangle} \label{fig:sendscreenimage} \end{figure} -\subsection{マルチディスプレイへの対応} -VNCでは画面の情報を矩形型にして送信する。もし複数のディスプレイが存在する場合すべてのディスプレイの情報が送られてくる。しかし、発表などに使用するディスプレイは一つである場合が多い。\\ -必要な画像が一つのディスプレイなのに、すべてのディスプレイのデータを送ると無駄なデータが発生する。そこで、ディスプレイを指定して、その画像だけ送信する機能を追加することで、無駄なデータ送信を省くことができる。 +VNCでは、複数のディスプレイが存在する場合、すべてのディスプレイの情報が送られてくる。しかし、発表などに使用するディスプレイは一つである場合が多い。\\ +必要な画面が一つのディスプレイなのに、すべてのディスプレイのデータを送ると無駄なデータを送信していることになる。そこで、ディスプレイを指定して、その画像だけ送信する機能を追加することで、無駄なデータ送信を省くことができる。 diff -r 2d6118b66367 -r aec4085dd5db paper/chapter5.tex --- a/paper/chapter5.tex Mon Feb 03 22:14:54 2014 +0900 +++ b/paper/chapter5.tex Tue Feb 04 03:50:01 2014 +0900 @@ -14,7 +14,7 @@ \section{マルチディスプレイへの対応} マルチディスプレイを使用すると、すべてのディスプレイ情報が送信されていたが、現在は一つのディスプレイの情報だけを送ることが可能となったので、無駄なデータを省くことができる。 -これにより、Queueに保存している画像の大きさも小さくなるので、メモリの節約の役割も果たしている。 +これにより、MulticastQueueに保存している画像の大きさも小さくなるので、メモリの節約の役割も果たしている。 \section{リファクタリングの容易化} TreeVNCは今までサーバ側とNode側に同じようなプログラムが２つあり、コードをリファクタリングが困難であった。 diff -r 2d6118b66367 -r aec4085dd5db paper/chapter6.tex --- a/paper/chapter6.tex Mon Feb 03 22:14:54 2014 +0900 +++ b/paper/chapter6.tex Tue Feb 04 03:50:01 2014 +0900 @@ -53,7 +53,7 @@ \end{lstlisting} \subsection{Capistrano} -今回の実験では、48台のサーバ上でCUI版のTreeVNCを立ち上げる必要がある。実験する度に、各サーバに一つ一つにログインしてアプリケーションを立ち上げるのは手間がかかりすぎてしまう。Capistranoを使用することで、この問題を解決することができる。\\ +今回の実験では、48台のサーバ上でCUI版のTreeVNCを立ち上げる必要がある。実験する度に、各サーバにログインしてアプリケーションを立ち上げるのは手間がかかりすぎてしまう。Capistranoを使用することで、この問題を解決することができる。\\ Capistranoは複数のサーバ上で同時に処理を実行するためのオープンソースなソフトウェアであり、Rubyを用いて作成されている。\\ Capistranoを実行する際に使用するスクリプトをListing\ref{src:capistrano}に示す。\\ @@ -75,9 +75,9 @@ \end{lstlisting} \section{木の深さによる遅延} -TreeVNCは、クライアントを木構造に配置し画像を配信している。\\ +TreeVNCは、クライアントを木構造に配置し画像を配信している。 木の深さが深くなってしまうと、データが下に届くまでに遅延が発生してしまう可能性がある。 -そこで、木の深さによる遅延がどの程度発生するのかを測定してみた。\\ +そこで、木の深さによる遅延がどの程度発生するのかを測定してみた。 \subsection{遅延の測定方法} RFBプロトコルでは、送られてくるデータの先頭にどのような処理をするかの命令番号が入っている。\\ 表\ref{tb:message}は送られてくるメッセージの一覧である。\\ @@ -97,10 +97,10 @@ \end{center} \end{table} -Listing\ref{src:delay_cli}、Listing\ref{src:delay_serv}は遅延を測るためのプログラムである。 -Root NodeはSystem.currentTimeMillis()を用いて時間を取得し、Nodeへ送信する。\\ -System.currentTimeMillis()は、システムの現在時刻をミリ秒（long型の数値）で取得する関数である。\\ -Nodeはこの値を受け取ると、そのままサーバへ受け取った値を返す。\\ +Listing\ref{src:delay_cli}、Listing\ref{src:delay_serv}は遅延を測るためのプログラムである。\\ +Root NodeはSystem.currentTimeMillis()を用いて時間を取得し、Nodeへ送信する。 +System.currentTimeMillis()は、システムの現在時刻をミリ秒（long型の数値）で取得する関数である。 +Nodeはこの値を受け取ると、そのままサーバへ受け取った値を返す。 Root Nodeはクライアントからの返信を受け取るとSystem.currentTimeMillis()を取り、差分を出してDelayを求める。 遅延を測る頻度は、画像を50回送信するごとに1回である。 \begin{lstlisting}[language=java,frame=lrbt,label=src:delay_cli,caption=遅延を測るプログラム,numbers=left] @@ -131,13 +131,26 @@ \end{center} \end{table} -並列計算環境のVMは高速なネットワークでつながっているので、遅延が少ない可能性がある。 -そこで、実際にOSの授業で、どの程度の遅延があるのかを測ってみた。\\ -OSの際は25Nodeであったので、段数にすると5段である。 -結果は、164ミリ秒と並列計算環境より良い結果が出た。\\ +\begin{figure}[!htbp] +\begin{flushleft} +\includegraphics[scale = 0.8]{images/graph-lost.pdf} +\end{flushleft} +\caption{ + 段差(step)によるデータの遅延 +} +\label{fig:graph-late} +\end{figure} +並列計算環境のVMは高速なネットワークでつながっているので、遅延が少ない可能性がある。 +そこで、実際にOSの授業で、どの程度の遅延があるのかを測定してみた。\\ +OSの授業のときは25Nodeであったので、段数にすると5段である。 +結果は、164ミリ秒と並列計算環境より良い結果が出た。 +図\ref{fig:graph-late} は遅延の分布を示したヒストグラムである。X軸は試行の回数で、Y軸は遅延(ミリ秒)を表している。\\ + + +\newpage \section{画面のフリーズ} データがTimeOutによってどの程度損失しているのかを調べてみた。\\ 今回、測定するために画像データのヘッダーの前にシリアルナンバーを付加した(Listing\ref{src:serial})。これによりNode側は、順番通りに画像が来なかった場合、データが損失したことを知ることができる。 @@ -175,9 +188,8 @@ \section{分木の最適化} 木の分木数が少ないほうが一つ一つのコンピュータにかかるCPU負荷が少なくなる。しかし、分木数を少なくしてしまうと、Nodeが増えたとき、木の深さが深くなり、データの伝搬に遅延が起こる可能性がある。 -上記の実験の結果、木の深さが6のときのデータ伝搬に平均139ミリ秒(0.139秒)の遅延しか起こっていなく、データの欠損も見られなかった。 +上記の実験の結果、木の深さが6のときのデータ伝搬に最遅446ミリ秒(0.446秒)の遅延しか起こっていなく、データの欠損も見られなかった。 分木数を変更してもコネクションの数はかわらないし、スイッチに対する負荷も変わらない。よって、100人程度で使用する場合は２分木が最適であるということがわかった。 -\newpage \section{ZRLEとZRLEEのデータ圧縮率の比較} 作成したTreeVNCでは、従来のVNCで使用されているエンコードを使用しておらず、独自で作成しているZRLEEエンコードを使用している。\\一見ZRLEは辞書が一つでZRLEEは辞書が一つ一つの画像データに付加されていて、データ量はZRLEEのほうが多くなってしまっている可能性があるので、ZRLEEとZRLEのデータ量にどの程度の差が出るのかを調べてみた。 diff -r 2d6118b66367 -r aec4085dd5db paper/conclusion.tex --- a/paper/conclusion.tex Mon Feb 03 22:14:54 2014 +0900 +++ b/paper/conclusion.tex Tue Feb 04 03:50:01 2014 +0900 @@ -6,7 +6,7 @@ 実装を行っていく中で必要になる、新しいEncodingタイプZRLLEの開発、木の再構成の機能、MulticastQueue等の機能が必要だとわかったので、これらの設計を行い実装を行った。 更に、TreeVNCをゼミで使用した際、画面の切り替え機能、ディスプレイの指定機能などが必要だと感じたので、それらの設計、実装を行った。 検証では、学科で用意されている並列計算環境を使用して、木のRoot Nodeから一番下のNodeまでの画像送信の遅延やTimeOutThreadによる画像のロスト率の検証を行い、木の分岐数の最適化について考察を行った。 -それから、実装した画面切り替えUIの妥当性について考察を行った。 +それから、開発したエンコードZRLEEとZRLEのデータ量の比較を行った。 @@ -17,6 +17,7 @@ Java6までは、圧縮を行うライブラリDeflaterにflushの機能がなく、TreeVNCでは独自のEncoding、ZRLEEを作成する必要があった。 しかし、ZRLEEを使用すると、通常のVNCでは、データをdecodeすることができないので、Javaを実行できないIPadなどではTreeVNCを使用することができない。 そこで、Java7から実装されたDeflaterのflush機能を使用して、ZRLEEをZRLEに変換することで、通常のVNCでdecodeすることができるようになる。 +それにより、Javaの実行環境を持たない端末の使用も可能になる。 \subsection{Multicast対応} Broadcastはパケットロス率が高すぎるので使用することは難しいが、Multicastのロス率だと、うまくいく見込がある。 @@ -28,6 +29,6 @@ 画像データは、一旦Root Nodeで解凍されるので、headerの情報を読み込み、適切なサイズに画像を加工し、headerを適切な値に変更することで、画面の範囲を指定できるようになる。 TreeVNCでは、画像の配信にMulticastQueueを使用している。 高解像度のディスプレイを使用すると、MulticastQueueのデータ量が増えてしまい、Memory Over Flowを起こす可能性がある。 -画面範囲の指定ができるようになれば、Mac Book Retina等の高解像度ディスプレイでも安定して画面共有をすることができるようになる。 +画面範囲の指定ができるようになれば、データ量を減らすことができるので、Mac Book Retina等の高解像度ディスプレイでも安定して画面共有をすることができるようになる。 diff -r 2d6118b66367 -r aec4085dd5db paper/images/TimeOut.xbb --- a/paper/images/TimeOut.xbb Mon Feb 03 22:14:54 2014 +0900 +++ b/paper/images/TimeOut.xbb Tue Feb 04 03:50:01 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 321.000000 318.000000 %%PDFVersion: 1.3 %%Pages: 1 -%%CreationDate: Mon Feb 3 20:55:57 2014 +%%CreationDate: Tue Feb 4 01:12:37 2014 diff -r 2d6118b66367 -r aec4085dd5db paper/images/TimeOut2.xbb --- a/paper/images/TimeOut2.xbb Mon Feb 03 22:14:54 2014 +0900 +++ b/paper/images/TimeOut2.xbb Tue Feb 04 03:50:01 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 433.000000 313.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Mon Feb 3 20:55:57 2014 +%%CreationDate: Tue Feb 4 01:12:37 2014 diff -r 2d6118b66367 -r aec4085dd5db paper/images/ZRLE.xbb --- a/paper/images/ZRLE.xbb Mon Feb 03 22:14:54 2014 +0900 +++ b/paper/images/ZRLE.xbb Tue Feb 04 03:50:01 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 356.000000 262.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Mon Feb 3 20:55:57 2014 +%%CreationDate: Tue Feb 4 01:12:37 2014 diff -r 2d6118b66367 -r aec4085dd5db paper/images/ZRLE2.xbb --- a/paper/images/ZRLE2.xbb Mon Feb 03 22:14:54 2014 +0900 +++ b/paper/images/ZRLE2.xbb Tue Feb 04 03:50:01 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 356.000000 262.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Mon Feb 3 20:55:57 2014 +%%CreationDate: Tue Feb 4 01:12:37 2014 diff -r 2d6118b66367 -r aec4085dd5db paper/images/ZRLEE.xbb --- a/paper/images/ZRLEE.xbb Mon Feb 03 22:14:54 2014 +0900 +++ b/paper/images/ZRLEE.xbb Tue Feb 04 03:50:01 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 414.000000 354.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Mon Feb 3 20:55:57 2014 +%%CreationDate: Tue Feb 4 01:12:37 2014 diff -r 2d6118b66367 -r aec4085dd5db paper/images/ZRLEE2.xbb --- a/paper/images/ZRLEE2.xbb Mon Feb 03 22:14:54 2014 +0900 +++ b/paper/images/ZRLEE2.xbb Tue Feb 04 03:50:01 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 476.934000 281.961000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Mon Feb 3 20:55:57 2014 +%%CreationDate: Tue Feb 4 01:12:37 2014 diff -r 2d6118b66367 -r aec4085dd5db paper/images/auth.xbb --- a/paper/images/auth.xbb Mon Feb 03 22:14:54 2014 +0900 +++ b/paper/images/auth.xbb Tue Feb 04 03:50:01 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 360.000000 194.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Mon Feb 3 20:55:57 2014 +%%CreationDate: Tue Feb 4 01:12:37 2014 diff -r 2d6118b66367 -r aec4085dd5db paper/images/broadcast.xbb --- a/paper/images/broadcast.xbb Mon Feb 03 22:14:54 2014 +0900 +++ b/paper/images/broadcast.xbb Tue Feb 04 03:50:01 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 458.000000 303.000000 %%PDFVersion: 1.3 %%Pages: 1 -%%CreationDate: Mon Feb 3 20:55:57 2014 +%%CreationDate: Tue Feb 4 01:12:37 2014 diff -r 2d6118b66367 -r aec4085dd5db paper/images/changeserver.xbb --- a/paper/images/changeserver.xbb Mon Feb 03 22:14:54 2014 +0900 +++ b/paper/images/changeserver.xbb Tue Feb 04 03:50:01 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 280.000000 251.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Mon Feb 3 20:55:57 2014 +%%CreationDate: Tue Feb 4 01:12:37 2014 diff -r 2d6118b66367 -r aec4085dd5db paper/images/changevncserver.xbb --- a/paper/images/changevncserver.xbb Mon Feb 03 22:14:54 2014 +0900 +++ b/paper/images/changevncserver.xbb Tue Feb 04 03:50:01 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 606.000000 475.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Mon Feb 3 20:55:57 2014 +%%CreationDate: Tue Feb 4 01:12:37 2014 diff -r 2d6118b66367 -r aec4085dd5db paper/images/compare_encoding.xbb --- a/paper/images/compare_encoding.xbb Mon Feb 03 22:14:54 2014 +0900 +++ b/paper/images/compare_encoding.xbb Tue Feb 04 03:50:01 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 432.000000 302.000000 %%PDFVersion: 1.3 %%Pages: 1 -%%CreationDate: Mon Feb 3 20:55:57 2014 +%%CreationDate: Tue Feb 4 01:12:37 2014 diff -r 2d6118b66367 -r aec4085dd5db paper/images/comparenormalandtree.xbb --- a/paper/images/comparenormalandtree.xbb Mon Feb 03 22:14:54 2014 +0900 +++ b/paper/images/comparenormalandtree.xbb Tue Feb 04 03:50:01 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 492.000000 252.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Mon Feb 3 20:55:57 2014 +%%CreationDate: Tue Feb 4 01:12:37 2014 diff -r 2d6118b66367 -r aec4085dd5db paper/images/countdownlatch.xbb --- a/paper/images/countdownlatch.xbb Mon Feb 03 22:14:54 2014 +0900 +++ b/paper/images/countdownlatch.xbb Tue Feb 04 03:50:01 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 308.000000 230.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Mon Feb 3 20:55:57 2014 +%%CreationDate: Tue Feb 4 01:12:37 2014 diff -r 2d6118b66367 -r aec4085dd5db paper/images/createtree.pdf Binary file paper/images/createtree.pdf has changed diff -r 2d6118b66367 -r aec4085dd5db paper/images/createtree.xbb --- a/paper/images/createtree.xbb Mon Feb 03 22:14:54 2014 +0900 +++ b/paper/images/createtree.xbb Tue Feb 04 03:50:01 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 541.000000 395.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Mon Feb 3 20:55:57 2014 +%%CreationDate: Tue Feb 4 01:12:37 2014 diff -r 2d6118b66367 -r aec4085dd5db paper/images/multicast.xbb --- a/paper/images/multicast.xbb Mon Feb 03 22:14:54 2014 +0900 +++ b/paper/images/multicast.xbb Tue Feb 04 03:50:01 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 458.000000 303.000000 %%PDFVersion: 1.3 %%Pages: 1 -%%CreationDate: Mon Feb 3 20:55:57 2014 +%%CreationDate: Tue Feb 4 01:12:37 2014 diff -r 2d6118b66367 -r aec4085dd5db paper/images/multicastqueue.xbb --- a/paper/images/multicastqueue.xbb Mon Feb 03 22:14:54 2014 +0900 +++ b/paper/images/multicastqueue.xbb Tue Feb 04 03:50:01 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 480.000000 267.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Mon Feb 3 20:55:57 2014 +%%CreationDate: Tue Feb 4 01:12:37 2014 diff -r 2d6118b66367 -r aec4085dd5db paper/images/multicastqueue2.xbb --- a/paper/images/multicastqueue2.xbb Mon Feb 03 22:14:54 2014 +0900 +++ b/paper/images/multicastqueue2.xbb Tue Feb 04 03:50:01 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 480.000000 267.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Mon Feb 3 20:55:57 2014 +%%CreationDate: Tue Feb 4 01:12:37 2014 diff -r 2d6118b66367 -r aec4085dd5db paper/images/rawdata.xbb --- a/paper/images/rawdata.xbb Mon Feb 03 22:14:54 2014 +0900 +++ b/paper/images/rawdata.xbb Tue Feb 04 03:50:01 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 286.000000 118.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Mon Feb 3 20:55:57 2014 +%%CreationDate: Tue Feb 4 01:12:37 2014 diff -r 2d6118b66367 -r aec4085dd5db paper/images/reconnection.xbb --- a/paper/images/reconnection.xbb Mon Feb 03 22:14:54 2014 +0900 +++ b/paper/images/reconnection.xbb Tue Feb 04 03:50:01 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 558.000000 307.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Mon Feb 3 20:55:57 2014 +%%CreationDate: Tue Feb 4 01:12:37 2014 diff -r 2d6118b66367 -r aec4085dd5db paper/images/reconnection2.xbb --- a/paper/images/reconnection2.xbb Mon Feb 03 22:14:54 2014 +0900 +++ b/paper/images/reconnection2.xbb Tue Feb 04 03:50:01 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 487.000000 300.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Mon Feb 3 20:55:57 2014 +%%CreationDate: Tue Feb 4 01:12:37 2014 diff -r 2d6118b66367 -r aec4085dd5db paper/images/rfbProtocol.xbb --- a/paper/images/rfbProtocol.xbb Mon Feb 03 22:14:54 2014 +0900 +++ b/paper/images/rfbProtocol.xbb Tue Feb 04 03:50:01 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 434.000000 631.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Mon Feb 3 20:55:57 2014 +%%CreationDate: Tue Feb 4 01:12:37 2014 diff -r 2d6118b66367 -r aec4085dd5db paper/images/sendscreenimage.xbb --- a/paper/images/sendscreenimage.xbb Mon Feb 03 22:14:54 2014 +0900 +++ b/paper/images/sendscreenimage.xbb Tue Feb 04 03:50:01 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 268.000000 123.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Mon Feb 3 20:55:57 2014 +%%CreationDate: Tue Feb 4 01:12:37 2014 diff -r 2d6118b66367 -r aec4085dd5db paper/images/structureofTreeVNC.xbb --- a/paper/images/structureofTreeVNC.xbb Mon Feb 03 22:14:54 2014 +0900 +++ b/paper/images/structureofTreeVNC.xbb Tue Feb 04 03:50:01 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 492.000000 252.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Mon Feb 3 20:55:57 2014 +%%CreationDate: Tue Feb 4 01:12:37 2014 diff -r 2d6118b66367 -r aec4085dd5db paper/images/treestructure.xbb --- a/paper/images/treestructure.xbb Mon Feb 03 22:14:54 2014 +0900 +++ b/paper/images/treestructure.xbb Tue Feb 04 03:50:01 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 309.000000 256.000000 %%PDFVersion: 1.3 %%Pages: 1 -%%CreationDate: Mon Feb 3 20:55:57 2014 +%%CreationDate: Tue Feb 4 01:12:37 2014 diff -r 2d6118b66367 -r aec4085dd5db paper/images/treestructure_jp.xbb --- a/paper/images/treestructure_jp.xbb Mon Feb 03 22:14:54 2014 +0900 +++ b/paper/images/treestructure_jp.xbb Tue Feb 04 03:50:01 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 309.000000 256.000000 %%PDFVersion: 1.3 %%Pages: 1 -%%CreationDate: Mon Feb 3 20:55:57 2014 +%%CreationDate: Tue Feb 4 01:12:37 2014 diff -r 2d6118b66367 -r aec4085dd5db paper/images/vnc.xbb --- a/paper/images/vnc.xbb Mon Feb 03 22:14:54 2014 +0900 +++ b/paper/images/vnc.xbb Tue Feb 04 03:50:01 2014 +0900 @@ -4,5 +4,5 @@ %%HiResBoundingBox: 0.000000 0.000000 360.000000 194.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Mon Feb 3 20:55:57 2014 +%%CreationDate: Tue Feb 4 01:12:37 2014 diff -r 2d6118b66367 -r aec4085dd5db paper/master_paper.pdf Binary file paper/master_paper.pdf has changed