--- a/presen/prosym.md	Thu Jan 07 19:39:55 2016 +0900
+++ b/presen/prosym.md	Fri Jan 08 02:28:33 2016 +0900
@@ -6,9 +6,8 @@
 
 # 画面共有を利用したコミュニケーション
 - 授業やゼミ等で、それぞれが PC 端末を持っている場合では、PC の機能を活かした コミュニケーションが可能である
-- 教員が操作する画面をそのまま学生に配信したり, ゼミ などで、発表する学生の画面を切り替えたりすることを可能にする
 - 画面配信システム TreeVNC は参加したクライアントをバイナリツリー状に接続し、配信コストを分散させる 仕組みを取っている。そのため, 多人数が参加しても処理性能が下がらない
-- ツリー のルートが参照している VNC サーバーを変更することで、ケーブルの差し替えなしに画面 の切替が可能となる
+- ツリー のルートが参照している VNC サーバーを変更することで、ケーブルの差し替えなしに画面の切替が行える
 
 # TreeVNC の問題点
 - TreeVNC を実際に使用していく中で様々な問題が発生した。
@@ -21,7 +20,7 @@
 - ゼミ等で発表者毎に画面切り替えを行う際、デュアルディスプレイを使っている人がいた
 - その際 VNC サーバーからはすべての画面データが送信されており、発表とは関係ない画面も配信されていた
 
-<img src="./images/multidisplay.svg" alt="message" width="400">
+<img src="./images/multidisplay.svg" alt="message" width="500">
 
 # この発表は
 - TreeVNC の概要
@@ -40,7 +39,7 @@
 # TreeVNC
 -  TreeVNC は本研究室で開発している VNC を利用した画面配信システム
 - 参加したクライアントをバイナリツリー状で接続することで配信コストを分散させる
-- スムーズな画面の切替を行う
+- スムーズな配信画面の切替を行う
 
 <img src="./images/TreeVNC.svg" alt="message" width="400">
 
@@ -48,19 +47,18 @@
 - VNC(Virtual Network Computing) は RFBプロトコルを用いて遠隔操作を行うソフトウェア
 - サーバー側とクライアント側に分かれており、サーバーを起動し、クライアントがサーバーに接続を行うことで遠隔操作を可能とする
 
-<img src="./images/vnc.svg" alt="message" width="400">
+<img src="./images/vnc.svg" alt="message" width="600">
 
 # RFB プロトコル
 - RFB(Remote Frame Buffer)プロトコルは VNC で用いられているプロトコル
 - 自身の画面をネットワーク越しに他者の画面に表示する
-- RFB サーバと RFB クライアントに分かれている
 - Framebuffer と呼ばれるメモリ上に置かれた画像データを使用して画面表示を行う
-- RFB サーバーは Framebuffer が更新されるたびにRFB クライアントに対して Framebuffer の変更部分だけを送信する。
+- サーバーは Framebuffer が更新されるたびにクライアントに対して変更部分だけを送信する。
 
 # 多人数でVNCを使用する際の問題点
-- 多人数のクライアントが1つのサーバーに接続する構造である
-- そのため、サーバー側の処理性能が落ちてしまう
-- ゼミ等の発表で画面配信者が切り替わる場合配信者が変わるたびにアプリケーションを終了し、再接続を行う必要がある。
+- 多人数のクライアントが1つのサーバーに接続する構造
+- サーバー側の処理性能が落ちてしまう
+- 配信者を切り替える際、配信側のサーバーを立ち上げ直す必要がある
 
 # TreeVNC の構造
 - Java で作成されたTightVNC(Tight Virtual Network Computing) を元に作成されている
@@ -80,7 +78,7 @@
 - 従来のVNCはNode数に比例
 - TreeVNCはNode数に関係なく一定
 
-<img src="./images/comparenormalandtree.svg" alt="message" width="400">
+<img src="./images/comparenormalandtree.svg" alt="message" width="600">
 
 # TreeVNC の圧縮形式
 - TreeVNC は  ZRLEE というエンコードでデータのやり取りを行う
@@ -91,7 +89,7 @@
 <img src="./images/ZRLEE.svg" alt="message" width="400">
 
 # TreeVNC に参加するまでのメッセージ通信の流れ
-<img src="./images/message.svg" alt="message" class="center" width="400"/>
+<img src="./images/message.svg" alt="message"  width="400"/>
 
 # 切断時の木の再構成
 - TreeVNC はバイナリーツリーという特性上 Node の切断を検知できずにいると、Node 同士で構成された木構造が崩れてしまう
@@ -104,7 +102,7 @@
 - 画面を配信されている側のビューワにある Share Screen ボタンが押す 
 - Root Node に SERVER\_CHANGE\_REQUEST メッセージを送信する
 - Root Node は Share Screen ボタンを押したクライアントの VNC サーバーと通信を始める。
-- NAT を越えは現時点では実装されていない
+- NAT 越えは現時点では実装されていない
 
 # QUALITY モードと SPEED モード
 - 高解像度のデータの描画処理はPCのスペックによって重くなる場合がある
@@ -126,10 +124,10 @@
 - Root Node が接続しているネットワークごとに木構造を形成する
 - 新しい Node が接続してきた際、 interfaces から Node のネットワークと一致する木構造を取得し、 接続の処理を任せる
 
-<img src="./images/MultiNetworkTree.svg" alt="message" width="800">
+<img src="./images/MultiNetworkTree.svg" alt="message" width="600">
 
 # Direct Connection
-- NATを越えたネットワークからの接続は直接配信側の Root Node に 接続を行うことで実現する
+- NATを越えたネットワークからの接続は直接配信側の Root Node に接続を行うことで実現する
 - Direct Connection した Node はそのネットワークの Root Node になり、そのネットワークの他の Node は Root Node に接続を行い木構造を作る
 
 <img src="./images/directConnection.svg" alt="message" width="800">
@@ -151,15 +149,16 @@
 ```
 
 # 深さ1, 2
-<img src="./images/depth1.svg" alt="message" width="800">
-<img src="./images/depth2.svg" alt="message" width="800">
+<img src="./images/depth1.svg" alt="message" width="450">
+<img src="./images/depth2.svg" alt="message" width="450">
 
 # 深さ3, 4
-<img src="./images/depth3.svg" alt="message" width="800">
-<img src="./images/depth4.svg" alt="message" width="800">
+<img src="./images/depth3.svg" alt="message" width="450">
+<img src="./images/depth4.svg" alt="message" width="450">
 
 # 結果から
-- 画像データの伝達はほぼ1秒以内に収まっているが、容量が小さい場合でも時間がかかる場合がある。 それはその送信の前に大容量の画像を送信した後の回線の Delay が残っているためだと考えられる
+- 画像データの伝達はほぼ1秒以内に収まっている
+- 容量が小さい場合でも時間がかかる場合がある。 それはその送信の前に大容量の画像を送信した後の回線の Delay が残っているためだと考えられる
 - 深さ 3 で極端に遅い場合がある。 遅い原因として1つの Node がボトルネックになっている事が判明した。
 - ネックになった Node をそのままにするとその子Nodeに影響を及ぼしてしまう。 そのためその Node に何らかの対応を行う必要がある