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

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

\section{RFBプロトコル}
RFB(remote frame buffer)プロトコル\cite{rfbProtocol}とは、自身の画面を送信し、ネットワーク越しに他者の画面に表示するプロトコルである。
ユーザが居る側をRFBクライアント側と呼び、Framebufferへの更新が行われる側はRFBサーバと呼ぶ。
Framebufferとは、メモリ上に置かれた画像データのことである。
RFBプロトコルの概要を図\ref{fig:rfb}に示す。
RFBプロトコルでは、最初にプロトコルバージョンの確認や認証が行われる(図\ref{fig:rfb}中,1: ,2: ,3: ,4:)。
%RFBプロトコルでは、最初にサーバ・クライアント間でハンドシェイクが行われる。ハンドシェイクでは、プロトコルバージョンの確認・接続に対しての認証が行われる。
その後、クライアントに向けてFramebufferの大きさやデスクトップに付けられた名前などが含まれている初期メッセージが送信される。(図\ref{fig:rfb}中,5:)
%ハンドシェイク後には、クライアントに向けて初期メッセージが送信される。初期メッセージにはフレームバッファの大きさやデスクトップに付けられた名前などが含まれている。
RFBサーバ側はFramebufferの更新が行われるたびに、RFBクライアントに対してFramebufferの変更部分だけを送信する。更にRFBクライアントのFramebufferUpdateRequestが来るとそれに答え返信する。
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}はJAVAを用いて作成されたRFBプロトコルのクライアントである。
本研究で作成したTreeVNCはTightVNCを元に作成されている。



\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
    1台 & 20M(最大速度) & 55\%  \\ \hline
    10台 & 5M & 100\%  \\ \hline
  \end{tabular}
\end{center}
\end{table}

一本の通信網への負荷が高く、サーバのCPUへの負荷が高いというのが問題である。\\


\section{VNC Reflector}
VNC Reflectorはサーバへの負荷を減らすように設計されているVNCソフトの一つである。
Javaを用いて実装されており、フリーで入手することができる。
Vnc Reflectorは、Vncサーバとクライアントとの間に入り、VNCサーバとの通信を代わり
に行うプログラムである。
クライアントはVnc Reflectorへ接続するので、VNCサーバとの接続はVnc Reflectorのみ
となり、VNCサーバ側の負荷を減らすことができる。
しかし、VNC Reflectorも接続はProxyに一極に集中してしまっているためサーバの負荷は軽減するが、
Proxyに対しては負荷がかかる。


\section{ゼミで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{Broadcastパケットの性質}
Broacdcastパケットの性質として大きすぎるデータの送信ができないという性質がある。どの程度の大きさのパケットまで送れるかをテストしてみたところ、64000byteまでだと送信可能であることがわかった。
もう一つの性質にパケットが消失(ロスト)しても特定することができないという性質がある。
MulticastについてもBroadcastと同じ性質を持っている。

\subsection{消失したパケットの検出}
Broadcastの性質で説明したとおり、Broadcastではデータが消失したことをクライアントが検出することができない。そこでプロトコルを拡張し、データごとにシリアル番号を振り、連続でない値が来た場合、正しくデータが届いていないと判断し、データの消失を検出することができる。

\subsection{Acknowledgeの設計}
データが消失したのを検出した際、どのような対応をとるのかが問題になる。シリアル番号を振っているのでサーバ対して、消失したデータのシリアル番号を指定することで、消失したデータの再送が可能となる。この際、再送にBroadcastを用いると、またデータの消失が起こるので、消失したデータを再送する際はTCPコネクションを用いて送信を行うのが良い。

\subsection{Broadcastを使用した送信}
Broadcastを使用する場合は一度に送信するパケットのサイズを64000byte以下にしなければならない。もし、1920*1080のサイズの画像データを送信する際、約600万byte(1920*1080*3)となってしまう。これでは送信することができないのでデータを分割し64000byte以下にして送信しなければならない。
作成したTreeVNCでは、サーバから受け取った画像データをRoot Nodeが一旦解凍して、再圧縮し、Nodeへ送信するという方式を取っている。
一旦解凍した後はRawDataとなるのでデータを分割することができる。TreeVNCではZRLEエンコーディングを使用している。ZRLE解凍すると左から右へ上から下への順の64*64のタイル群のRawDataとなる。
解凍されたRawDataを図\ref{fig:rawdata}に示す。


\begin{figure}[!htbp]
\begin{center}
\includegraphics[width=110mm]{./images/rawdata.pdf}
\end{center}
\caption{RawDataの構造}
\label{fig:rawdata}
\end{figure}

テストで、図\ref{fig:comparenormalandtree}のように2列づつに分割して送信するプログラムを書いた。
書いたテストプログラムでは、毎回バッファをコピーして送っているため処理が重かった。

BroadcastとMulticastでどのくらいパケットロスするかのテストも行った。
BroadcastとMulticastを用いてそれぞれのbyte数を100packetずつ送信しパケットのロス率を測った。その結果を表したのが表\ref{tb:testofbroadcastandmulticast}である。
表\ref{tb:testofbroadcastandmulticast}にあるようにMulticastを用いても、4000byteを100packet続けて送信すると37\%もパケットロスしてしまう。

\begin{table}[htbp]
\caption{BroadcastとMulticastのテスト}
\label{tb:testofbroadcastandmulticast}
\begin{center}
  \begin{tabular}{|c|c|c|} \hline
    & 256byte & 4000byte  \\ \hline
    Broadcasst & 47\% &87\%  \\ \hline
    Multicast & 0\% &37\%  \\ \hline
  \end{tabular}
\end{center}
\end{table}



結果として、データ分割の処理が重い、且つ予想以上のパケットロス率という結果をになったので、BraodcastやMulticastを用いた実装にはもう少し工夫が必要だということがわかった。