|
1
|
1 \documentclass[twocolumn,twoside,9.5pt]{jarticle}
|
|
|
2 \usepackage{picins}
|
|
|
3 \usepackage{fancyhdr}
|
|
18
|
4 \usepackage{abstract}
|
|
35
|
5 \usepackage[dvipdfmx]{graphicx}
|
|
|
6 \usepackage{multirow}
|
|
|
7 \usepackage{here}
|
|
|
8 \usepackage{cite}
|
|
|
9 \usepackage{url}
|
|
37
|
10 \usepackage{geometry}
|
|
35
|
11
|
|
|
12 \usepackage{caption}
|
|
|
13
|
|
18
|
14
|
|
1
|
15 \pagestyle{fancy}
|
|
|
16 \lhead{\parpic{\includegraphics[height=1zw,keepaspectratio,bb=0 0 251 246]{pic/emblem-bitmap.pdf}}琉球大学主催 工学部情報工学科 卒業研究発表会}
|
|
|
17 \rhead{}
|
|
|
18 \cfoot{}
|
|
|
19
|
|
|
20 \setlength{\topmargin}{-1in \addtolength{\topmargin}{15mm}}
|
|
|
21 \setlength{\headheight}{0mm}
|
|
|
22 \setlength{\headsep}{5mm}
|
|
|
23 \setlength{\oddsidemargin}{-1in \addtolength{\oddsidemargin}{11mm}}
|
|
|
24 \setlength{\evensidemargin}{-1in \addtolength{\evensidemargin}{21mm}}
|
|
|
25 \setlength{\textwidth}{181mm}
|
|
|
26 \setlength{\textheight}{261mm}
|
|
|
27 \setlength{\footskip}{0mm}
|
|
|
28 \pagestyle{empty}
|
|
|
29
|
|
25
|
30
|
|
|
31 \renewcommand{\abstractname}{Abstract}
|
|
1
|
32 \begin{document}
|
|
35
|
33 \title{画面配信システム TreeVNC のMulticast 導入}
|
|
|
34 \author{165729B 氏名 {安田}{亮} 指導教員 : 河野真治}
|
|
1
|
35 \date{}
|
|
18
|
36 \twocolumn [
|
|
1
|
37 \maketitle
|
|
18
|
38 \centering
|
|
|
39 \begin{onecolabstract}
|
|
35
|
40 In lectures and seminars，the materials prepared on the PC screen is used.
|
|
|
41 Participants need to concentrate on the projector，which can be a burden when cross-referencing with the PC at hand.
|
|
|
42 When the presenter is replaced，the cable needs to be replaced by switching the presenter's PC screen,
|
|
|
43 depending on the adapter connected to the PC，the PC screen may not be displayed properly.
|
|
|
44 TreeVNC，which is being developed in our laboratory，is a screen distribution system that displays the presenter's PC screen on the participant's PC.
|
|
|
45 By connecting clients connected to the server in the form of a binary tree and distributing the delivery cost,
|
|
|
46 It is designed so that the processing performance does not decrease even if many people connect.
|
|
|
47 In addition，there is a mechanism for freely switching the screen of the presenter，which is convenient for presentations at seminars and the like.
|
|
|
48 Currently，TreeVNC screen sharing is limited to wired LANs because of the large amount of data.
|
|
|
49 To support widely used wireless LAN,
|
|
|
50 we evaluate the implementation of data communication in multicast and the data division
|
|
|
51 and compression method，and evaluate the possibility of multicast in TreeVNC.
|
|
18
|
52 \end{onecolabstract} ]
|
|
|
53
|
|
1
|
54 \thispagestyle{fancy}
|
|
|
55
|
|
18
|
56
|
|
|
57
|
|
35
|
58 \section{画面配信ソフトウェアTreeVNCの活用}
|
|
|
59 現代の講義やゼミではPC画面で用意した資料をプロジェクタに映しながら進行することが多い。
|
|
|
60 発表者のPCを接続するたびにケーブルを差し替える必要があり、発表者のPCによっては接続するアダプターの種類や解像度の設定により、正常にPC画面を表示できない場合がある。また、参加者もプロジェクタに集中を割く必要があり、同時に手元のPCで作業を行う場合、集中の妨げとなってしまう。
|
|
1
|
61
|
|
35
|
62 当研究室で開発している画面配信システムTreeVNC\cite{taninari:2011a}は、発表者のPC画面を参加者のPC画面に表示するソフトウェアである。サーバに接続したクライアントをバイナリツリー状に接続することで、配信コストをクライアントに分散させる仕組みになっている。
|
|
|
63 しかし、画面共有は送信するデータ量が多いため、無線LANで接続を行なった際に有線接続よりも遅延が大きくなってしまう。そこで本研究では、Multicastでのデータ通信の考察やデータの分割・圧縮方法の実装、評価を行う。
|
|
1
|
64
|
|
35
|
65 \section{TreeVNCの基本概念}
|
|
36
|
66 Virtual Network Computing\cite{vnc}(以下VNC)は、サーバ側とクライアント(ビューワー)側からなるリモートデスクトップソフトウェアである。遠隔操作にはサーバを起動し、クライアント側がサーバに接続することで可能としている。特に画面送信の動作にはRemote Frame Buffer(以下RFB)プロトコル\cite{rfbprotocol}を用いている。
|
|
|
67
|
|
|
68 TreeVNCはjavaを用いて作成されたTight VNC\cite{tightvnc}を元に作成されている。 TreeVNCはVNCを利用して画面配信を行っているが、従来のVNCでは配信(サーバ)側のPCに全ての参加者(クライアント)が接続するため負荷が大きくなってしまう。
|
|
|
69
|
|
|
70 そこでTreeVNCではサーバに接続を行ってきたクライアントをバイナリツリー状(木構造)に接続する。接続してきたクライアントをノードとし、その下に新たなノードを最大2つ接続していく。これにより人数分のデータのコピーと送信の手間を分散することができる(図\ref{fig:TreevncStruct})。
|
|
|
71
|
|
|
72 \begin{figure}[htb] %PDF
|
|
|
73 \begin{center}
|
|
|
74 \includegraphics[scale=0.28]{pic/TreevncStruct.pdf}
|
|
|
75 \caption{TreeVNCでの接続構造}
|
|
|
76 \label{fig:TreevncStruct}
|
|
|
77 \end{center}
|
|
|
78 \end{figure}
|
|
|
79
|
|
37
|
80
|
|
|
81 %\thispagestyle{fancy}
|
|
|
82
|
|
36
|
83
|
|
|
84 バイナリツリー状に接続することで、N台のクライアントが接続を行ってきた場合、従来のVNCではサーバ側がN回のコピーを行って画面配信する必要があるが、TreeVNCでは各ノードが最大2回ずつコピーするだけで画面配信が可能となる。
|
|
|
85
|
|
|
86
|
|
|
87
|
|
|
88 TreeVNCはZRLEE\cite{taninari:2012a}というエンコードタイプでデータのやり取りを行う。ZRLEEはRFBプロトコルで使用できるZLREというエンコードタイプを元に生成される。
|
|
|
89
|
|
|
90 ZLRE(Zlib Run-Length Encoding)とは可逆圧縮可能なZlib形式\cite{zlib}とRun-Length Encoding方式を組み合わせたエンコードタイプである。
|
|
|
91
|
|
|
92
|
|
|
93 ZLREはZlibで圧縮されたデータとそのデータのバイト数がヘッダーとして付与され送信される。
|
|
|
94
|
|
|
95
|
|
|
96 Zlibはjava.util.zip.deflaterとjava.util.zip.inflaterで圧縮と解凍が行える。しかしjava.util.zip.deflaterは解凍に必要な辞書を書きだす(flush)ことが出来ない。従って、圧縮されたデータを途中から受け取ってもデータを正しく解凍することが出来ない。
|
|
35
|
97
|
|
|
98
|
|
|
99
|
|
36
|
100 そこでZRLEEは一度Root Nodeで受け取ったZRLEのデータをunzipし、Update Rectangleと呼ばれる画面ごとのデータに辞書を付与してzipし直すことで、初めからデータを読み込んでいなくても解凍を出来るようになっている(図\ref{fig:ZRLEtoZRLEE})。
|
|
|
101
|
|
|
102 \begin{figure}[htb] %PDF
|
|
|
103 \begin{center}
|
|
|
104 \includegraphics[scale=0.5]{pic/EncodeZRLEtoZRLEE.pdf}
|
|
|
105 \caption{ZRLEEへ再圧縮されたデータを途中から受け取った場合}
|
|
|
106 \label{fig:ZRLEtoZRLEE}
|
|
|
107 \end{center}
|
|
|
108 \end{figure}
|
|
|
109
|
|
|
110
|
|
35
|
111 \section{Multicatに向けたBlockingの実装}
|
|
36
|
112 画像配信のデータ量は膨大なため、現在のTreeVNCでVNCサーバに無線LAN接続を行なった場合、画面配信の遅延が大きくなってしまう。
|
|
|
113
|
|
|
114 無線LAN接続時の場合でも画面切り替えの機能は有効であるため、VNCサーバ側が無線LANで接続を行い、クライアント側は有線接続を行うことで画面配信が可能となる。ここで、WifiのMulticastの機能を用いてクライアント側でもWifiを使用することが可能であると考えられる。
|
|
|
115
|
|
|
116 WifiのMulticast Packetのサイズは64KByteが最大となっている。4Kディスプレイを例にとると、4Kディスプレイの大きさの画面更新には8MByte(画素数) \* 8Byte(色情報)で圧縮前で、64MByte程度となる。これを圧縮しつつ、64kbye毎のパケットに変換して送る必要がある。
|
|
|
117
|
|
|
118
|
|
37
|
119 VNCサーバから受け取ったZRLEで構成された画像データをZRLEEに変換、再構成するためにTileLoopというルーチンで再構成を行う。
|
|
36
|
120
|
|
37
|
121 TileLoopはVNCサーバから受け取ったZRLEを図\ref{fig:BlockingUpdateRectangle}のようにRectangleを分割し、ZRLEEに再圧縮を行ったPacketを生成する。
|
|
36
|
122
|
|
|
123 \begin{figure}[htb] %PDF
|
|
|
124 \begin{center}
|
|
|
125 \includegraphics[scale=0.4]{pic/FrameUpdateRectangle.pdf}
|
|
|
126 \caption{Rectangleの分割}
|
|
|
127 \label{fig:BlockingUpdateRectangle}
|
|
|
128 \end{center}
|
|
|
129 \end{figure}
|
|
|
130
|
|
37
|
131
|
|
|
132
|
|
|
133 Tile内はパレットなどがある場合があるが、通常はRun Length encodeされたRGBデータである。
|
|
|
134 これまでのTreeVNCではVNCサーバから受け取ったRectangleを分割せずにZRLEEへ再構成を行なっていた。これをMluticastのためにデータを64KByteに収まる最大3つのRectangleに再構成する(図\ref{fig:Packet})。この時にTile内部は変更する必要はないが、Rectangleの構成は変わる。ZLREを展開しつつ、Packetを構成する必要がある。
|
|
|
135
|
|
|
136 \begin{figure}[htb] %PDF
|
|
|
137 \begin{center}
|
|
|
138 \includegraphics[scale=0.3]{pic/Blocking.pdf}
|
|
|
139 \caption{ZRLEEのPacketの構成と分割されたRectangle}
|
|
|
140 \label{fig:Packet}
|
|
|
141 \end{center}
|
|
|
142 \end{figure}
|
|
|
143
|
|
|
144
|
|
|
145
|
|
36
|
146 64KByteのPacketの中には複数のTileが存在するが、連続してRectangleを構成する必要がある。3つの
|
|
|
147 Rectangleの構成を下記に示す。
|
|
|
148
|
|
37
|
149 \begin{itemize}
|
|
|
150 \item 行の途中から始まり、行の最後までを構成するRectangle(図\ref{fig:BlockingUpdateRectangle}中 Phase0)
|
|
|
151 \item 行の初めから最後までを構成するRectangle(図\ref{fig:BlockingUpdateRectangle}中 Phase1)
|
|
|
152 \item 行の初めから、行の途中までを構成するRectangle(図\ref{fig:BlockingUpdateRectangle}中 Phase2)
|
|
|
153 \end{itemize}
|
|
36
|
154
|
|
37
|
155 ZRLEとjava.util.zip.deflaterを使用した圧縮では、圧縮後のデータ長を予測することができない。Packetが満杯になってしまうと、圧縮書き込みの途中であっても圧縮書き込みが中断する。そのため、Packetのサイズを余分に確保する必要がある。したがって最初から最大の64KByteではなく、42KByteに制限を行っている。
|
|
|
156
|
|
36
|
157
|
|
|
158 java.util.zip.deflaterには下記の3種類の圧縮方法がある。
|
|
|
159
|
|
|
160 \begin{itemize}
|
|
|
161 \item NO\_FLUSH : Streamに格納されたデータを最高率で圧縮を行う。Streamにある入力データが規定量に満たない場合は圧縮されない
|
|
|
162 \item SYNC\_FLUSH : これまでにStreamに格納されたデータの圧縮を行う。ただし圧縮率が低下する可能性がある
|
|
|
163 \item FULL\_FLUSH : SYNC\_FLUSH同様、これまでにStreamに格納されたデータの圧縮を行う。異なる点はこれまでの辞書情報がリセットされるため、圧縮率が極端に低くなる可能性がある
|
|
|
164 \end{itemize}
|
|
1
|
165
|
|
37
|
166 TileLoopではデータの圧縮にNO\_FLUSHを利用していたが、圧縮後のデータがPacketの上限である64KByteを超えてしまうことが多発した。
|
|
|
167
|
|
|
168 これは圧縮されるための入力データの規定量が想定以上に多く、圧縮後のデータ長がMulticast Packetの上限を越えてしまったためである。
|
|
|
169
|
|
|
170 そこで圧縮率は悪くなるが、1Tile毎に確実にPacketに書き込まれるSYNC\_FLUSHを利用し、ZRLEEの生成を行う。また各行末ではFULL\_FLUSHを行い、Packetへの書き込みを行なっている。
|
|
|
171
|
|
1
|
172
|
|
35
|
173 \section{TreeVNC開発環境やソースコードの修正改善}
|
|
37
|
174 jarファイルの生成や、アプリケーションの生成を行なっているGradleのバージョンが4.8であったため、これを現行の最新バージョンである6.1でBuildできるよう対応を行なった。
|
|
|
175 また、Javaで使用しているRetinaディスプレイのAPIがJava8以前のものを使用していた。これはJava9以降で非推奨となってしまったため、Java9以降に対応できるようAPIの書き換えを行なった。
|
|
|
176
|
|
|
177 TreeVNCのデバッグにはこれまで、1つのPC上でサーバ側とクライアント側を同時に起動してデバッグを行なっていた。本来はこれを1つのプロセスでデバッグできる-pオプションがあるが、TreeVNCの仕様変更などにより、使用不可となっていた。Blockingデバッグは非常に多く行う必要があったため、-pオプションの修正を行い、1つのプロセスでデバッグを可能とした。
|
|
35
|
178
|
|
|
179 \section{まとめ}
|
|
36
|
180 本研究ではTreeVNCにWifi上のMulticast Packetを用いる手法の考察と実装と、Gradle6.1対応、java9以降のRetinaAPI対応、デバッグオプションの修正を行った。
|
|
|
181
|
|
|
182 画面圧縮にHardware supportedなMPEG4などを用いることができればより効率的な転送が可能であるが、ここではJava上で実装できる安易な方法をあえて選択した。Wifiの速度とMulticastの信頼性が高ければこれでも実用になる可能性がある。
|
|
|
183
|
|
|
184 Blocking後のMulticast 送信は実装中であるが、Multicast PacketのPacket loss率は、接続環境に依存すると思われるのでさらなる実験が必要だと思われる。
|
|
|
185
|
|
37
|
186 有線接続時よりも、画面共有の質が落ちるのはある程度はやむを得ないが、再送が必要である場合には、必要なプロトコルを実装する。
|
|
36
|
187
|
|
|
188 VNCサーバへの接続方法の分割についても、Node接続時のNetwork Interfacesから有線接続か無線LAN接続かを完全に区別できない。接続時にユーザが選択するか、接続時にある程度区別する処理を実装する必要がある。
|
|
|
189
|
|
37
|
190 Blockingでは1Tile毎にSYNC\_FLUSHを行なっているが、NO\_FLUSHを利用した時と比べて、圧縮率が下がってしまっているため、圧縮率の向上の手法を考察する必要がある。
|
|
36
|
191
|
|
35
|
192
|
|
1
|
193
|
|
|
194 \thispagestyle{fancy}
|
|
35
|
195 \nocite{*}
|
|
|
196 \bibliographystyle{junsrt}
|
|
|
197 \bibliography{reference}
|
|
|
198 %\addcontentsline{toc}{chapter}{参考文献}
|
|
1
|
199
|
|
|
200 \end{document} |
