# HG changeset patch # User Tatsuki IHA # Date 1448707952 -32400 # Node ID 6daaf5e03e4d61af6efe246c55bda20a2be2a959 # Parent 7e2f72bafa1bcf5d66484b3c49c7f5f7014956b3 Add MindMap diff -r 7e2f72bafa1b -r 6daaf5e03e4d paper/prosym.bib --- a/paper/prosym.bib Tue Nov 10 22:30:05 2015 +0900 +++ b/paper/prosym.bib Sat Nov 28 19:52:32 2015 +0900 @@ -10,7 +10,7 @@ } @article{oc:thesis, - author = "{Miwa OSHIRO and Shinji KONO}", + author = "{Miwa OSHIRO}", title = "授業やゼミ向けの画面配信システムTreeVNCの拡張機能", journal = "琉球大学工学部情報工学科平成26年度学位論文(学士) ", year = 2014 diff -r 7e2f72bafa1b -r 6daaf5e03e4d paper/prosym.pdf Binary file paper/prosym.pdf has changed diff -r 7e2f72bafa1b -r 6daaf5e03e4d paper/prosym.tex --- a/paper/prosym.tex Tue Nov 10 22:30:05 2015 +0900 +++ b/paper/prosym.tex Sat Nov 28 19:52:32 2015 +0900 @@ -76,19 +76,24 @@ 教員が操作する画面をそのまま学生に配信したり、 ゼミなどで、発表する学生の画面を切り替えたりすることを可能にしたい。 -TreeVNC画面配信システム\cite{oc:thesis}\cite{taninari:2012a}は、 -参加したクライアントをバイナリツリー状に接続し、 +TreeVNC\cite{oc:thesis}\cite{taninari:2012a}は参加したクライアントをバイナリツリー状に接続し、 配信コストをクライアントにバランスさせる仕組みになっている。 -なので、多人数が参加しても処理性能が下がらない。 +そのため、多人数が参加しても処理性能が下がらない。 また、RFBプロトコルを用いているので、ケーブルの差し替えなしに 共有している画面の切り替えが可能になっている。 -今研究では、 WAN 、マルチディスプレイへの対応を行った。 +本研究では WAN 、マルチディスプレイへの対応を行った。 WANへの対応として、新しい接続方法を提案し、実装を行った。 また、マルチディスプレイへの対応としては配信する際に、配信するディスプレイ情報を取得し、配信を行うことで、対応した。 \section{画面配信システムTreeVNC} -\subsection*{[RFBプロトコル]} +\subsection{VNCについて} +VNC(Virtual Network Computing) は、 RFBプロトコルを用いて遠隔操作を行うリモートデスクトップソフトウェアである。 +VNC はサーバー側とクライアント(ビューア)側に分かれている。 サーバを起動し、クライアントがサーバに接続を行い遠隔操作を可能とする。 + +VNCを使用すればクライアント側にサーバー側の画面を表示することが可能である。 しかし、多人数のクライアントが1つのサーバーに接続してしまうと処理性能が落ちてしまうという問題点がある。 + +\subsection{RFBプロトコル} RFB(remote frame buffer)プロトコル\cite{rfbProtocol}とは、自身の画面を送信し、ネットワーク越しに他者の画面に表示するプロトコルである。 ユーザが居る側をRFBクライアント側と呼び、Framebufferへの更新が行われる側はRFBサーバと呼ぶ。 Framebufferとは、メモリ上に置かれた画像データのことである。 @@ -98,24 +103,15 @@ 更にRFBクライアントのFramebufferUpdateRequestが来るとそれに答え返信する。 RFBプロトコルは、描画データに使われるエンコードが多数用意されており、また独自のエンコードを実装することもできるプロトコルである。 -\subsection*{[TightVNC]} -TightVNC(Tight Virtual Network Computing)\cite{tightvnc}はJavaを用いて作成されたRFBプロトコルのクライアントである。 -本研究で作成したTreeVNCはTightVNCを元に作成されている。 +\subsection{TreeVNC の構造} +TreeVNC は Java を用いて作成された TightVNC(Tight Virtual Network Computing)\cite{tightvnc} を元に作成されている。 -\subsection*{[多人数で VNC を使用する時の問題点]} -多人数で従来の VNC を使用する際、1つのコンピュータに多人数が同時につながり、 -処理が集中してしまい、性能が大幅に落ちてしまうという問題が生じる。 +TreeVNC は クライアント同士を接続させ、画面描画のデータを受け取ったクライアントが次のクライアントにデータを流す。 -ゼミ等の画面配信者が頻繁に切り替わる場合、 -配信者が替わる度にアプリケーションを終了し、接続をし直さないといけないという問題がある。 - -\subsection*{[TreeVNC の構造]} -多人数で VNC を用いるために、クライアントの接続がサーバに一極集中してしまう問題を解決する。 -そのために、 TreeVNC はサーバへ接続しに来たクライアントをバイナリツリー状に接続する(図\ref{fig:tree})。 +TreeVNC はサーバへ接続しに来たクライアントをバイナリツリー状に接続する(図\ref{fig:tree})。 バイナリツリーなら、各nodeに最大2台分のクライアントしか接続されない。 -$N$台のクライアントが接続しに来た場合、画面配信の画像データをコピーする回数は、 -従来の VNC ではサーバ側で$N$回する必要があるが、TreeVNCでは各 node が2回ずつコピーするだけで済む。 -TreeVNC は、root への負荷を各 node に分散することにより、処理性能が向上している。 +$N$台のクライアントが接続しに来た場合、画面配信の画像データをコピーする回数は従来の VNC ではサーバ側で$N$回する必要があるが、TreeVNCでは各ノードが2回ずつコピーするだけで済む。 +TreeVNC は ルートへの負荷を各ノードに分散することにより、処理性能が向上している。 \begin{figure}[ht] \begin{center} @@ -125,50 +121,26 @@ \label{fig:tree} \end{figure} -\subsection*{[Multicast や Broadcast を用いたVNC]} -Multicast とは、 -同一ネットワーク内でマルチキャストアドレスを持っている端末に対してデータを送信することである。 -Broadcast とは、 -同一ネットワーク上の全ての端末に対してデータを送信することである。 -どちらの通信方法も、root からのデータ送信は1回でよく、 -1度データの送信を行うとデータの複製はルータが行う。 - -VNC を Multicast や Broadcast の通信方法を用いて実装すると、 -画像データの送信が1度で済むため、負荷分散のために木構造を形成する必要もなくなる。 - -しかし、これらの通信方法でのパケットの扱いには -\begin{itemize} - \item 送信可能なパケットのブロックサイズが 64000byte までであると決まっている - \item パケットが途中で消失してしまっても特定することができない -\end{itemize} -といった性質がある。 - - -VNC でこれらの通信方法を用いて実装する場合、 -パケットの扱いの性質を乗り越えなければならない。 - -送信可能なパケットのサイズが決まっているので、 -画面データは 64000byte 以下に分割し送信しなければならない。 -しかし、現在の TreeVNC で用いている方法では、 -データ分割の処理には時間がかかってしまう。 - -パケットの消失を検知するために、 -各パケットに対してシリアル番号を振り分ける。 -パケットを受信した node 側で、 -シリアル番号が連番で届いているのかどうかを調べれば、消失を検知することが可能である。 -もしパケットが届いていなかった場合は、root に対して再送要求を送信すれば良い。 -しかし、Multicast や Broadcast 通信ではパケットロス率が高かった。 - -これらの通信方法を用いての VNC の実装にはもう更なる工夫が必要である。 +\subsection{TightVNC} +TightVNC(Tight Virtual Network Computing)\cite{tightvnc}はJavaを用いて作成されたRFBプロトコルのクライアントである。 +本研究で作成したTreeVNCはTightVNCを元に作成されている。 -\subsection*{[node 間で行われるメッセージ通信]} +\subsection{多人数で VNC を使用する時の問題点} +多人数で従来の VNC を使用する際、1つのコンピュータに多人数が同時につながり、 +処理が集中してしまい、性能が大幅に落ちてしまうという問題が生じる。 + +ゼミ等の画面配信者が頻繁に切り替わる場合、 +配信者が替わる度にアプリケーションを終了し、接続をし直さないといけないという問題がある。 + +\subsection{node 間で行われるメッセージ通信} RFBプロトコルで提供されているメッセージに加え、 TreeVNC 独自のメッセージを使用している。 TreeVNC で使用されるメッセージの一覧を表\ref{tb:message}に示す。 \begin{table}[h!] + \caption{通信経路とメッセージ一覧} \large \scalebox{0.4} { \begin{tabular}{|l|l|l|} \hline @@ -200,7 +172,6 @@ & SERVER\_CUT\_TEXT & サーバがテキストのカットバッファを持った際のmessage。 \\ \hline \end{tabular} } - \caption{通信経路とメッセージ一覧} \label{tb:message} \end{table} @@ -231,7 +202,7 @@ \end{figure} -\subsection*{[配信画面切り替え]} +\subsection{配信画面切り替え} ゼミでは発表者が順々に入れ替わる。発表者が入れ替わる度に共有する画面の切り替えが必要となる。 ゼミを円滑に進めるために、画面の切り替えをスムーズに行いたい。 @@ -280,7 +251,7 @@ そこで、画面を共有する際、ディスプレイを選択させ、画面共有を行う機能を追加した。 ディスプレイの情報は個々のクライアントでしか取得ができない。 -なので、配信側は画面の切替を行う際に、ディスプレイを選択し、そのディスプレイの左上と右下の座標を取得する。 +そのため、配信側は画面の切替を行う際に、ディスプレイを選択し、そのディスプレイの左上と右下の座標を取得する。 その座標を root への画面切り替えを要求する SERVER\_CHANGE\_REQUEST message に付加させる。 root は 配信側の VNCServer に画像データを要求する FRAMEBUFFER\_UPDATE\_REPLY message に送信された座標を付加する。 VNCServer は要求された座標内の画像データを FRAMEBUFFER\_UPDATE message で root に送信する。 @@ -341,7 +312,7 @@ Direct Connection した node はそのネットワークの root になり、node はそのネットワークの root に接続し、木構造を生成する。 配信側の root は Direct Connection で接続された node に対して Framebuffer Update で 画像データを別ネットワークの node に送信する。 -Framebuffer Update が送信された node はそのネットワークの root なので、子 node に対して Framebuffer Update を送信する。 +Framebuffer Update が送信された node はそのネットワークの root であるため、子 node に対して Framebuffer Update を送信する。 これにより、別ネットワークでの画面共有が可能となる。 @@ -355,7 +326,7 @@ \section{評価} -\subsection*{[木の深さによるメッセージ伝達の遅延]} +\subsection{木の深さによるメッセージ伝達の遅延} VNCServer から受信する画像データ、 TreeVNC で扱われるメッセージ通信は構成された木を伝って伝達される。 接続する人数が増える毎に木の段数は増えていく。 @@ -363,11 +334,11 @@ メッセージが遅延することなく伝達できているかを検証する実験を行った。 -\subsection*{[実験環境]} +\subsection{実験環境} 授業を受講している学生が TreeVNC を使用した状態で実験を行った。 TreeVNC には最大で34名が接続していた。 -\subsection*{[メッセージを使用した実測]} +\subsection*{メッセージを使用した実測} TreeVNC を伝搬するメッセージに、CHECK\_DELAY・CHECK\_DELAY\_REPLY を追加した。 CHECK\_DELAY は root から node の末端まで伝達するメッセージ(図\ref{fig:checkdelay}, 左)、 CHECK\_DELAY\_REPLY は各 node から root まで伝達するメッセージ(図\ref{fig:checkdelay}, 右)である。 @@ -393,7 +364,7 @@ 計算方法を以下のソースコード\ref{calc}に記述する。 各 node にデータを下ろす際も、root にデータが上る際も、 木を伝い受け渡されている。 -なので、データが root から末端 node に伝わる時間は、 +そのため、データが root から末端 node に伝わる時間は、 CHECK\_DELAY を送信した時間と、 CHECK\_DELAY\_REPLY を受信した時間の半分であるといえる。 diff -r 7e2f72bafa1b -r 6daaf5e03e4d prosym.mm --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/prosym.mm Sat Nov 28 19:52:32 2015 +0900 @@ -0,0 +1,110 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +