--- a/FinalMid/FinalMid_165729B.tex	Sun Feb 16 22:52:07 2020 +0900
+++ b/FinalMid/FinalMid_165729B.tex	Sun Feb 16 23:28:04 2020 +0900
@@ -62,16 +62,112 @@
 しかし、画面共有は送信するデータ量が多いため、無線LANで接続を行なった際に有線接続よりも遅延が大きくなってしまう。そこで本研究では、Multicastでのデータ通信の考察やデータの分割・圧縮方法の実装、評価を行う。
 
 \section{TreeVNCの基本概念}
+Virtual Network Computing\cite{vnc}(以下VNC)は、サーバ側とクライアント(ビューワー)側からなるリモートデスクトップソフトウェアである。遠隔操作にはサーバを起動し、クライアント側がサーバに接続することで可能としている。特に画面送信の動作にはRemote Frame Buffer(以下RFB)プロトコル\cite{rfbprotocol}を用いている。
+
+TreeVNCはjavaを用いて作成されたTight VNC\cite{tightvnc}を元に作成されている。 TreeVNCはVNCを利用して画面配信を行っているが、従来のVNCでは配信(サーバ)側のPCに全ての参加者(クライアント)が接続するため負荷が大きくなってしまう。
+
+そこでTreeVNCではサーバに接続を行ってきたクライアントをバイナリツリー状(木構造)に接続する。接続してきたクライアントをノードとし、その下に新たなノードを最大2つ接続していく。これにより人数分のデータのコピーと送信の手間を分散することができる(図\ref{fig:TreevncStruct})。
+
+\begin{figure}[htb]　%PDF
+\begin{center}
+\includegraphics[scale=0.28]{pic/TreevncStruct.pdf}
+\caption{TreeVNCでの接続構造}
+\label{fig:TreevncStruct}
+\end{center}
+\end{figure}
+
+%\newpage
+\thispagestyle{fancy}
+
+バイナリツリー状に接続することで、N台のクライアントが接続を行ってきた場合、従来のVNCではサーバ側がN回のコピーを行って画面配信する必要があるが、TreeVNCでは各ノードが最大2回ずつコピーするだけで画面配信が可能となる。
+
+
+
+TreeVNCはZRLEE\cite{taninari:2012a}というエンコードタイプでデータのやり取りを行う。ZRLEEはRFBプロトコルで使用できるZLREというエンコードタイプを元に生成される。
+
+ZLRE(Zlib Run-Length Encoding)とは可逆圧縮可能なZlib形式\cite{zlib}とRun-Length Encoding方式を組み合わせたエンコードタイプである。
+
+
+ZLREはZlibで圧縮されたデータとそのデータのバイト数がヘッダーとして付与され送信される。
+
+\newpage
+
+Zlibはjava.util.zip.deflaterとjava.util.zip.inflaterで圧縮と解凍が行える。しかしjava.util.zip.deflaterは解凍に必要な辞書を書きだす(flush)ことが出来ない。従って、圧縮されたデータを途中から受け取ってもデータを正しく解凍することが出来ない。
 
 
 
+そこでZRLEEは一度Root Nodeで受け取ったZRLEのデータをunzipし、Update Rectangleと呼ばれる画面ごとのデータに辞書を付与してzipし直すことで、初めからデータを読み込んでいなくても解凍を出来るようになっている(図\ref{fig:ZRLEtoZRLEE})。
+
+\begin{figure}[htb]　%PDF
+\begin{center}
+\includegraphics[scale=0.5]{pic/EncodeZRLEtoZRLEE.pdf}
+\caption{ZRLEEへ再圧縮されたデータを途中から受け取った場合}
+\label{fig:ZRLEtoZRLEE}
+\end{center}
+\end{figure}
+
+
 \section{Multicatに向けたBlockingの実装}
+画像配信のデータ量は膨大なため、現在のTreeVNCでVNCサーバに無線LAN接続を行なった場合、画面配信の遅延が大きくなってしまう。
+
+無線LAN接続時の場合でも画面切り替えの機能は有効であるため、VNCサーバ側が無線LANで接続を行い、クライアント側は有線接続を行うことで画面配信が可能となる。ここで、WifiのMulticastの機能を用いてクライアント側でもWifiを使用することが可能であると考えられる。
+
+WifiのMulticast Packetのサイズは64KByteが最大となっている。4Kディスプレイを例にとると、4Kディスプレイの大きさの画面更新には8MByte(画素数) \* 8Byte(色情報)で圧縮前で、64MByte程度となる。これを圧縮しつつ、64kbye毎のパケットに変換して送る必要がある。
+
+
+TileLoopはVNCサーバから受け取ったZRLEを図\ref{fig:BlockingUpdateRectangle}のようにRectangleを分割し、ZRLEEに再圧縮を行ったPacketを生成する。
+
+
+\begin{figure}[htb]　%PDF
+\begin{center}
+\includegraphics[scale=0.3]{pic/Blocking.pdf}
+\caption{ZRLEEのPacketの構成と分割されたRectangle}
+\label{fig:Packet}
+\end{center}
+\end{figure}
+
+Tile内はパレットなどがある場合があるが、通常はRun Length encodeされたRGBデータである。
+これまでのTreeVNCではVNCサーバから受け取ったRectangleを分割せずにZRLEEへ再構成を行なっていた。これをMluticastのためにデータを64KByteに収まる最大3つのRectangleに再構成する(図\ref{fig:BlockingUpdateRectangle})。この時にTile内部は変更する必要はないが、Rectangleの構成は変わる。ZLREを展開しつつ、Packetを構成する必要がある。
+
+\begin{figure}[htb]　%PDF
+\begin{center}
+\includegraphics[scale=0.4]{pic/FrameUpdateRectangle.pdf}
+\caption{Rectangleの分割}
+\label{fig:BlockingUpdateRectangle}
+\end{center}
+\end{figure}
+
+64KByteのPacketの中には複数のTileが存在するが、連続してRectangleを構成する必要がある。3つの
+Rectangleの構成を下記に示す。
+
+
+TileLoopにはc1Rectと呼ばれるRectangleを持っている。これは読み込んだTile分だけ縦横を拡張していくことによってRectangleの再構成を行なっている。図\ref{fig:TileLoopFlow} 中2の圧縮段階では、読み込んだTileのデータを圧縮用のStreamに格納し、java.util.zip.deflaterを利用して圧縮を行っている。Packetのサイズは60KByteとしているが、一旦の制限として42KByteまでを格納可能としている。
+
+java.util.zip.deflaterには下記の3種類の圧縮方法がある。
+
+\begin{itemize}
+\item NO\_FLUSH : Streamに格納されたデータを最高率で圧縮を行う。Streamにある入力データが規定量に満たない場合は圧縮されない
+\item SYNC\_FLUSH : これまでにStreamに格納されたデータの圧縮を行う。ただし圧縮率が低下する可能性がある
+\item FULL\_FLUSH : SYNC\_FLUSH同様、これまでにStreamに格納されたデータの圧縮を行う。異なる点はこれまでの辞書情報がリセットされるため、圧縮率が極端に低くなる可能性がある
+\end{itemize}
 
 
 \section{TreeVNC開発環境やソースコードの修正改善}
 
 \section{まとめ}
 
+本研究ではTreeVNCにWifi上のMulticast Packetを用いる手法の考察と実装と、Gradle6.1対応、java9以降のRetinaAPI対応、デバッグオプションの修正を行った。
+
+画面圧縮にHardware supportedなMPEG4などを用いることができればより効率的な転送が可能であるが、ここではJava上で実装できる安易な方法をあえて選択した。Wifiの速度とMulticastの信頼性が高ければこれでも実用になる可能性がある。
+
+Blocking後のMulticast 送信は実装中であるが、Multicast PacketのPacket loss率は、接続環境に依存すると思われるのでさらなる実験が必要だと思われる。
+
+有線接続時よりも、画面共有の質が落ちるのはある程度はやむお得ないが、再送が必要である場合には、必要なプロトコルを実装する。
+
+VNCサーバへの接続方法の分割についても、Node接続時のNetwork Interfacesから有線接続か無線LAN接続かを完全に区別できない。接続時にユーザが選択するか、接続時にある程度区別する処理を実装する必要がある。
+
+
+
 
 
 \thispagestyle{fancy}

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/FinalMid/Makefile	Sun Feb 16 23:28:04 2020 +0900
@@ -0,0 +1,39 @@
+TARGET = FinalMid_165729B
+
+LATEX   = platex
+BIBTEX  = pbibtex
+DVIPS   = dvips
+DVIPDFM = dvipdfmx
+RM      = rm -f
+DVIPDF=dvipdfmx -p a4
+#  Option definitions
+#DVIPDFMOPT = 
+#DVIPSOPT   = -D 720 -mode esphi -O 0mm,0mm -N0 
+
+PDF_FILE = $(TARGET).pdf
+DVI_FILE = $(TARGET).dvi
+
+pdf: $(PDF_FILE)
+	open $(PDF_FILE)
+$(PDF_FILE): $(TARGET).tex $(DVI_FILE)
+	$(DVIPDF) $(DVIPDF_OPT) $(DVI_FILE)
+
+dvi : $(DVI_FILE)
+$(DVI_FILE): $(TARGET).tex
+	$(LATEX) -halt-on-error $(TARGET).tex
+	$(LATEX) $(TARGET).tex
+	$(BIBTEX) $(TARGET)
+	$(LATEX) $(TARGET).tex
+	$(LATEX) $(TARGET).tex
+
+
+all: $(PDF_FILE)
+	open $(PDF_FILE)
+
+#dvi: $(#TARGET).dvi
+
+#pdf: $(#TARGET).pdf
+
+
+clean:
+	rm -f *.dvi *.aux *.log *.pdf *.ps *.gz *.bbl *.blg *~ *.core

Binary file FinalMid/pic/Blocking.graffle has changed

Binary file FinalMid/pic/Blocking.pdf has changed

Binary file FinalMid/pic/EncodeZRLEtoZRLEE.graffle has changed

Binary file FinalMid/pic/EncodeZRLEtoZRLEE.pdf has changed

Binary file FinalMid/pic/FrameUpdateRectangle.graffle has changed

Binary file FinalMid/pic/FrameUpdateRectangle.pdf has changed

Binary file FinalMid/pic/TreevncStruct.graffle has changed

Binary file FinalMid/pic/TreevncStruct.pdf has changed