Mercurial > hg > Papers > 2020 > riono-sigos
changeset 16:87e6657871b5
fix
author | riono <e165729@ie.u-ryukyu.ac.jp> |
---|---|
date | Thu, 07 May 2020 23:25:08 +0900 |
parents | fa856091870b |
children | 209be9c6243a |
files | Paper/riono-sigos.bib Paper/riono-sigos.pdf Paper/riono-sigos.tex |
diffstat | 3 files changed, 9 insertions(+), 27 deletions(-) [+] |
line wrap: on
line diff
--- a/Paper/riono-sigos.bib Thu May 07 22:01:59 2020 +0900 +++ b/Paper/riono-sigos.bib Thu May 07 23:25:08 2020 +0900 @@ -24,13 +24,6 @@ } -@article{understandingScreenContents, - author = "{Surendar Chandra, Jacob T. Biehl, John Boreczky, Scott Carter, Lawrence A. Rowe}", - title = "Understanding Screen Contents for Building a High Performance, Real Time Screen Sharing System", - journal = "ACM Multimedia", - year = 2012, - month = "Oct" -} @article{taninari:2011a, author = "{Yu TANINARI and Nobuyasu OSHIRO and Shinji KONO}", title = "VNCを用いた授業用画面共有システムの実装と設計", @@ -45,15 +38,4 @@ 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
--- a/Paper/riono-sigos.tex Thu May 07 22:01:59 2020 +0900 +++ b/Paper/riono-sigos.tex Thu May 07 23:25:08 2020 +0900 @@ -65,7 +65,7 @@ \begin{abstract} 講義やゼミではPC画面で用意した資料を見ながら進行することが多い。PCごとにアダプターや解像度が異なっており、正常にPC画面を表示できない場合がある。 当研究室で開発しているTreeVNCは、発表者のPC画面を参加者のPCに表示する画面配信システムである。TreeVNCの画像共有は、送信するデータ量が多いために有線LANでの接続に限られている。 -本稿では無線LANでもTreeVNCを利用可能にするため、Wifi上にシステム制御用の従来の木構造と、画像データ送信用のMulticastの両方を構築を行う。 +本稿では無線LANでもTreeVNCを利用可能にするため、Wifi上にシステム制御用の従来の木構造と、画像データ送信用のMulticastの両方の構築を行う。 Multicastでは、サーバから送信された画像データUpdateRectangleを小さいパケットに分割し送信を行うよう実装した。 \end{abstract} @@ -96,9 +96,9 @@ Remote Frame Bufferプロトコル\cite{rfbprotocol}(以下RFB)とはVNC上で使用される、自身のPC画面をネットワーク上に送信し、他人のPC画面に表示を行うプロトコルである。画面が表示されるユーザ側をRFBクライアントと呼び、画面送信を行うためにFrameBufferの更新が行われる側をRFBサーバと呼ぶ。 -FrameBufferとは、メモリ上に置かれた画像データのことである。RFBプロトコルでは、最初にプロトコルのバージョンの確認や認証が行われる。その後、RFBクライアントへ向けてFramebuffferの大きさやデスクトップに付けられた名前などが含まれている初期メッセージを送信する。 +FrameBufferとは、メモリ上に置かれた画像データのことである。RFBプロトコルでは、最初にプロトコルのバージョンの確認や認証が行われる。その後、RFBクライアントへ向けてFrameBufferの大きさやデスクトップに付けられた名前などが含まれている初期メッセージを送信する。 -RFBサーバ側はFramebufferの更新が行われるたびに、RFBクライアントに対してFramebufferの変更部分を送信する。さらに、RFBクライアントからFramebuffer - UpdateRequestが来るとそれに答え返信する。変更部分のみを送信する理由は、更新があるたびに全画面を送信すると、送信するデータ面と更新にかかる時間面において効率が悪くなるからである。 +RFBサーバ側はFrameBufferの更新が行われるたびに、RFBクライアントに対してFrameBufferの変更部分を送信する。さらに、RFBクライアントからFrameBuffer - UpdateRequestが来るとそれに答え返信する。変更部分のみを送信する理由は、更新があるたびに全画面を送信すると、送信するデータ面と更新にかかる時間面において効率が悪くなるからである。 TreeVNCはjavaを用いて作成されたTight VNC\cite{tightvnc}を元に作成されている。TreeVNCはVNCを利用して画面配信を行なっているが、従来のVNCでは配信(サーバ)側のPCに全ての参加者(クライアント)が接続するため負荷が大きくなってしまう(図\ref{fig:vncStruct})。 @@ -142,7 +142,7 @@ \section{データの圧縮形式} TreeVNCでは、ZRLEE\cite{taninari:2012a}というエンコード方法でデータの圧縮を行う。ZRLEEはRFBプロトコルで使用できるZRLEというエンコードタイプを元に生成される。 -ZLRE(Zlib Run-Length Encoding)とは可逆圧縮可能なZlib形式\cite{zlib}とRun-Length Encoding方式を組み合わせたエンコードタイプである。 +ZRLE(Zlib Run-Length Encoding)とは可逆圧縮可能なZlib形式\cite{zlib}とRun-Length Encoding方式を組み合わせたエンコードタイプである。 ZLREはZlibで圧縮されたデータとそのデータのバイト数がヘッダーとして付与され送信される。Zlibはjava.util.zip.deflaterとjava.util.zip.inflaterで圧縮と解凍が行える。しかしjava.util.zip.deflaterは解凍に必要な辞書を書き出す(flush)ことができない。従って、圧縮されたデータを途中から受け取ってもデータを正しく解凍することができない。 @@ -281,9 +281,9 @@ java.util.zip.deflaterには下記の3種類の圧縮方法がある。 \begin{itemize} -\item NO\_FLUSH : Streamに格納されたデータを最効率で圧縮を行う。Streamにある入力データが規定量に満たない場合は圧縮されない -\item SYNC\_FLUSH : これまでにStreamに圧縮されたデータの圧縮を行う。ただし圧縮率が低下する可能性がある -\item FULL\_FLUSH : SYNC\_FLUSH同様、これまでにStreamに格納されたデータ圧縮を行う。異なる点はこれまでの辞書情報がリセットされるため、圧縮率が極端に低くなる可能性がある +\item NO\_FLUSH : Streamに格納されたデータを最効率で圧縮を行う。Streamにある入力データが規定量に満たない場合は圧縮されない。 +\item SYNC\_FLUSH : これまでにStreamに圧縮されたデータの圧縮を行う。ただし圧縮率が低下する可能性がある。 +\item FULL\_FLUSH : SYNC\_FLUSH同様、これまでにStreamに格納されたデータ圧縮を行う。異なる点はこれまでの辞書情報がリセットされるため、圧縮率が極端に低くなる可能性がある。 \end{itemize} Packetのサイズは62KBとしているが、一旦の制限として37KBまでを格納可能としている。これには理由があり、ZRLEとjava.util.zip.deflaterを使用した圧縮では、圧縮後のデータ長を予測することができない。 @@ -296,7 +296,7 @@ Code \ref{code:multicastput}: 21行目以降の処理はTileのフェーズ確認である。 -Code \ref{code:multicastput}: 22 - 27行目は行の最後のTileだった場合の条件分岐である。図\ref{fig:Packet}中のflushに該当するTileであり、そこで圧縮されたデータとループ内で再構成を行っているc1Rectの情報をPacketへ書き込みを行う。ここでFULL\_FLUSHを行う理由は、次の行に移る際圧縮用のStreamにデータを残さないためである。また、この箇所でPhase2かどうかの判断も行っている。 +Code \ref{code:multicastput}: 22 - 27行目は行の最後のTileだった場合の条件分岐である。図\ref{fig:Packet}中のflushに該当するTileであり、そこで圧縮されたデータとループ内で再構成を行っているc1Rectの情報をPacketへ書き込みを行う。ここでFULL\_FLUSHを行う理由は、次の行へ移る際に圧縮用のStreamにデータを残さないためである。また、この箇所でPhase2かどうかの判断も行っている。 Code \ref{code:multicastput}: 33、47行目ではPhase0、Phase1の確認と処理を行っている。どちらの処理も圧縮されたデータとc1Rectの情報をPacketに書き込み、次のPhaseのための初期化などを行っている。Packetへ書き込みが完了すると、子Nodeへの送信のためにPacketがMulticastQueueへ格納される。 @@ -333,7 +333,7 @@ 実装によりMulticastで実用的に画面配信が可能であると推測されるが、まだ、接続が限られるなどの問題があり解決されていない。 -現在TreeVNCはPC画面のみ配信をすることが可能であるが、音声を送信することも可能である。その場合、画面よりも音声の方がデータ量少ないため、Multicastでも送信することは可能である。 +現在TreeVNCはPC画面のみ配信をすることが可能であるが、音声を送信することも可能である。その場合、画面よりも音声の方がデータ量が少ないため、Multicastでも送信することは可能である。