Mercurial > hg > Papers > 2015 > oc-thesis

changeset 3:63ae5aaa2a7a

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
update
author oc
date Sat, 14 Feb 2015 14:25:36 +0900
parents 5a0d4afbb53e
children 14e96778c600
files chapter2.tex chapter3.tex chapter4.tex chapter6.tex images/chapter3/LostParent.pdf images/chapter3/LostParent.xbb images/chapter3/lostChild1.pdf images/chapter3/lostChild1.xbb images/chapter3/lostChild2.pdf images/chapter3/lostChild2.xbb images/chapter4/sendInitData.pdf images/chapter4/sendInitData.xbb
diffstat 12 files changed, 232 insertions(+), 81 deletions(-) [+]
line wrap: on
line diff
--- a/chapter2.tex	Sun Feb 08 17:49:22 2015 +0900
+++ b/chapter2.tex	Sat Feb 14 14:25:36 2015 +0900
@@ -5,32 +5,64 @@
 RFB(remote frame buffer)プロトコル\cite{rfbProtocol}とは、自身の画面を送信し、ネットワーク越しに他者の画面に表示するプロトコルである。
 ユーザが居る側をRFBクライアント側と呼び、Framebufferへの更新が行われる側はRFBサーバと呼ぶ。
 Framebufferとは、メモリ上に置かれた画像データのことである。
-RFBプロトコルの概要を図\ref{fig:rfb}に示す。
-RFBプロトコルでは、最初にプロトコルバージョンの確認(図\ref{fig:rfb}中,2:)や認証が行われる(図\ref{fig:rfb}中,3:)。
-その後、クライアントに向けてFramebufferの大きさやデスクトップに付けられた名前などが含まれている初期メッセージが送信される(図\ref{fig:rfb}中,4:)。
-RFBサーバ側はFramebufferの更新が行われるたびに、RFBクライアントに対してFramebufferの変更部分だけを送信する(図\ref{fig:rfb}中,5:)。更にRFBクライアントのFramebufferUpdateRequestが来るとそれに答え返信する。
+RFBプロトコルでは、最初にプロトコルバージョンの確認や認証が行われる。
+その後、クライアントに向けてFramebufferの大きさやデスクトップに付けられた名前などが含まれている初期メッセージが送信される。
+RFBサーバ側はFramebufferの更新が行われるたびに、RFBクライアントに対してFramebufferの変更部分だけを送信する。
+更にRFBクライアントのFramebufferUpdateRequestが来るとそれに答え返信する。
 RFBプロトコルは、描画データに使われるエンコードが多数用意されており、また独自のエンコードを実装することもできるプロトコルである。
 
-\begin{figure}[!htbp]
-\begin{center}
-\includegraphics[width=110mm]{./images/chapter2/rfbprotocol.pdf}
-\end{center}
-\caption{RFBプロトコル}
-\label{fig:rfb}
-\end{figure}
-
 
 \section{TightVNC}
 TightVNC(Tight Virtual Network Computing)\cite{tightvnc}はJavaを用いて作成されたRFBプロトコルのクライアントである。
 本研究で作成したTreeVNCはTightVNCを元に作成されている。
 
 
+\section{多人数で VNC を使用するときの問題点}
+多人数で従来の VNC を使用する際、1つのコンピュータに多人数が同時につながり、
+処理が集中してしまい、性能が大幅に落ちてしまうという問題が生じる。
+
+ゼミ等の画面配信者が頻繁に切り替わる場合、
+配信者が替わる度にアプリケーションを終了し、接続をし直さないといけないという問題がある。
+
+
 \newpage
 
-\section{node間のメッセージ}
+
+\section{TreeVNC の構造}
+多人数で VNC を用いるために、クライアントの接続がサーバに一極集中してしまう問題を解決する。
+そのために、 TreeVNC はサーバへ接続しに来たクライアントをバイナリツリー状に接続する(図\ref{fig:tree})。
+バイナリツリーなら、各nodeに最大2台分のクライアントしか接続されない。
+$N$台のクライアントが接続しに来た場合、画面配信の画像データをコピーする回数は、
+従来のVNCでは$N$回、TreeVNCでは$log N * 2$回となる。
+TreeVNCは、rootへの負荷を各nodeに分散することにより、
+処理性能が向上している。
+
+\begin{figure}[htpd]
+  \begin{center}
+    \includegraphics[scale=0.4]{./images/chapter2/TreeVNC.pdf}
+  \end{center}
+  \caption{構成される木構造}
+  \label{fig:tree}
+\end{figure}
+
+
+\section{node 間で行われるメッセージ通信}
 RFBプロトコルで提供されているメッセージに加え、 TreeVNC 独自のメッセージを使用している。
 TreeVNC で使用されるメッセージの一覧を表\ref{tb:message}に示す。
 
+図\ref{fig:message}は、
+TreeVNC で node が root に接続し、画像データを受信するまでのメッセージ通信の様子である。
+node は Multicast 通信で root に対して FIND\_ROOT を送信する(図\ref{fig:message}中, 1:)。
+同じネットワークインタフェースにいる root が受信し、FIND\_ROOT\_REPLY を送信する(図\ref{fig:message}中, 2:)。
+それを受け取ると node は root に対して接続先を要求する WHERE\_TO\_CONNECT を送信する(図\ref{fig:message}中, 3:)。
+root は、node の接続先を CONNECT\_TO で送信する(図\ref{fig:message}中, 4:)。
+root・ node 間の接続が確立後は、
+root から定期的に画像データ FRAME\_BUFFER\_UPDATE が送信される(図\ref{fig:message}中, 4:)。
+
+
+\newpage
+
+
 \begin{table*}[htb]
   \scriptsize
   \begin{tabular}{|l|l|l|} \hline
@@ -60,43 +92,83 @@
     send message        & SET\_COLOR\_MAP\_ENTRIES   & 指定されているpixel値にマップするRGB値。 \\ \cline{2-3}
     (VNCServer to root) & BELL                       & ビープ音を鳴らす。 \\ \cline{2-3}
                         & SERVER\_CUT\_TEXT          & サーバがテキストのカットバッファを持った際のmessage。 \\ \hline
-
   \end{tabular}
   \caption{通信経路とmessage一覧}
   \label{tb:message}
 \end{table*}
 
-\section{多人数でVNCを使用するときの問題点}
-多人数で従来の VNC を使用する際、1つのコンピュータに多人数が同時につながり、
-処理が集中してしまい、性能が大幅に落ちてしまうという問題が生じる。
-
-ゼミ等の画面配信者が頻繁に切り替わる場合、
-配信者が替わる度に、接続をし直さないといけないという問題がある。
-
-
-\section{TreeVNC の構造}
-多人数で VNC を用いるために、クライアントの接続がサーバに一極集中してしまう問題を解決する。
-そのために、 TreeVNC はサーバへ接続しに来たクライアントをバイナリツリー状に接続する(図\ref{fig:tree})。
-バイナリツリーなら、各nodeに最大2台分のクライアントしか接続されない。
-$N$台のクライアントが接続しに来た場合、画面配信の画像データをコピーする回数は、
-従来のVNCでは$N$回、TreeVNCでは$log N * 2$回となる。
-TreeVNCは、rootへの負荷を各nodeに分散することにより、
-処理性能が向上している。
-
-\begin{figure}[htpd]
-  \begin{center}
-    \includegraphics[scale=0.4]{./images/chapter2/TreeVNC.pdf}
-  \end{center}
-  \caption{構成される木構造}
-  \label{fig:tree}
+\begin{figure}[!htbp]
+\begin{center}
+\includegraphics[width=67mm]{./images/chapter2/message.pdf}
+\end{center}
+\caption{node 間で行われるメッセージ通信}
+\label{fig:message}
 \end{figure}
 
 
 \newpage
 
 
+\section{配信画面切り替え}
+TreeVNC は、配信者の切り替えの度に生じる煩わしさを解決している。
+配信者となるクライアント側で share button を押すと、配信者を切り替えることができる。
+
+root は配信者の VNCServer と通信を行っており、
+VNCServer から画面データを受信し、そのデータを node へと送信している。
+share button が押されると、
+root は share button を押したクライアントの VNCServer と新しく通信をし直す。
+
+これにより、配信者切り替えのために VNC を終了し、再接続する必要がなくなる。
+
+
+\section{MulticastQueue}
+配信側の画面が更新されると、 VNCServer から画像データが framebufferUpdate として送られてくる。
+TreeVNC は、画像の更新を複数の node に同時に伝えるため、
+MulticastQueue という Queue に画像データを格納する。
+
+MulticastQueue は、CountDownLatch を用いている。
+java.util.concurrent.CountDownLatch とは、
+java の並列用に用意された API で、他のスレッドで実行中の操作が完了するまで、
+複数のスレッドを待機させることのできるクラスである。
+スレッドを解放するカウントを設定することができ、
+カウントが 0 になるまで await メソッドでスレッドをブロックすることができる。
+
+TreeVNC では、それぞれの画像データにカウントが追加され、
+カウントが 0 になると、その画像データは消される。
+親 node が接続されている子 node の数だけカウントを設定する。
+子 node が画像データを pull すると、そのカウントが減る。
+全ての子 node が画像データを pull するとカウントが 0 になり、画像データが消される。
+
 
 
-\section{配信画面切り替え}
+
+
 
 
+%\section{オプション一覧}
+%${\mathchar`-}$${\mathchar`-}$
+%
+%\begin{table*}[htb]
+%\begin{center}
+%  \begin{tabular}{|l|l|} \hline
+%    オプション            & 説明 \\ \hline \hline
+%    -p                    & a\\ \hline
+%    -d                    & a\\ \hline
+%    ${\mathchar`-}$${\mathchar`-}$cui                 & a\\ \hline
+%    -v                    & a\\ \hline
+%    -version              & a\\ \hline
+%    -ns                   & a\\ \hline
+%    ${\mathchar`-}$${\mathchar`-}$fixSize             & a\\ \hline
+%    ${\mathchar`-}$${\mathchar`-}$filterSingleDisplay & a\\ \hline
+%    ${\mathchar`-}$${\mathchar`-}$width               & a\\ \hline
+%    ${\mathchar`-}$${\mathchar`-}$height              & a\\ \hline
+%    ${\mathchar`-}$${\mathchar`-}$host                & a\\ \hline
+%    ${\mathchar`-}$${\mathchar`-}$showTree            & a\\ \hline
+%    ${\mathchar`-}$${\mathchar`-}$checkDelay          & a\\ \hline
+%    ${\mathchar`-}$${\mathchar`-}$addSerialNum        & a\\ \hline
+%    ${\mathchar`-}$${\mathchar`-}$logFile             & a\\ \hline
+%  \end{tabular}
+%  \caption{オプション一覧}
+%  \label{tb:option}
+%\end{center}
+%\end{table*}
--- a/chapter3.tex	Sun Feb 08 17:49:22 2015 +0900
+++ b/chapter3.tex	Sat Feb 14 14:25:36 2015 +0900
@@ -12,7 +12,7 @@
 最低限のソケットポートを開けることによって、
 メモリの使用量を抑えることにも繋がる。
 
-%  messageの説明にportにどんな関係があるのかあとから
+%  messageの説明にportにどんな関係があるのかとから
 以前は固定port番号を使用しmessageの通信を行っていたが、
 一意なportを割り当てられているnodeが通信を行うことによって、
 どのport番号が使用されているかを意識する必要がなくなった。
@@ -26,7 +26,18 @@
 新しいホスト側のviewerを閉じることで問題を解決した。
 
 
-\newpage
+\section{QUALITYモードとSPEEDモード}
+
+高解像度のまま拡大・縮小の処理を行うと、
+PCのスペックによって描画処理に時間がかかってしまうことがある。
+授業中に TreeVNC を使用する際、
+拡大・縮小をしてしまうと描画処理が重くなり遅延が生じていた。
+
+画像描画処理には、品質優先( QUALITY モード)・スピード優先( SPEED モード)がある。
+今まで TreeVNC は基本的に QUALITY モードを設定していた。
+
+どちらのモードを使用するかをビューワから変更出来るようにした。
+これにより、描画処理の遅延を解決することができた。
 
 
 \section{Tree の構成の変更}
@@ -34,7 +45,6 @@
 従来のTreeVNCは、クライアントの接続する木構造が単一であった。
 そのため、ネットワークインターフェースが違うクライアントが
 同じ木に混在している状況が生じた。
-
 速度の遅いクライアントが木に存在すると、
 そのクライアント以下の通信速度が遅くなってしまう。
 
@@ -59,32 +69,62 @@
 \end{figure}
 
 
+\newpage
+
 \section{切断時の検知方法の変更}
 
-lostParent\ref{fig:lostparent} を lostChild\ref{fig:lostchild1} へ。
-lostChild の接続切り替えの図\ref{fig:lostchild2}
+接続していたクライアントとの接続が切れた際の検知方法を変更した。
+
+root は nodeList という TreeVNC のネットワークトポロジーを管理するためのリストを持っている。
+root は TreeVNC の接続処理の全てを担っている。
+%node が切断された場合、 root は TreeVNC の木構造を崩さないように切断を検知し、
+%木構造を崩さないよう、 node 同士の接続を再構成しなければならない。
+node の接続が切れた場合、代わりとなる node の接続が必要となるため root に知らせなければならない。
+
+変更前は、lostParent という検知方法を採用していた。
+この方法は、親となる node の接続が切れた場合、
+子となる node から root に対して lostParent message を送信する。
+これにより root は lostParent を検知し、代替 node の接続を行う。
+
+この方法では、子のいない末端の node の接続が切れた際に root にメッセージが送信されない。
+root は切断を検知できないと、nodeList の更新を行うことができない。
+nodeList が正しく更新されない場合、図\ref{fig:lostparent}のように、
+新しい node を既に切断されている node に接続しようと試み、失敗してしまう。
 
 \begin{figure}[htpd]
   \begin{center}
-    \includegraphics[scale=0.4]{./images/chapter3/lostParent.pdf}
+    \includegraphics[scale=0.7]{./images/chapter3/lostParent.pdf}
   \end{center}
   \caption{lostParent}
   \label{fig:lostparent}
 \end{figure}
 
+末端 node の切断が検知できない問題を解決するために、
+lostChild という検知方法に変更した。
+
+TreeVNC は、画面データ(framebufferUpdate)が MulticastQueue という Queue に蓄積される。
+node はこの Queue から画像データを取得し、描画している。
+lostChild の検出方法は、この MulticastQueue を使用している。
+ある一定時間、MulticastQueue から画像データが取得されない場合、
+その node との接続が切れたと判断し、親となる node が root に LOST\_CHILD message を送信する(図\ref{fig:lostchild1})。
+lostChild により、切断されてしまった全ての node を検知することができるので、
+nodeList の更新が正しく行われる。
+これにより、新しい node を適切な場所へ接続することができる(図\ref{fig:lostChild2})。
+
+
 \begin{figure}[htpd]
   \begin{center}
-    \includegraphics[scale=0.4]{./images/chapter3/lostChild1.pdf}
+    \includegraphics[scale=0.7]{./images/chapter3/lostChild1.pdf}
   \end{center}
-  \caption{lostChild1}
+  \caption{lostChild を検知・再接続}
   \label{fig:lostchild1}
 \end{figure}
 
 \begin{figure}[htpd]
   \begin{center}
-    \includegraphics[scale=0.4]{./images/chapter3/lostChild2.pdf}
+    \includegraphics[scale=0.7]{./images/chapter3/lostChild2.pdf}
   \end{center}
-  \caption{lostChild2}
+  \caption{新 node の接続}
   \label{fig:lostchild2}
 \end{figure}
 
--- a/chapter4.tex	Sun Feb 08 17:49:22 2015 +0900
+++ b/chapter4.tex	Sat Feb 14 14:25:36 2015 +0900
@@ -1,53 +1,91 @@
 \chapter{TreeVNC の新機能}
 
-\section{画面サイズ調整機能}
+
+\section{表示画面サイズ調整機能}
+TreeVNC は、配信側の解像度を配信するので画質が荒くなることはない。
+しかし、配信側とクライアントで画面サイズに差がある場合、
+画面に入らない、或いは表示画面が小さすぎる等の問題が生じる。
+
+今までは、ユーザが viewer に用意されている拡大・縮小ボタンを使用し調整していた。
+
+今回、ビューワに HD ボタンと fit screen ボタンを追加した。
+HD ボタンを押すと、画面サイズが 1920x1080 サイズに拡大・縮小される。
+fit screen ボタンを押すと、クライアントの画面サイズに合わせてフルサイズで拡大・縮小される。
+
+更に、rootとして起動し viewer も表示される -d オプションを使用した場合は、
+表示される画面が常にフルサイズに調整されるよう実装した。
+
+
+\section{配信画面サイズ指定機能}
 
 配信する画面サイズを指定できるオプションを追加した。
-TreeVNC 起動時にオプション(--fixSize)を追加することによって、
+TreeVNC 起動時にオプション(${\mathchar`-}$${\mathchar`-}$fixSize)を追加することによって、
 指定した幅・高さの画面サイズのみを配信することができる。
+起動方法をソースコード\ref{fixsize}に記述する。
+
+\begin{lstlisting}[caption=オプション--fixSize,label=fixsize]
+  $ java -jar TreeVNC.java -d --fixSize 1920 1080
+\end{lstlisting}
 
 VNCServer からは、配信する側の画面全体のデータが送信される。
-画面データを root が受信し、接続されている node に画面データを送信する。
+root は指定したサイズ領域のデータのみを表示するため、
+領域内の更新のみを node に送信し、領域内のみを描画している。
+そして、VNCServer へ更新データを要求する際は、
+領域内のみの画像データを要求する。
+これにより、node に指定された領域以外は表示されない。
 
-指定した画面サイズのデータのみを表示する方法として、
-画面全体のデータを受信する root 側で指定した画面サイズの領域内の更新のみをフィルタリングする。
-フィルタリングされた画面データを node は受信するので、指定された領域以外は表示されない。
 
 \newpage
 
+
 \section{マルチディスプレイ対応}
 
-画面配信側がマルチディスプレイの場合、
-VNCServer からは全画面データが送信されるので複数の画面が共有される。
-しかし、プレゼンテーションの際にスライドを全画面で表示する等、複数枚の画面表示が要らない場面がある。
-一画面のみをフィルタリングするオプション機能(--filterSingleDisplay)を追加した。
+画面配信側がマルチディスプレイの場合でも、
+VNCServer からは全画面データが送信されるので、
+配信側の保持している画面全てが共有される。
+しかし、プレゼンテーションを行う際、複数枚の画面表示が要らない場合がある。
+
+そこで、一画面のみをフィルタリングし表示するためのオプション機能(${\mathchar`-}$${\mathchar`-}$filterSingleDisplay)を追加した。
 オプションを追加した起動方法をソースコード\ref{filtersingledisplay}に記述する。
 
 \begin{lstlisting}[caption=オプション--filterSingleDisplay,label=filtersingledisplay]
   $ java -jar TreeVNC.java -d --filterSingleDisplay
 \end{lstlisting}
 
+root は全画面データから一画面のみをフィルタリングする必要がある。
+シングルディスプレイサイズは、個々のクライアントでしか取得できない。
+配信側は画面切り替えを行う際に、シングルディスプレイサイズを取得する。
+そして、画面切り替えを行う際に root へ送信する serverChangeRequset message に
+シングルディスプレイサイズを付加する。
+
+root はメッセージを受け取り initData を変更する。
+本来 initData は、RFB プロトコルで行われる通信中に VNCServer から受信する ServerInit message から生成される。
+マルチディスプレイの場合、ServerInit message をそのまま使用すると、複数画面全体を描画してしまう。
+それを避けるため、initData をシングルディスプレイサイズ用に生成し直す(oritinalInitData)。
+そして、接続されている node へも originalInitData を送信する(図\ref{fig:initdata})。
 
 \begin{figure}[htpd]
   \begin{center}
-    \includegraphics[scale=0.4]{./images/chapter4/flameDisplaySizeFilterVer.pdf}
+    \includegraphics[scale=0.8]{./images/chapter4/sendInitData.pdf}
   \end{center}
-  \caption{}
-  \label{fig:}
+  \caption{シングルディスプレイサイズ用の initData}
+  \label{fig:initdata}
 \end{figure}
 
+さらに VNCServer から送信されてきた全画面データをそのまま node に流すのではなく、
+シングルディスプレイサイズの領域の更新部分のみを root 側でフィルタリングし流す。
 
-\begin{figure}[htpd]
-  \begin{center}
-    \includegraphics[scale=0.4]{./images/chapter4/sendInitData.pdf}
-  \end{center}
-  \caption{}
-  \label{fig:}
-\end{figure}
+これにより、一画面のみの表示が可能となる。
 
 
 \newpage
 
+
+\section{Retina のマルチディスプレイ対応}
+
+
+
+
 \section{遠隔地からの接続}
 
 \begin{figure}[htpd]
--- a/chapter6.tex	Sun Feb 08 17:49:22 2015 +0900
+++ b/chapter6.tex	Sat Feb 14 14:25:36 2015 +0900
@@ -1,3 +1,4 @@
 \chapter{まとめ}
 
+\section{改良点のまとめ}
 \section{今後の課題}
Binary file images/chapter3/LostParent.pdf has changed
--- a/images/chapter3/LostParent.xbb	Sun Feb 08 17:49:22 2015 +0900
+++ b/images/chapter3/LostParent.xbb	Sat Feb 14 14:25:36 2015 +0900
@@ -1,8 +1,8 @@
-%%Title: ./LostParent.pdf
+%%Title: ./lostParent.pdf
 %%Creator: extractbb 20140317
-%%BoundingBox: 0 0 449 288
-%%HiResBoundingBox: 0.000000 0.000000 449.000000 288.000000
+%%BoundingBox: 0 0 395 257
+%%HiResBoundingBox: 0.000000 0.000000 394.500000 257.250000
 %%PDFVersion: 1.3
 %%Pages: 1
-%%CreationDate: Sun Feb  8 13:05:09 2015
+%%CreationDate: Fri Feb 13 16:25:37 2015
 
Binary file images/chapter3/lostChild1.pdf has changed
--- a/images/chapter3/lostChild1.xbb	Sun Feb 08 17:49:22 2015 +0900
+++ b/images/chapter3/lostChild1.xbb	Sat Feb 14 14:25:36 2015 +0900
@@ -1,8 +1,8 @@
 %%Title: ./lostChild1.pdf
 %%Creator: extractbb 20140317
-%%BoundingBox: 0 0 365 284
-%%HiResBoundingBox: 0.000000 0.000000 365.000000 284.000000
+%%BoundingBox: 0 0 627 267
+%%HiResBoundingBox: 0.000000 0.000000 627.000000 267.000000
 %%PDFVersion: 1.3
 %%Pages: 1
-%%CreationDate: Sun Feb  8 13:05:43 2015
+%%CreationDate: Fri Feb 13 16:23:43 2015
 
Binary file images/chapter3/lostChild2.pdf has changed
--- a/images/chapter3/lostChild2.xbb	Sun Feb 08 17:49:22 2015 +0900
+++ b/images/chapter3/lostChild2.xbb	Sat Feb 14 14:25:36 2015 +0900
@@ -1,8 +1,8 @@
 %%Title: ./lostChild2.pdf
 %%Creator: extractbb 20140317
-%%BoundingBox: 0 0 410 279
-%%HiResBoundingBox: 0.000000 0.000000 410.000000 279.000000
+%%BoundingBox: 0 0 338 221
+%%HiResBoundingBox: 0.000000 0.000000 338.250000 220.500000
 %%PDFVersion: 1.3
 %%Pages: 1
-%%CreationDate: Sun Feb  8 13:05:25 2015
+%%CreationDate: Fri Feb 13 16:28:47 2015
 
Binary file images/chapter4/sendInitData.pdf has changed
--- a/images/chapter4/sendInitData.xbb	Sun Feb 08 17:49:22 2015 +0900
+++ b/images/chapter4/sendInitData.xbb	Sat Feb 14 14:25:36 2015 +0900
@@ -1,8 +1,8 @@
 %%Title: ./sendInitData.pdf
 %%Creator: extractbb 20140317
-%%BoundingBox: 0 0 366 416
-%%HiResBoundingBox: 0.000000 0.000000 366.000000 416.000000
+%%BoundingBox: 0 0 272 312
+%%HiResBoundingBox: 0.000000 0.000000 272.250000 312.000000
 %%PDFVersion: 1.3
 %%Pages: 1
-%%CreationDate: Sun Feb  8 01:06:36 2015
+%%CreationDate: Fri Feb 13 16:53:29 2015