|
0
|
1 \chapter{TreeVNC の基本概念}
|
|
|
2 %% VNCとはなにか？どのようなものか？どのようにしてなりたっているか？
|
|
|
3
|
|
|
4 TreeVNC は当研究室で開発している画面配信ソフトウェアである。
|
|
|
5
|
|
|
6 本章は TreeVNC の基本概念となっている技術について説明する。
|
|
|
7
|
|
|
8 %% どういう概念？ どうしてそうするの？ どうやってつかうの？
|
|
|
9 \section{ Virtual Network Computing }
|
|
|
10
|
|
|
11 VNC(Virtual Network Computing) は、RFB プロトコルを用いて PC の遠隔操作を行うことを目的としたリモートデスクトップソフトウェアである。
|
|
|
12
|
|
|
13 サーバー側とクライアント側に分かれており、起動したサーバーにクライアントが接続することで遠隔操作を可能にしている。
|
|
|
14
|
|
|
15
|
|
|
16 \section{ RFB プロトコル}
|
|
|
17
|
|
|
18 RFB(Remote Frame Buffer)プロトコルは、自身の画面をネットワークを通じて送信し他者の画面に表示するプロトコルである。
|
|
|
19
|
|
|
20 ユーザがいる側と FrameBuffer への更新が行われる側に分かれ、それぞれを RFB クライアント、RFB サーバと呼ぶ。FrameBuffer は、メモリ上に置かれた画像データのことである。
|
|
|
21
|
|
|
22 RFB プロトコルでは、始めにプロトコルバージョンの確認、認証を行う。その後クライアントに向けて FrameBuffer の大きさやデスクトップに付けられた名前などが含まれている初期メッセージが送信される。RFB サーバ側は FrameBuffer の更新が行われるたびに RFB クライアントに対して FrameBuffer の変更部分だけを送信する。更に、RFB クライアントの FramebufferUpdateRequest が来るとそれに答え返信する。変更部分だけを送信する理由は、更新がある度に全画面を送信していると、送信するデータ面、更新にかかる時間面において効率が悪いからである。
|
|
|
23
|
|
|
24 RFB プロトコルには、描画データに使われるエンコードが多数用意されており、更に、独自のエンコードを実装することも可能である。
|
|
|
25
|
|
|
26
|
|
|
27 %%ここより上を修正したい
|
|
|
28 \section{ TreeVNC の基本構造}
|
|
|
29 TreeVNC は TightVNC を元に作成されている
|
|
|
30
|
|
|
31
|
|
|
32 \section{従来の VNC と TreeVNC の相違点}
|
|
|
33
|
|
|
34 従来の VNC は画面配信を行う際、サーバー側に全てのクライアントが同時に接続してしまうため、多人数に配信を行う場合、クライアントに対する全ての処理をサーバー1つで負担することになり、サーバーの処理性能が落ちてしまう問題点が存在する。
|
|
|
35
|
|
|
36
|
|
|
37 %%従来の VNC の接続方式の図
|
|
|
38 %%従来の VNC 使用時のパフォーマンスの計測結果
|
|
|
39
|
|
|
40
|
|
|
41 \section{}
|
|
|
42 CbC で DataGear を扱う際、 Context と呼ばれる接続可能な CodeGear、 DataGear のリ
|
|
|
43 スト、Temporal DataGear のためのメモリ空間等を持っている Meta DataGearである。
|
|
|
44 CbC で必要な CodeGear 、 DataGear を参照する際は Context を通してアクセスする必
|
|
|
45 要がある。
|
|
|
46
|
|
|
47 \section{stub CodeGear}
|
|
|
48 CodeGear が必要とする DataGear を取り出す際、 Context を通す必要がある。
|
|
|
49 しかし、 Context を直接扱えるようにするのは信頼性を損なう。そのため CbC では
|
|
|
50 Context を通して必要なデータを取り出して次の Code Gear に接続する stub CodeGear
|
|
|
51 を定義している。CodeGear は stub CodeGear を介してのみ必要な DataGear へアクセス
|
|
|
52 することができる。 stub CodeGear は CodeGear 毎に生成され、次の CodeGear へと接
|
|
|
53 続される。
|
|
|
54 stub CodeGear は CodeGear の Meta CodeGear に当たる。
|
|
|
55
|
|
|
56
|
|
|
57 \section{CbCによる Interface の記述と継続}
|
|
|
58
|
|
|
59 CodeGear は通常の関数と比べ、細かく分割されるためメタ計算をより柔軟に記述でき
|
|
|
60 る。 CodeGear 、 DataGear にはそれぞれメタレベルとして、 Meta CodeGear
|
|
|
61 、 Meta DataGear が存在する。
|
|
|
62
|
|
|
63 CbC で実装していくうちに、stub CodeGear の記述が煩雑になることが分かった。
|
|
|
64 そのため 既存の実装を モジュールとして扱うため Interface という仕組みを導入した。
|
|
|
65
|
|
|
66 Interface は DataGear に対して何らかの操作(API)を行う CodeGear とその
|
|
|
67 CodeGear で使われる DataGear の集合を抽象化した メタレベルの DataGear
|
|
|
68 として定義されている。
|
|
|
69
|
|
|
70 % interface は データ構造に record で interface 名を列挙し、実際の動作をする関数と紐付けている。使用する際は、$ DataName->InterfaceFunk $のように使用する。
|
|
|
71
|
|
|
72 例として CbC による Stack Interface のソースコード\ref{src:interface-define},
|
|
|
73 \ref{src:interface}がある。Stack への push 操作に注目して見ると、
|
|
|
74 実態は SingleLinkedStack の push であることが\ref{src:interface}で分
|
|
|
75 かる。実際の SingleLinkedStack の push では Stack を指定する必要があるが、
|
|
|
76 Interface で実装した Stack では push 先の Stack が stackImpl として扱
|
|
|
77 われている。この stackImpl は$ Stack->push $で呼ばれた時の Stack と同じになる。
|
|
|
78 これにより、 ユーザーは実行時に Stack を指定する必要がなくなる。
|
|
|
79 また、ユーザーが誤って異なる Stack を指定することを防ぐこともできる。
|
|
|
80
|
|
|
81 このように Interface 記述をすることで CbC で通常記述する必要がある一定の部分を省略し呼び出
|
|
|
82 しが容易になる。
|
|
|
83
|
|
|
84 \lstinputlisting[label=src:interface-define, caption=CbCでのStack-Interfaceの定義] {src/interface.cbc}
|
|
|
85
|
|
|
86 \lstinputlisting[label=src:interface, caption=CbCでのStack-Interfaceの実装] {src/singleLinkedStackInterface.cbc}
|
|
|
87
|
