# HG changeset patch # User riono # Date 1588856519 -32400 # Node ID fa856091870b8c17759128cb0522a46b4262ae50 # Parent 4f420f057fd7a8a931fba1a602586d6157df1170 fix diff -r 4f420f057fd7 -r fa856091870b Paper/riono-sigos.tex --- a/Paper/riono-sigos.tex Thu May 07 21:48:17 2020 +0900 +++ b/Paper/riono-sigos.tex Thu May 07 22:01:59 2020 +0900 @@ -96,7 +96,7 @@ Remote Frame Bufferプロトコル\cite{rfbprotocol}(以下RFB)とはVNC上で使用される、自身のPC画面をネットワーク上に送信し、他人のPC画面に表示を行うプロトコルである。画面が表示されるユーザ側をRFBクライアントと呼び、画面送信を行うためにFrameBufferの更新が行われる側をRFBサーバと呼ぶ。 -Framebufferとは、メモリ上に置かれた画像データのことである。RFBプロトコルでは、最初にプロトコルのバージョンの確認や認証が行われる。その後、RFBクライアントへ向けてFramebuffferの大きさやデスクトップに付けられた名前などが含まれている初期メッセージを送信する。 +FrameBufferとは、メモリ上に置かれた画像データのことである。RFBプロトコルでは、最初にプロトコルのバージョンの確認や認証が行われる。その後、RFBクライアントへ向けてFramebuffferの大きさやデスクトップに付けられた名前などが含まれている初期メッセージを送信する。 RFBサーバ側はFramebufferの更新が行われるたびに、RFBクライアントに対してFramebufferの変更部分を送信する。さらに、RFBクライアントからFramebuffer - UpdateRequestが来るとそれに答え返信する。変更部分のみを送信する理由は、更新があるたびに全画面を送信すると、送信するデータ面と更新にかかる時間面において効率が悪くなるからである。 @@ -161,9 +161,9 @@ \section{ShareMyScreen} 従来のVNCでは、配信者が交代するたびにVNCの再起動、サーバ・クライアント間の再接続を行う必要がある。TreeVNCでは配信者の切り替えのたびに生じる問題を解決している。 -TreeVNCを立ち上げることでケーブルを使用せずに、各参加者の手元のPCに発表者の画面を共有することができる。画面の切り替えについてはユーザがVNCサーバへの再接続を行うことなく、ビューワー側のShere My Screenボタンを押すことで配信者の切り替えが可能となっている。 +TreeVNCは立ち上げることでケーブルを使用せずに、各参加者の手元のPCに発表者の画面を共有することができる。画面の切り替えについてはユーザがVNCサーバへの再接続を行うことなく、ビューワー側のShere My Screenボタンを押すことで配信者の切り替えが可能となっている。 -TreeVNCのROot Nodeは配信者のVNCサーバと通信を行なっている。VNCサーバから画面データを受信し、そのデータを子Nodeへと送信している。配信者切り替え時にShare Screenを実行すると、Root Nodeに対しSERVER\_CHANGE\_REQUESTというメッセージが送信される。このメッセージにはShare Screenボタンを押したNodeの番号やディスプレイ情報が付与されている。メッセージを受け取ったRoot Nodeは配信を希望しているNodeのVNCサーバと通信を始める。 +TreeVNCのRoot Nodeは配信者のVNCサーバと通信を行なっている。VNCサーバから画面データを受信し、そのデータを子Nodeへと送信している。配信者切り替え時にShare Screenを実行すると、Root Nodeに対しSERVER\_CHANGE\_REQUESTというメッセージが送信される。このメッセージにはShare Screenボタンを押したNodeの番号やディスプレイ情報が付与されている。メッセージを受け取ったRoot Nodeは配信を希望しているNodeのVNCサーバと通信を始める。 \section{Multicastの利用} 現在のTreeVNCでは有線接続と無線LAN接続のどちらでも、VNCサーバから画面配信の提供を受けることが可能である。しかし無線LANの帯域は接続PC全部で共有されるために @@ -198,7 +198,7 @@ & 2 byte & & U16 - height \\ & 4 byte & & S32 - encoding-type \\ & 4 byte & & U32 datalengths \\ \hline - & & 1 byte & subencoding of tile \\ + & & 1 byte & subencoding of Tile \\ & & n byte & Run Length Encoded Tile \\ \hline \end{tabular} \label{tb:updateRectangle} @@ -229,7 +229,7 @@ \section{TileLoopの圧縮とブロッキング} TileLoopはVNCサーバから受け取ったZRLEを図\ref{fig:BlockingUpdateRectangle}のようにRectangleを分割し、ZRLEEに再構成を行ったPacketを生成する。 -通常では1画面全部を一つのUpdate Rectangleで送ることがあり、数Mbyteのパケットが生成されしまう。これを再圧縮を行いながら64kbyte以内の +通常では1画面全部を一つのUpdate Rectangleで送ることがあり、数MBのパケットが生成されしまう。これを再圧縮を行いながら64KB以内の Update Rectangleに分割する。個々のパケットは長方形の集合なので、分割されたパケットは1-3個の長方形を含むことになる。 以下の図\ref{fig:Packet}にTileLoopで生成されるPacket全体と、分割される各PhaseのRectangleを示した。