Mercurial > hg > Papers > 2015 > parusu-prosym

changeset 33:c20b2d98c5f4

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Update
author Tatsuki IHA <e125716@ie.u-ryukyu.ac.jp>
date Fri, 08 Jan 2016 03:17:25 +0900
parents 0b99de43a192
children 1ef0837924a3
files presen/prosym.html presen/prosym.md
diffstat 2 files changed, 60 insertions(+), 44 deletions(-) [+]
line wrap: on
line diff
--- a/presen/prosym.html	Fri Jan 08 02:28:33 2016 +0900
+++ b/presen/prosym.html	Fri Jan 08 03:17:25 2016 +0900
@@ -87,7 +87,7 @@
 <!-- === begin markdown block ===
 
       generated by markdown/1.2.0 on Ruby 2.3.0 (2015-12-25) [x86_64-darwin15]
-                on 2016-01-08 02:25:23 +0900 with Markdown engine kramdown (1.9.0)
+                on 2016-01-08 03:14:48 +0900 with Markdown engine kramdown (1.9.0)
                   using options {}
   -->
 
@@ -208,21 +208,29 @@
 <h2 id="treevnc--2">TreeVNC の構造</h2>
 <ul>
   <li>Java で作成されたTightVNC(Tight Virtual Network Computing) を元に作成されている</li>
+  <li>様々なメッセージで通信を行う</li>
   <li>クライアント同士をバイナリツリー状に接続する</li>
   <li>バイナリツリーのルートのノードをRoot Nodeと呼び、 Root Node に接続されるノードを Node と呼ぶ</li>
-  <li>Node は 親 Node から送られたデータを自分の子 Node に流す機能、 逆に子 Node から送られてきたデータを親 Nodeに流す機能がある</li>
 </ul>
 
 
 </div>
 <div class='slide '>
 <!-- _S9SLIDE_ -->
-<h2 id="root-node">Root Node</h2>
+<h2 id="node-">Node が行う処理</h2>
 <ul>
-  <li>Root Node は 子 Nodeにデータを流す機能に加え
+  <li>Node
     <ul>
+      <li>親 Node から送られたデータを自分の子 Node に流す</li>
+      <li>子 Node から送られてきたデータを親 Nodeに流す</li>
+    </ul>
+  </li>
+  <li>Root Node
+    <ul>
+      <li>TreeVNC で配信を行う際に一番最初に起動する Node</li>
+      <li>Node の機能</li>
       <li>各 Node の管理</li>
-      <li>VNC サーバーから送信されたFramebuffer の管理を行う</li>
+      <li>VNC サーバーから送信されたFramebuffer の管理</li>
     </ul>
   </li>
 </ul>
@@ -253,8 +261,9 @@
 <ul>
   <li>TreeVNC は  ZRLEE というエンコードでデータのやり取りを行う</li>
   <li>ZRLEE は Rfb でのエンコードの1つである ZRLE を元に生成される</li>
-  <li>ZRLEE はZRLE を一度 Root Node で解凍して再圧縮を行う</li>
-  <li>その際配信画面の更新のたびに辞書を作りなおす</li>
+  <li>ZRLE を一度 Root Node で解凍して再圧縮を行う</li>
+  <li>配信画面の更新のたびに辞書を作りなおす</li>
+  <li>途中からデータを受け取っても解凍できる</li>
 </ul>
 
 <p><img src="./images/ZRLEE.svg" alt="message" width="400" /></p>
@@ -263,17 +272,17 @@
 </div>
 <div class='slide '>
 <!-- _S9SLIDE_ -->
-<h2 id="treevnc--4">TreeVNC に参加するまでのメッセージ通信の流れ</h2>
+<h2 id="section-2">メッセージ通信の流れ</h2>
 <p><img src="./images/message.svg" alt="message" width="400" /></p>
 
 
 </div>
 <div class='slide '>
 <!-- _S9SLIDE_ -->
-<h2 id="section-2">切断時の木の再構成</h2>
+<h2 id="section-3">切断時の木の再構成</h2>
 <ul>
   <li>TreeVNC はバイナリーツリーという特性上 Node の切断を検知できずにいると、Node 同士で構成された木構造が崩れてしまう</li>
-  <li>TreeVNC は Node 切断の検知を LOST_CHILD というメッセージ通信で行っている</li>
+  <li>TreeVNC は Node 切断の検知を LOST_CHILD というメッセージで行っている</li>
 </ul>
 
 <p><img src="./images/lostChild1.svg" alt="message" width="800" /></p>
@@ -282,11 +291,11 @@
 </div>
 <div class='slide '>
 <!-- _S9SLIDE_ -->
-<h2 id="section-3">共有画面切り替え</h2>
+<h2 id="section-4">共有画面切り替え</h2>
 <ul>
   <li>TreeVNC の Root Node は配信者の VNC サーバーと通信を行っている</li>
   <li>画面を配信されている側のビューワにある Share Screen ボタンが押す</li>
-  <li>Root Node に SERVER_CHANGE_REQUEST メッセージを送信する</li>
+  <li>Root Node に SERVER_CHANGE_REQUEST を送信する</li>
   <li>Root Node は Share Screen ボタンを押したクライアントの VNC サーバーと通信を始める。</li>
   <li>NAT 越えは現時点では実装されていない</li>
 </ul>
@@ -305,19 +314,18 @@
     </ul>
   </li>
   <li>今まで QUALITY モード を使用していた(変更不可)</li>
-  <li>今回ビューワからユーザーがどちらのモードを使用するかを変更できるようにした</li>
-  <li>これにより描画処理の遅延が解決できると思われる</li>
+  <li>ビューワからユーザーがどちらのモードを使用するかを変更を可能にした</li>
 </ul>
 
 
 </div>
 <div class='slide '>
 <!-- _S9SLIDE_ -->
-<h2 id="section-4">マルチディスプレイ</h2>
+<h2 id="section-5">マルチディスプレイ</h2>
 <ul>
   <li>画面切り替えの際のSERVER_CHANGE_REQUESTに共有するディスプレイの座標を付加する</li>
-  <li>Root Node は 接続した VNC サーバーから画像データを要求する FRAME_BUFFER_UPDATE_REQUEST メッセージに受け取った座標を付加する</li>
-  <li>VNC サーバーは要求された座標内の画像データを FRAME_BUFFER_UPDATE メッセージで Root Node に送信する</li>
+  <li>Root Node は 接続した VNC サーバーから画像データを要求する FRAME_BUFFER_UPDATE_REQUEST に受け取った座標を付加する</li>
+  <li>VNC サーバーは要求された座標内の画像データを FRAME_BUFFER_UPDATE で Root Node に送信する</li>
 </ul>
 
 <p><img src="./images/shareScreenToMultiDisplay.svg" alt="message" width="800" /></p>
@@ -326,7 +334,7 @@
 </div>
 <div class='slide '>
 <!-- _S9SLIDE_ -->
-<h2 id="section-5">複数ネットワークの対応</h2>
+<h2 id="section-6">複数ネットワークの対応</h2>
 <ul>
   <li>Root Node が接続しているネットワークごとに木構造を形成する</li>
   <li>新しい Node が接続してきた際、 interfaces から Node のネットワークと一致する木構造を取得し、 接続の処理を任せる</li>
@@ -342,6 +350,7 @@
 <ul>
   <li>NATを越えたネットワークからの接続は直接配信側の Root Node に接続を行うことで実現する</li>
   <li>Direct Connection した Node はそのネットワークの Root Node になり、そのネットワークの他の Node は Root Node に接続を行い木構造を作る</li>
+  <li>Direct Connection された Root Node では NAT を越えたネットワークの Root Node の管理を行わない</li>
 </ul>
 
 <p><img src="./images/directConnection.svg" alt="message" width="800" /></p>
@@ -365,10 +374,10 @@
 </div>
 <div class='slide '>
 <!-- _S9SLIDE_ -->
-<h2 id="section-6">実測方法</h2>
+<h2 id="section-7">実測方法</h2>
 <ul>
-  <li>Root Node は 送信時間と画像データを持った CHECK_DELAY を 末端 Node まで各 Node を伝いながら伝達する</li>
-  <li>CHECK_DELAY を受け取った各 Node は CHECK_DELAY_REPLY を送信する</li>
+  <li>Root Node は 送信時間と画像データを持った CHECK_DELAY を 末端 Node まで木構造を辿りながら伝達する</li>
+  <li>CHECK_DELAY を受け取った各 Node は 付加された送信時間を CHECK_DELAY_REPLY に付加し、 Root Node に送信する</li>
   <li>CHECK_DELAY_REPLY を受け取った Root Node は CHECK_DELAY の送信にどれだけ時間がかかったかの計算を行う</li>
 </ul>
 
@@ -380,7 +389,7 @@
 </div>
 <div class='slide '>
 <!-- _S9SLIDE_ -->
-<h2 id="section-7">深さ1, 2</h2>
+<h2 id="section-8">深さ1, 2</h2>
 <p><img src="./images/depth1.svg" alt="message" width="450" />
 <img src="./images/depth2.svg" alt="message" width="450" /></p>
 
@@ -388,7 +397,7 @@
 </div>
 <div class='slide '>
 <!-- _S9SLIDE_ -->
-<h2 id="section-8">深さ3, 4</h2>
+<h2 id="section-9">深さ3, 4</h2>
 <p><img src="./images/depth3.svg" alt="message" width="450" />
 <img src="./images/depth4.svg" alt="message" width="450" /></p>
 
@@ -396,11 +405,11 @@
 </div>
 <div class='slide '>
 <!-- _S9SLIDE_ -->
-<h2 id="section-9">結果から</h2>
+<h2 id="section-10">結果から</h2>
 <ul>
   <li>画像データの伝達はほぼ1秒以内に収まっている</li>
-  <li>容量が小さい場合でも時間がかかる場合がある。 それはその送信の前に大容量の画像を送信した後の回線の Delay が残っているためだと考えられる</li>
-  <li>深さ 3 で極端に遅い場合がある。 遅い原因として1つの Node がボトルネックになっている事が判明した。</li>
+  <li>容量が小さい場合でも時間がかかる場合がある。 それはその送信の前に大容量の画像を送信した後の回線の遅延が残っているためだと考えられる</li>
+  <li>深さ3が遅い原因として1つの Node がボトルネックになっている事が判明した。</li>
   <li>ネックになった Node をそのままにするとその子Nodeに影響を及ぼしてしまう。 そのためその Node に何らかの対応を行う必要がある</li>
 </ul>
 
@@ -408,7 +417,7 @@
 </div>
 <div class='slide '>
 <!-- _S9SLIDE_ -->
-<h2 id="section-10">まとめと課題</h2>
+<h2 id="section-11">まとめと課題</h2>
 <ul>
   <li>今回TreeVNCの様々な問題点の解決を行った</li>
   <li>実験を行うことによりさらなる問題点が判明した</li>
--- a/presen/prosym.md	Fri Jan 08 02:28:33 2016 +0900
+++ b/presen/prosym.md	Fri Jan 08 03:17:25 2016 +0900
@@ -62,14 +62,20 @@
 
 # TreeVNC の構造
 - Java で作成されたTightVNC(Tight Virtual Network Computing) を元に作成されている
+- 様々なメッセージで通信を行う
 - クライアント同士をバイナリツリー状に接続する
 - バイナリツリーのルートのノードをRoot Nodeと呼び、 Root Node に接続されるノードを Node と呼ぶ
-- Node は 親 Node から送られたデータを自分の子 Node に流す機能、 逆に子 Node から送られてきたデータを親 Nodeに流す機能がある
 
-# Root Node
-- Root Node は 子 Nodeにデータを流す機能に加え 
+# Node が行う処理
+- Node
+    - 親 Node から送られたデータを自分の子 Node に流す
+    - 子 Node から送られてきたデータを親 Nodeに流す
+- Root Node
+    - TreeVNC で配信を行う際に一番最初に起動する Node
+    - Node の機能
     - 各 Node の管理
-    - VNC サーバーから送信されたFramebuffer の管理を行う
+    - VNC サーバーから送信されたFramebuffer の管理
+
 
 # TreeVNCの負荷分散
 - ポート一本あたりの負荷
@@ -83,24 +89,25 @@
 # TreeVNC の圧縮形式
 - TreeVNC は  ZRLEE というエンコードでデータのやり取りを行う
 - ZRLEE は Rfb でのエンコードの1つである ZRLE を元に生成される
-- ZRLEE はZRLE を一度 Root Node で解凍して再圧縮を行う
-- その際配信画面の更新のたびに辞書を作りなおす
+- ZRLE を一度 Root Node で解凍して再圧縮を行う
+- 配信画面の更新のたびに辞書を作りなおす
+- 途中からデータを受け取っても解凍できる
 
 <img src="./images/ZRLEE.svg" alt="message" width="400">
 
-# TreeVNC に参加するまでのメッセージ通信の流れ
+# メッセージ通信の流れ
 <img src="./images/message.svg" alt="message"  width="400"/>
 
 # 切断時の木の再構成
 - TreeVNC はバイナリーツリーという特性上 Node の切断を検知できずにいると、Node 同士で構成された木構造が崩れてしまう
-- TreeVNC は Node 切断の検知を LOST\_CHILD というメッセージ通信で行っている
+- TreeVNC は Node 切断の検知を LOST\_CHILD というメッセージで行っている
 
 <img src="./images/lostChild1.svg" alt="message" width="800">
 
 # 共有画面切り替え
 - TreeVNC の Root Node は配信者の VNC サーバーと通信を行っている
 - 画面を配信されている側のビューワにある Share Screen ボタンが押す 
-- Root Node に SERVER\_CHANGE\_REQUEST メッセージを送信する
+- Root Node に SERVER\_CHANGE\_REQUEST を送信する
 - Root Node は Share Screen ボタンを押したクライアントの VNC サーバーと通信を始める。
 - NAT 越えは現時点では実装されていない
 
@@ -110,13 +117,12 @@
     - 高画質優先の QUALITY モード
     - 描画速度優先の SPEED モード
 - 今まで QUALITY モード を使用していた(変更不可)
-- 今回ビューワからユーザーがどちらのモードを使用するかを変更できるようにした
-- これにより描画処理の遅延が解決できると思われる
+- ビューワからユーザーがどちらのモードを使用するかを変更を可能にした
 
 # マルチディスプレイ
 - 画面切り替えの際のSERVER\_CHANGE\_REQUESTに共有するディスプレイの座標を付加する
-- Root Node は 接続した VNC サーバーから画像データを要求する FRAME\_BUFFER\_UPDATE\_REQUEST メッセージに受け取った座標を付加する
-- VNC サーバーは要求された座標内の画像データを FRAME\_BUFFER\_UPDATE メッセージで Root Node に送信する
+- Root Node は 接続した VNC サーバーから画像データを要求する FRAME\_BUFFER\_UPDATE\_REQUEST に受け取った座標を付加する
+- VNC サーバーは要求された座標内の画像データを FRAME\_BUFFER\_UPDATE で Root Node に送信する
 
 <img src="./images/shareScreenToMultiDisplay.svg" alt="message" width="800">
 
@@ -129,6 +135,7 @@
 # Direct Connection
 - NATを越えたネットワークからの接続は直接配信側の Root Node に接続を行うことで実現する
 - Direct Connection した Node はそのネットワークの Root Node になり、そのネットワークの他の Node は Root Node に接続を行い木構造を作る
+- Direct Connection された Root Node では NAT を越えたネットワークの Root Node の管理を行わない
 
 <img src="./images/directConnection.svg" alt="message" width="800">
 
@@ -139,8 +146,8 @@
     - 約20名の接続
 
 # 実測方法
-- Root Node は 送信時間と画像データを持った CHECK\_DELAY を 末端 Node まで各 Node を伝いながら伝達する
-- CHECK\_DELAY を受け取った各 Node は CHECK\_DELAY\_REPLY を送信する
+- Root Node は 送信時間と画像データを持った CHECK\_DELAY を 末端 Node まで木構造を辿りながら伝達する
+- CHECK\_DELAY を受け取った各 Node は 付加された送信時間を CHECK\_DELAY\_REPLY に付加し、 Root Node に送信する
 - CHECK\_DELAY\_REPLY を受け取った Root Node は CHECK\_DELAY の送信にどれだけ時間がかかったかの計算を行う
 
 ```java
@@ -158,8 +165,8 @@
 
 # 結果から
 - 画像データの伝達はほぼ1秒以内に収まっている
-- 容量が小さい場合でも時間がかかる場合がある。 それはその送信の前に大容量の画像を送信した後の回線の Delay が残っているためだと考えられる
-- 深さ 3 で極端に遅い場合がある。 遅い原因として1つの Node がボトルネックになっている事が判明した。
+- 容量が小さい場合でも時間がかかる場合がある。 それはその送信の前に大容量の画像を送信した後の回線の遅延が残っているためだと考えられる
+- 深さ3が遅い原因として1つの Node がボトルネックになっている事が判明した。
 - ネックになった Node をそのままにするとその子Nodeに影響を及ぼしてしまう。 そのためその Node に何らかの対応を行う必要がある
 
 # まとめと課題