changeset 37:f7a79686256d default tip

update mid
author riono <e165729@ie.u-ryukyu.ac.jp>
date Mon, 17 Feb 2020 00:04:06 +0900
parents a2a82eead86f
children
files FinalMid/FinalMid_165729B.pdf FinalMid/FinalMid_165729B.tex FinalMid/reference.bib FinalThesis/FinalThesis_165729B.pdf FinalThesis/main.pdf FinalThesis/thanks.tex riono-thesis.pdf
diffstat 7 files changed, 96 insertions(+), 23 deletions(-) [+]
line wrap: on
line diff
Binary file FinalMid/FinalMid_165729B.pdf has changed
--- a/FinalMid/FinalMid_165729B.tex	Sun Feb 16 23:28:04 2020 +0900
+++ b/FinalMid/FinalMid_165729B.tex	Mon Feb 17 00:04:06 2020 +0900
@@ -7,6 +7,7 @@
 \usepackage{here}
 \usepackage{cite}
 \usepackage{url}
+\usepackage{geometry}
 
 \usepackage{caption}
 
@@ -76,8 +77,9 @@
 \end{center}
 \end{figure}
 
-%\newpage
-\thispagestyle{fancy}
+
+%\thispagestyle{fancy}
+
 
 バイナリツリー状に接続することで、N台のクライアントが接続を行ってきた場合、従来のVNCではサーバ側がN回のコピーを行って画面配信する必要があるが、TreeVNCでは各ノードが最大2回ずつコピーするだけで画面配信が可能となる。
 
@@ -90,7 +92,6 @@
 
 ZLREはZlibで圧縮されたデータとそのデータのバイト数がヘッダーとして付与され送信される。
 
-\newpage
 
 Zlibはjava.util.zip.deflaterとjava.util.zip.inflaterで圧縮と解凍が行える。しかしjava.util.zip.deflaterは解凍に必要な辞書を書きだす(flush)ことが出来ない。従って、圧縮されたデータを途中から受け取ってもデータを正しく解凍することが出来ない。
 
@@ -115,19 +116,9 @@
 WifiのMulticast Packetのサイズは64KByteが最大となっている。4Kディスプレイを例にとると、4Kディスプレイの大きさの画面更新には8MByte(画素数) \* 8Byte(色情報)で圧縮前で、64MByte程度となる。これを圧縮しつつ、64kbye毎のパケットに変換して送る必要がある。
 
 
-TileLoopはVNCサーバから受け取ったZRLEを図\ref{fig:BlockingUpdateRectangle}のようにRectangleを分割し、ZRLEEに再圧縮を行ったPacketを生成する。
-
+VNCサーバから受け取ったZRLEで構成された画像データをZRLEEに変換、再構成するためにTileLoopというルーチンで再構成を行う。
 
-\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を構成する必要がある。
+TileLoopはVNCサーバから受け取ったZRLEを図\ref{fig:BlockingUpdateRectangle}のようにRectangleを分割し、ZRLEEに再圧縮を行ったPacketを生成する。
 
 \begin{figure}[htb] %PDF
 \begin{center}
@@ -137,11 +128,32 @@
 \end{center}
 \end{figure}
 
+
+
+Tile内はパレットなどがある場合があるが、通常はRun Length encodeされたRGBデータである。
+これまでのTreeVNCではVNCサーバから受け取ったRectangleを分割せずにZRLEEへ再構成を行なっていた。これをMluticastのためにデータを64KByteに収まる最大3つのRectangleに再構成する(図\ref{fig:Packet})。この時にTile内部は変更する必要はないが、Rectangleの構成は変わる。ZLREを展開しつつ、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}
+
+
+
 64KByteのPacketの中には複数のTileが存在するが、連続してRectangleを構成する必要がある。3つの
 Rectangleの構成を下記に示す。
 
+\begin{itemize}
+\item 行の途中から始まり、行の最後までを構成するRectangle(図\ref{fig:BlockingUpdateRectangle}中 Phase0)
+\item 行の初めから最後までを構成するRectangle(図\ref{fig:BlockingUpdateRectangle}中 Phase1)
+\item 行の初めから、行の途中までを構成するRectangle(図\ref{fig:BlockingUpdateRectangle}中 Phase2)
+\end{itemize}
 
-TileLoopにはc1Rectと呼ばれるRectangleを持っている。これは読み込んだTile分だけ縦横を拡張していくことによってRectangleの再構成を行なっている。図\ref{fig:TileLoopFlow} 中2の圧縮段階では、読み込んだTileのデータを圧縮用のStreamに格納し、java.util.zip.deflaterを利用して圧縮を行っている。Packetのサイズは60KByteとしているが、一旦の制限として42KByteまでを格納可能としている。
+ZRLEとjava.util.zip.deflaterを使用した圧縮では、圧縮後のデータ長を予測することができない。Packetが満杯になってしまうと、圧縮書き込みの途中であっても圧縮書き込みが中断する。そのため、Packetのサイズを余分に確保する必要がある。したがって最初から最大の64KByteではなく、42KByteに制限を行っている。
+
 
 java.util.zip.deflaterには下記の3種類の圧縮方法がある。
 
@@ -151,22 +163,31 @@
 \item FULL\_FLUSH : SYNC\_FLUSH同様、これまでにStreamに格納されたデータの圧縮を行う。異なる点はこれまでの辞書情報がリセットされるため、圧縮率が極端に低くなる可能性がある
 \end{itemize}
 
+TileLoopではデータの圧縮にNO\_FLUSHを利用していたが、圧縮後のデータがPacketの上限である64KByteを超えてしまうことが多発した。
+
+これは圧縮されるための入力データの規定量が想定以上に多く、圧縮後のデータ長がMulticast Packetの上限を越えてしまったためである。
+
+そこで圧縮率は悪くなるが、1Tile毎に確実にPacketに書き込まれるSYNC\_FLUSHを利用し、ZRLEEの生成を行う。また各行末ではFULL\_FLUSHを行い、Packetへの書き込みを行なっている。
+
 
 \section{TreeVNC開発環境やソースコードの修正改善}
+jarファイルの生成や、アプリケーションの生成を行なっているGradleのバージョンが4.8であったため、これを現行の最新バージョンである6.1でBuildできるよう対応を行なった。
+また、Javaで使用しているRetinaディスプレイのAPIがJava8以前のものを使用していた。これはJava9以降で非推奨となってしまったため、Java9以降に対応できるようAPIの書き換えを行なった。
+
+TreeVNCのデバッグにはこれまで、1つのPC上でサーバ側とクライアント側を同時に起動してデバッグを行なっていた。本来はこれを1つのプロセスでデバッグできる-pオプションがあるが、TreeVNCの仕様変更などにより、使用不可となっていた。Blockingデバッグは非常に多く行う必要があったため、-pオプションの修正を行い、1つのプロセスでデバッグを可能とした。
 
 \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接続かを完全に区別できない。接続時にユーザが選択するか、接続時にある程度区別する処理を実装する必要がある。
 
-
+Blockingでは1Tile毎にSYNC\_FLUSHを行なっているが、NO\_FLUSHを利用した時と比べて、圧縮率が下がってしまっているため、圧縮率の向上の手法を考察する必要がある。
 
 
 
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/FinalMid/reference.bib	Mon Feb 17 00:04:06 2020 +0900
@@ -0,0 +1,53 @@
+@Misc{rfbprotocol,
+  author = "{RICHARDSON, T., AND LEVINE, J.}",
+  title = "The remote framebuffer protocol. RFC 6143",
+  month = "mar",
+  year = 2011
+}
+
+@Misc{tightvnc,
+  author       = "{TightVNC Software}",
+  howpublished = "\url{http://www.tightvnc.com}"
+}
+
+@Misc{vnc,
+    author = "{RICHARDSON, T., STAFFORD-FRASER, Q., WOOD, K. R., AND HOPPER,}",
+    title  = "A. Virtual Network Computing",
+    month = "jan",
+    year = 1998
+}
+
+@Misc{zlib,
+    author = "{LOUP GAILLY, J., AND ADLER, M.}",
+    title = "zlib: A massively spiffy yet delicately unobtrusive compression library.",
+    howpublished = "\url{http://zlib.net}"
+
+}
+
+
+@article{taninari:2011a,
+    author = "{Yu TANINARI and Nobuyasu OSHIRO and Shinji KONO}",
+    title = "VNCを用いた授業用画面共有システムの実装と設計",
+    journal = "日本ソフトウェア科学会第28回大会論文集",
+    month = "sep",
+    year = 2011
+}
+
+@article{taninari:2012a,
+    author = "{Yu TANINARI and Nobuyasu OSHIRO and Shinji KONO}",
+    title = "VNCを用いた授業用画面共有システムの設計・開発",
+    journal = "情報処理学会 システムソフトウェアとオペレーティング・システム研究会(OS)",
+    month = "may",
+    year = 2012
+}
+
+@inproceedings{weko_176504_1,
+   author	 = "伊波,立樹 and 河野,真治",
+   title	 = "有線LAN上のPC画面配信システムTreeVNCの改良",
+   booktitle	 = "第57回プログラミング・シンポジウム予稿集",
+   year 	 = "2016",
+   volume	 = "2016",
+   number	 = "",
+   pages	 = "29--37",
+   month	 = "jan"
+}
\ No newline at end of file
Binary file FinalThesis/FinalThesis_165729B.pdf has changed
Binary file FinalThesis/main.pdf has changed
--- a/FinalThesis/thanks.tex	Sun Feb 16 23:28:04 2020 +0900
+++ b/FinalThesis/thanks.tex	Mon Feb 17 00:04:06 2020 +0900
@@ -9,14 +9,13 @@
 
 \hspace{1zw}本研究の遂行,また本論文の作成にあたり、御多忙にも関わらず終始懇切なる御指導と御教授を賜わりました河野真治准教授に深く感謝したします。
 
-また、本研究の遂行及び本論文の作成にあたり、日頃より終始懇切なる御教授と御指導を賜わりましたhoge教授に心より深く感謝致します。
+数々の貴重な御助言と細かな御配慮を戴いた並列信頼研究室の外間政尊さん、桃原優さん、清水隆博さん、東恩納琢偉さんに深く感謝致します。
 
-数々の貴重な御助言と細かな御配慮を戴いた研究室のhoge氏に深く感謝致します。
-
-また一年間共に研究を行い、暖かな気遣いと励ましをもって支えてくれたhoge研究室のhoge君、hoge君、hogeさん並びにhoge研究室のhoge、hoge君、hoge君、hoge君、hoge君に感謝致します。
+また一年間共に研究を行い、暖かな気遣いと励ましをもって支えてくれた並列信頼研究室の一木貴裕君、坂本昂弘君、福田光希君に感謝致します。
 
 最後に、有意義な時間を共に過ごした情報工学科の学友、並びに物心両面で支えてくれた両親に深く感謝致します。
 
+
 \begin{flushright}
  2020年 2月 \\ 安田亮
 \end{flushright}
Binary file riono-thesis.pdf has changed