Binary file paper/main.pdf has changed

--- a/paper/main.tex	Wed Feb 17 16:42:42 2016 +0900
+++ b/paper/main.tex	Wed Feb 17 18:57:25 2016 +0900
@@ -176,19 +176,18 @@
 
 表\ref{tb:treeVncTheory}はポート一本あたりの通信量である。
 通常の VNC の場合、クライアント数に比例してポート一本あたりの負荷が増えている。
-TreeVNC の場合は1つの Node に対して2台の Node が接続するため、クライアント数関係なく一定である。
+TreeVNC の場合は1つの Node に対して2台の Node が接続するため、最大でも親から送信されるデータと2つの子に送信するデータ分の負荷になる。
 
-% 一本は上からくる奴の説明が欲しい 図 はUpdate rectangle 
 送信するデータ量も通常の VNC の場合 Node 数に比例した量のデータを送信する必要があり、 CPU に負荷がかかってしまう。
 それに対して TreeVNC はクライアントが増えても送信するデータはクライアント毎に分散されているため、1台の CPU に掛かる負荷は一定となる。
 そのため、性能が低下せずに画面配信を行うことが出来る。
 
 \begin{table}[htbp]
     \begin{center}
-    \caption{ポート一本あたりの通信量(N はノード数)}
+    \caption{ポート一本あたりの通信量(N はノード数, d はデータ量)}
     \begin{tabular}{|l|l|l|} \hline
                & 通常の VNC   & TreeVNC \\ \hline
-        通信量 & N * データ量 & (2 + 1) * データ量 \\ \hline
+        通信量 & N * d & (2 + 1) * d \\ \hline
     \end{tabular}
     \label{tb:treeVncTheory}
     \end{center}
@@ -206,8 +205,9 @@
 しかし、 java.util.zip.deflater は解凍に必要な辞書を書き出す(flush)ことが出来ない。
 そのため図\ref{fig:zrleFail} のように、 Zlib圧縮されたデータを途中から受け取ってもデータを正しく解凍することが出来ない。
 
-そこで ZRLEE は 一度 Root Node で受け取った ZRLE のデータを unzip し、 データをzip し直して最後に finish() をいれることで初めからデータを呼んでいなくても解凍を行えるようにした(図\ref{fig:zrlee})。
+そこで ZRLEE は 一度 Root Node で受け取った ZRLE のデータを unzip し、 データをupdate rectangle という画面毎のデータに辞書を付けて zip し直すことで初めからデータを呼んでいなくても解凍を行えるようにした(図\ref{fig:zrlee})。
 % ZRLEE はupdate rectangle 毎にzip, unzip する
+% 一本は上からくる奴の説明が欲しい 図 はUpdate rectangle 
 一度 ZRLEE に変換してしまえば子 Node はそのデータをそのまま流すだけで良い。
 ただし、deflater と inflater では前回までの通信で得た辞書をクリアしないといけないため、 Root Node と Node 側では毎回新しく作る必要がある。
 
@@ -362,16 +362,16 @@
 
 従来のVNCを使用する場合、 画面の切り替えの度に一旦VNCを終了し、発表者の VNC サーバーへと再接続を行う必要がある。
 
-TreeVNC は配信者の切り替えの度に生じる問題を解決している。
-TreeVNC を立ち上げることで、ケーブルを使用する必要なしに、各参加者の手元の PC に発表者の画面を共有することができる。
-画面の切り替えはユーザが VNC サーバーへの再接続を行うことなく、ビューアの Share Screen ボタンを押すことによって、配信者の切り替えを行うことができる。
-%  画面の切り替えはユーザが VNC サーバーへの再接続を行うことなく、ビューアの Share Screen ボタンを押すことによって、配信者の切り替えを行うことができる。 ~ を先に書いたほうが良い
-% 今回〜 切り替え用thread の話を軽く書く
+TreeVNC はユーザが VNC サーバーへの再接続を行うことなく、ビューアの Share Screen ボタンを押すことによって、配信者の切り替えを行うことができる。
+
 TreeVNC の Root Node は配信者の VNC サーバーと通信を行っている。
 VNC サーバーから画面データを受信し、そのデータを 子 Node へと送信している。
 配信者切り替え時に Share Screen ボタンが押されると、 SERVER\_CHANGE\_REQUEST メッセージに Node 番号やディスプレイ情報 を付加し、Root Node に送信する。
 SERVER\_CHANGE\_REQUEST メッセージを受け取った Root Node は配信を行う Node の VNC サーバーと通信を始める。
+この切り替え動作は別のスレッドを生成して行うため、 切り替え作業が終了したときに現在配信している画面が切り替わる。
+
 そのため TreeVNC は配信者切り替えの度に VNC を終了し、再接続する必要がない。
+更にプロジェクタ等も使用しないため、ケーブルの差し替えも行わずとも画面配信を行うことが出来
 
 \newpage
 
@@ -382,10 +382,7 @@
 fit screen ボタンが押されると PC の画面サイズに合わせてフルサイズで拡大・縮小する。
 
 \section{複数のネットワークの対応}
-従来の TreeVNC は、クライアントの接続する木構造が単一であった。
-そのため、Root Node が複数のネットワークに接続していても、 単一のネットワークでしか使用することができなかった。
-
-この問題を解決するために、 図\ref{fig:multinetworktree}の様に、ネットワーク別に木構造を形成するように設計した。
+TreeVNC は Root Node が複数のネットワークに接続している場合、 図\ref{fig:multinetworktree}の様に、ネットワーク別に木構造を形成する。
 
 \begin{figure}[htbp]
     \begin{center}
@@ -400,22 +397,29 @@
 TreeManager では木構造を管理する nodeList が生成される。
 この nodeList を元に、新しい Node の接続や、切断検出時の接続の切り替え等を行う。
 
-Root Node の保持しているネットワーク毎にTreeManager を生成する用に変更を行った。
+Root Node の保持しているネットワーク毎にTreeManager を生成する。
 新しい Node が接続してきた際、 interfaces から Node のネットワークと一致する TreeManager を取得し、 Node 接続の処理を任せる。
-そのため、 TreeVNC が複数のネットワーク別に木構造を構成することが可能となる。
 
 \chapter{NAT 対応}
 % NAT の説明がいる
 % 基本的にグローバルip は複数のインタフェース
 \section{NAT}
+NAT(Network Address Translation) は ローカルなネットワークではプライベートIPアドレスを設定し、外のネットワークへ接続するときにグローバルIPアドレスに変換する技術のことである。 
+また、NAT に変換にポート番号を付け加えることで1つのグローバルIPアドレスで複数のホスト間の通信も可能となる。
+この変換はNAPT(Network Address Ports Translator) と呼ばれる
 % NAT があるとTreeVNCがどうこまるのか
 % マルチキャストが送られないので TreeVNC が見つからない アドレスが重複するなど
-\section{TreeVNC の問題点}
-TreeVNC は Root Node が所属しているネットワークで木を構成する。
-そのため、NAT 越えた別のネットワークからの接続を行うことが出来ない。
+\section{TreeVNC での NAT の問題点}
+TreeVNC は NAT の変換を経由した通信を行う場合様々な問題が発生する。
+
+まず、Multicast 通信を行うことが出来ないという点である。 Multicast は同一ネットワーク内のマルチキャストアドレスを持っている端末に対してデータを送信することである。
+TreeVNC は Root Node を探す際に FIND\_ROOT メッセージをMulticastで送信する。
+しかし、NAT を越えたネットワークは同一ネットワークではないので、Root Node を探すことができない。
+
+また、Root Node の木構造を管理しているnodeList に NAT を越えたネットワークのアドレスを追加していくとIPアドレスが重複する可能性があるため、通常の TreeVNC の構成では NATを越えたネットワークからの接続を行うことが出来ない。
 
 \section{Direct Connection}
-遠隔地からでもゼミや授業に参加できるよう、 NATを越えたネットワークから TreeVNC への接続を可能にした。
+遠隔地からでもゼミや授業に参加できるよう、 NATを越えたネットワークから TreeVNC への接続を可能\cite{parusu:2016a}にした。
 
 図\ref{fig:directConnection} にNATを越えたネットワークからの接続を示す。
 別ネットワークからTreeVNCに参加する際、 直接配信側のネットワークの Root Node に接続を行う。
@@ -456,14 +460,33 @@
     \end{center}
 \end{figure}
 
-\section{共有画面切り替え}
-% DirectConnection してやれば簡単に見えるが、NAT なので、接続先が見つからない場合がある
-% Connection を張りながら入れ替える必要があるけど難しい
-% 難しいといったほうがAlice で簡単にできるというのが強調できる
+\section{NATを越えた画面切り替え}
+図\ref{fig:directConnectionServerChange} は Direct Connection での画面切り替えの実装案である。
+まず Direct Connection した ネットワークのクライアントから SERVER\_CHANGE\_REQUEST メッセージが送信される。
+SERVER\_CHAGEN\_REQUEST メッセージを受け取った そのネットワークの Root Node は Direct Connection した先の Root Node へ SERVER\_CHANGE\_REQUEST を -1 を付加して送信する。
+ -1 を送信することで、 受け取った Root Node は別のネットワークからの画面切り替え要求ということを判断することができる。
+別ネットワークからの切り替え要求を受け取った Root Node は読み込み用と書き込み用のソケットを入れ替える。
+ソケットを入れ替えることで、 切り替え要求した Root Node のデータを受け取ることが可能となる。
 
-\chapter{TreeVNC のリファクタリング}
+\begin{figure}[htbp]
+    \begin{center}
+        \includegraphics[scale=0.5]{./images/directConnectionServerChange.pdf}
+        \caption{NATを越えたネットワークでの画面切り替え}
+        \label{fig:directConnectionServerChange}
+    \end{center}
+\end{figure}
+
+
+図\ref{fig:directConnectionServerChange} の実装案ではなく、画面切り替えが起こったネットワークに対して繋がっているネットワークが DirectConnection をすることで 容易に実装することができる。 
+だが、 NAT を越えた接続のため、再接続する際に接続先が見つからないという問題が発生する。
+そのため接続状況を維持したまま送受信状態を入れ替える必要がある。
+
+しかし、接続状態を維持したままの入れ替えは実装が複雑になっており、今回追加した Direct Connection ではNATを越えたネットワークの画面の配信を行うのみであり、 画面切り替えを行うことが出来ない。
+
+
 % 全て章に
-\section{マルチディスプレイ対応}
+\chapter{マルチディスプレイ対応}
+\section{マルチディスプレイ時の問題点}
 画面配信側の PC がマルチディスプレイの場合 VNC サーバーからは複数の画面全体の画像データが送信されてしまう。
 授業やゼミ等でTreeVNCを使用する場合、複数画面の表示は必要ない。
 そこで、画面を共有する際、ディスプレイを選択させ、画面共有を行う機能を追加した\cite{parusu:2016a}。
@@ -486,7 +509,7 @@
     \label{fig:multidisplay}
 \end{figure}
 
-\section{画面切り替えの安定化}
+\chapter{画面切り替えの安定化}
 % もうちょい細かく Tight VNC はシングルthread でやっていた
 % ユーザーが途中でキャンセルされると辛い とかの図を入れると1章分あるか?
 % protoclContext
@@ -500,7 +523,7 @@
 切り替えが完了した後に、 現在配信中の画面を停止し、画面の切替を行う。
 切り替え用のスレッドを用意することで、配信状況を維持したままスムーズな画面切り替えが可能になった。
 
-\section{クライアントへのエラー通知}
+\chapter{クライアントへのエラー通知}
 % こっちも問題から定義して~
 
 TreeVNC には接続しているクライアントへのエラーの通知を行うことが出来なかった。
@@ -594,7 +617,7 @@
 
 \newpage
 
-\section{ボトルネックになっている Node への対処}
+\chapter{ボトルネックになっている Node への対処}
 画像データを受け取る時間が遅い Node をそのまま木構造に配置しているとその子 Node 以下に影響を及ぼす。
 そのためネックになっている Node への対処が必要である。
 
@@ -622,43 +645,20 @@
 NATを越えに対応した Direct Connection という接続方法を確立し実装した。
 これにより、NAT を越えた別ネットワークのユーザーが TreeVNC に参加することが可能となった。
 
-更にリファクタリングによって以下の機能改良を行った。
-\begin{itemize}
-    \item マルチディスプレイの場合に画面を選択して配信することが可能になった。
-    \item 画面切り替えの際に切り替え用のスレッドを用意することでスムーズな画面切り替えが可能。
-    \item 新しくメッセージを追加することでクライアントにエラー通知を行える様になった。
-\end{itemize}
+マルチディスプレイの場合に画面を選択して配信することが可能になった。
+
+画面切り替えの際に切り替え用のスレッドを用意することでスムーズな画面切り替えが可能。
+
+新しくメッセージを追加することでクライアントにエラー通知を行える様になった。
 
 今回の画像データの遅延実験を行い、 ボトルネックになっているノードがあることがわかった。
 また、ボトルネックになっているノードへの対処を行った。
 
 \section{今後の課題}
-\subsection{NATを越えた画面切り替え}
-% これは上に書いたほうが良い
-今回追加した Direct Connection ではNATを越えたネットワークの画面の配信を行うのみであり、 TreeVNC の利点の1つである画面切り替えを行うことが出来ない。
-そのため、NATを越えたネットワークでの画面切り替えの実装を行う必要がある。
-
-図\ref{fig:directConnectionServerChange} は Direct Connection での画面切り替えの実装案である。
-まず Direct Connection した ネットワークのクライアントから SERVER\_CHANGE\_REQUEST メッセージが送信される。
-SERVER\_CHAGEN\_REQUEST メッセージを受け取った そのネットワークの Root Node は Direct Connection した先の Root Node へ SERVER\_CHANGE\_REQUEST を -1 を付加して送信する。
- -1 を送信することで、 受け取った Root Node は別のネットワークからの画面切り替え要求ということを判断することができる。
-別ネットワークからの切り替え要求を受け取った Root Node は読み込み用と書き込み用のソケットを入れ替える。
-ソケットを入れ替えることで、 切り替え要求した Root Node のデータを受け取ることが可能となる。
-
-\begin{figure}[htbp]
-    \begin{center}
-        \includegraphics[scale=0.5]{./images/directConnectionServerChange.pdf}
-        \caption{NATを越えたネットワークでの画面切り替え}
-        \label{fig:directConnectionServerChange}
-    \end{center}
-\end{figure}
-
-\subsection{音声機能の追加}
 Direct Conenction により、NAT を越えたの画面配信が可能となった。
 しかし、 遠隔地からゼミや授業等に参加する場合は画面の表示のみではなく、 音声の配信も行いたい。
 そのため音声配信機能の実装を行う必要がある。
 
-\subsection{マルチディスプレイ時の画面調整}
 今回実装したマルチディスプレイ選択の画面配信は PC の画面サイズに合わせてフルサイズで拡大・縮小する fit screen ボタンに対応しておらず、一画面のサイズの調節を行えない。
 そのためマルチディスプレイの fit screen 機能を実装する必要がある。
 

Binary file prepaper/finalPre.pdf has changed

--- a/prepaper/finalPre.tex	Wed Feb 17 16:42:42 2016 +0900
+++ b/prepaper/finalPre.tex	Wed Feb 17 18:57:25 2016 +0900
@@ -28,18 +28,15 @@
 \thispagestyle{fancy} 
 
 \section{Abstract}
-Screen sharing system TreeVNC multicast high resolution PC screen using tree structured network over client's PCs.
-Copying costs are balanced among these PC instead of centralize heavy costs on a VNC server.
+An implementation of Screen sharing system is presented.
+TreeVNC supports multicasting high resolution PC screen using tree structured network over PCs.
+Copying costs are distributed instead of the centralized heavy costs on a VNC server.
 It also possible to change screen server dynamically without changing display cables.
 TreeVNC is useful in a lecture which contains 40-60 students or small seminar.
 
-We add several improvements on TreeVNC.
-By supporting NAT. 
-By refactoring TreeVNC. 
-create screen change thread. it stabilize screen change.
-in case of sharing multiple screen, selected one screen sharing.
-本研究ではTreeVNCの改良として、NATへの対応を行った。
-また、リファクタリングとして、マルチディスプレイへの対応、画面切り替えの安定化、エラー通知用のメッセージの追加等を行うとともに、TreeVNC 有用性を示すために画像データの遅延時間計測を行った。
+We add several improvements on TreeVNC, such as new connection method for supporting NAT, screen change in a separated thread, multiple screen selection, notification of connection errors.
+
+We also show the delay time distribution in real environments
 
 \section{画面共有を利用したコミュニケーション}
 授業やゼミ等で、それぞれが PC 端末を持っている場合では、