# HG changeset patch # User oshiro # Date 1550303785 -32400 # Node ID 8b42a96b95aa5b271e2c470566ca5bbd53ef32de # Parent 80d5d1e0428c38c6cd24c483a38c8b84beaaf2b4 change chapter2 diff -r 80d5d1e0428c -r 8b42a96b95aa final_main/chapter1.tex --- a/final_main/chapter1.tex Thu Feb 14 16:57:18 2019 +0900 +++ b/final_main/chapter1.tex Sat Feb 16 16:56:25 2019 +0900 @@ -1,4 +1,4 @@ -\chapter{画面配信ソフトウェアの活用} +\chapter{画面配信ソフトウェア TreeVNC の活用} \label{chap:introduction} \pagenumbering{arabic} diff -r 80d5d1e0428c -r 8b42a96b95aa final_main/chapter2.tex --- a/final_main/chapter2.tex Thu Feb 14 16:57:18 2019 +0900 +++ b/final_main/chapter2.tex Sat Feb 16 16:56:25 2019 +0900 @@ -1,87 +1,50 @@ \chapter{TreeVNC の基本概念} -%% VNCとはなにか？どのようなものか？どのようにしてなりたっているか？ +% VNCとはなにか？どのようなものか？どのようにしてなりたっているか？ 　TreeVNC は当研究室で開発している画面配信ソフトウェアである。 本章は TreeVNC の基本概念となっている技術について説明する。 -%% どういう概念？ どうしてそうするの？ どうやってつかうの？ -\section{ Virtual Network Computing } +% どういう概念？ どうしてそうするの？ どうやってつかうの？ +\section{Virtual Network Computing} -VNC(Virtual Network Computing) は、RFB プロトコルを用いて PC の遠隔操作を行うことを目的としたリモートデスクトップソフトウェアである。 +TreeVNC の名前にも用いられている VNC (Virtual Network Computing) は、RFB プロトコルを用いて PC の遠隔操作を行うことを目的としたリモートデスクトップソフトウェアである。 サーバー側とクライアント側に分かれており、起動したサーバーにクライアントが接続することで遠隔操作を可能にしている。 -\section{ RFB プロトコル} +\section{RFB プロトコル} -RFB(Remote Frame Buffer)プロトコルは、自身の画面をネットワークを通じて送信し他者の画面に表示するプロトコルである。 +RFB (Remote Frame Buffer) プロトコルは、自身の画面をネットワークを通じて送信し他者の画面に表示するプロトコルである。 -ユーザがいる側と FrameBuffer への更新が行われる側に分かれ、それぞれを RFB クライアント、RFB サーバと呼ぶ。FrameBuffer は、メモリ上に置かれた画像データのことである。 +ユーザがいる(画面を表示される)側と FrameBuffer への更新が行われる(自身の画面を送信する)側に分かれ、それぞれを RFB クライアント、RFB サーバと呼ぶ。FrameBuffer は、メモリ上に置かれた画像データのことである。 RFB プロトコルでは、始めにプロトコルバージョンの確認、認証を行う。その後クライアントに向けて FrameBuffer の大きさやデスクトップに付けられた名前などが含まれている初期メッセージが送信される。RFB サーバ側は FrameBuffer の更新が行われるたびに RFB クライアントに対して FrameBuffer の変更部分だけを送信する。更に、RFB クライアントの FramebufferUpdateRequest が来るとそれに答え返信する。変更部分だけを送信する理由は、更新がある度に全画面を送信していると、送信するデータ面、更新にかかる時間面において効率が悪いからである。 -RFB プロトコルには、描画データに使われるエンコードが多数用意されており、更に、独自のエンコードを実装することも可能である。 - -%%ここより上を修正したい -\section{ TreeVNC の基本構造} -TreeVNC は TightVNC を元に作成されている - +\section{TreeStructure} +TreeVNC はサーバーに接続してきたクライアントをバイナリツリー状に接続している。また、接続してきたクライアントをノードとし、その下に新たなクライアントを接続していくことでサーバーが画面のデータを配信する回数を抑えることで負荷分散している(図)。バイナリツリー状に接続することで、画像データのコピーを各ノードに負担させることができ、従来の VNC ではクライアントが N 台接続するとサーバー側が N 回コピーを行なって配信していたが、この接続方法であれば各ノードが 2 回ずつコピーすることで配信を可能にしている。 -\section{従来の VNC と TreeVNC の相違点} - -従来の VNC は画面配信を行う際、サーバー側に全てのクライアントが同時に接続してしまうため、多人数に配信を行う場合、クライアントに対する全ての処理をサーバー1つで負担することになり、サーバーの処理性能が落ちてしまう問題点が存在する。 +\begin{figure}[htpb] + \begin{center} + \scalebox{0.55}{\includegraphics{fig/vnc.pdf}} + \end{center} + \caption{従来の VNC の接続方法} + \label{fig:vnc} +\end{figure} - -%%従来の VNC の接続方式の図 -%%従来の VNC 使用時のパフォーマンスの計測結果 +\begin{figure}[htpb] + \begin{center} + \scalebox{0.55}{\includegraphics{fig/treevnc.pdf}} + \end{center} + \caption{TreeVNC の接続方法} + \label{fig:treevnc} +\end{figure} -\section{} -CbC で DataGear を扱う際、 Context と呼ばれる接続可能な CodeGear、 DataGear のリ -スト、Temporal DataGear のためのメモリ空間等を持っている Meta DataGearである。 -CbC で必要な CodeGear 、 DataGear を参照する際は Context を通してアクセスする必 -要がある。 - -\section{stub CodeGear} -CodeGear が必要とする DataGear を取り出す際、 Context を通す必要がある。 -しかし、 Context を直接扱えるようにするのは信頼性を損なう。そのため CbC では -Context を通して必要なデータを取り出して次の Code Gear に接続する stub CodeGear -を定義している。CodeGear は stub CodeGear を介してのみ必要な DataGear へアクセス -することができる。 stub CodeGear は CodeGear 毎に生成され、次の CodeGear へと接 -続される。 -stub CodeGear は CodeGear の Meta CodeGear に当たる。 - - -\section{CbCによる Interface の記述と継続} - -CodeGear は通常の関数と比べ、細かく分割されるためメタ計算をより柔軟に記述でき -る。 CodeGear 、 DataGear にはそれぞれメタレベルとして、 Meta CodeGear -、 Meta DataGear が存在する。 +\section{画面配信の切り替え} +従来の VNC では、配信者が切り替わるたびに VNC の再起動、サーバー、クライアント間の再接続を行う必要がある。TreeVNC では、画面上にある ShareScreen ボタンを押すことで配信者の切り替えを実行できるように設定し、この問題に対処している。 -CbC で実装していくうちに、stub CodeGear の記述が煩雑になることが分かった。 -そのため 既存の実装を モジュールとして扱うため Interface という仕組みを導入した。 - -Interface は DataGear に対して何らかの操作(API)を行う CodeGear とその -CodeGear で使われる DataGear の集合を抽象化した メタレベルの DataGear -として定義されている。 - -% interface は データ構造に record で interface 名を列挙し、実際の動作をする関数と紐付けている。使用する際は、$ DataName->InterfaceFunk $のように使用する。 +ShareScreen 実行後、 Root Node に対し SERVER_CHANGE_REQUEST というメッセージが送信される。このメッセージには ShereScreen ボタンを押した Node の番号やディスプレイの情報が付加されている。メッセージを受け取った Root Node は配信を希望している Node の VNC サーバーと通信を行い、切り替え作業に入る。 -例として CbC による Stack Interface のソースコード\ref{src:interface-define}, -\ref{src:interface}がある。Stack への push 操作に注目して見ると、 -実態は SingleLinkedStack の push であることが\ref{src:interface}で分 -かる。実際の SingleLinkedStack の push では Stack を指定する必要があるが、 -Interface で実装した Stack では push 先の Stack が stackImpl として扱 -われている。この stackImpl は$ Stack->push $で呼ばれた時の Stack と同じになる。 -これにより、 ユーザーは実行時に Stack を指定する必要がなくなる。 -また、ユーザーが誤って異なる Stack を指定することを防ぐこともできる。 - -このように Interface 記述をすることで CbC で通常記述する必要がある一定の部分を省略し呼び出 -しが容易になる。 - -\lstinputlisting[label=src:interface-define, caption=CbCでのStack-Interfaceの定義] {src/interface.cbc} - -\lstinputlisting[label=src:interface, caption=CbCでのStack-Interfaceの実装] {src/singleLinkedStackInterface.cbc} - +%切り替え実行時の図 \ No newline at end of file diff -r 80d5d1e0428c -r 8b42a96b95aa final_main/main.pdf Binary file final_main/main.pdf has changed