\chapter{画面共有システム}

この章では、従来画面共有で使用されているTightVNCとそれに使われてるRFBプロトコルについて説明する。その上で、多人数で使用する際の問題点を説明する。

\section{RFBプロトコル}
RFB(remote frame buffer)プロトコル\cite{rfbProtocol}とは、画面共有システムなどに用いられている、リモートのグラフィカルユーザーインターフェースにアクセスするためのプロトコルである。
ユーザが居る側をRFBクライアント側と呼び、フレームバッファ(画像データ)への更新が行われる側はRFBサーバと呼ぶ。\\
RFBプロトコルでは、最初にサーバ・クライアント間でハンドシェイクが行われる。ハンドシェイクでは、プロトコルバージョンの確認・接続に対しての認証が行われる。\\
ハンドシェイク後には、クライアントに向けて初期メッセージが送信される。初期メッセージにはフレームバッファの大きさやデスクトップに付けられた名前などが含まれている。\\
RFBサーバ側はフレームバッファの更新が行われるたびに、RFBクライアントに対してフーレムバッファの更新データを矩形で送信する。更にRFBクライアントのフレームバッファアップートリクエストが来るとそれに答え返信する。\\
RFBプロトコルは、描画データに使われっるエンコードが多数用意されており、また独自のエンコードを実装することもできるシンプルなプロトコルである。\\
RFBプロトコルの概要を図\ref{fig:rfb}に示す。
\begin{figure}[!htbp]
\begin{center}
\includegraphics[width=110mm]{./images/rfbprotocol.pdf}
\end{center}
\caption{RFBプロトコル}
\label{fig:rfb}
\end{figure}


\newpage

\section{TightVNC}
TightVNC(Tight Virtual Network Computing)\cite{tightvnc}はRFBプロトコルを用いて作成された、画面共有をするためのオープンソースなアプリケーションである。
TightVNCはサーバ側とクライアント(ビューア)側に分かれていて、サーバを起動し、クライアントがサーバに接続を行い画面共有を可能とする。
TightVNCの特徴として、圧縮された画像データを扱うことができることが挙げられる。そのため、低速回線環境でも動作できるようになっている。しかしエンコードとデコードを行う分CPUのパワーが必要になる。\\

\section{VNC Reflector}
VNCReflectorはサーバへの負荷を減らすように設計されているVNCソフトの一つである。
Javaを用いて実装されており、フリーで入手することができる。
Vnc Reflectorは、Vncサーバとクライアントとの間に入り、VNCサーバとの通信を代わり
に行うプログラムである。
クライアントはVnc Reflectorへ接続するので、VNCサーバとの接続はVnc Reflectorのみ
となり、VNCサーバ側の負荷を減らすことができる。
しかし、VNC Reflectorも接続はProxyに一極に集中してしまっているためサーバの負荷は軽減するが、
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を用いて発表を行う場合、発表者が切り替わるごとに接続し直さなければならない。
それに伴い接続し直す際の認証が毎回発生する。\\
また、高解像度のマルチディスプレイを使用している人などがいる場合は、送信される画像データの量が多くなりすぎてしまいメモリを圧迫してしまうことがある。


%\begin{figure}[!htbp]
%\begin{center}
%\includegraphics[width=120mm]{./images/auth.pdf}
%\end{center}
%\caption{再接続}
%\label{fig:auth}
%\end{figure}

\section{BroadcastとMulticast}
Broadcastは同じネットワークアドレス(同一セグメント)上のすべての端末に対して、同時にデータを送信することである(図\ref{fig:broadcast})。
Multicastは同じマルチキャストアドレスを持った端末に同時にデータを送信することである(図\ref{fig:multicast})。
画像データを配信する際にBroadcastやMulticastを用いて、画像データを送信すると、木構造を構成する必要がなくなり、画像データ送信も一回送信するだけで良い。そこで、Broadcastを用いた実装について考察してみた。
\begin{figure}[!htbp]
\begin{center}
\includegraphics[width=110mm]{./images/broadcast.pdf}
\end{center}
\caption{Broadcast}
\label{fig:broadcast}
\end{figure}

\begin{figure}[!htbp]
\begin{center}
\includegraphics[width=110mm]{./images/multicast.pdf}
\end{center}
\caption{Multicast}
\label{fig:multicast}
\end{figure}

\subsection{Braodcastパケットの性質}
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コネクションを用いて送信を行うのが良い。