# HG changeset patch
# User e165729 <e165729@ie.u-ryukyu.ac.jp>
# Date 1559136554 -32400
# Node ID 2709c4da4ba981fcf7a3a67ff44a2ab470280fa9
# Parent  444d5f272a9214971a1f1eff22dd5647cf8fa457
update slide ~10p

diff -r 444d5f272a92 -r 2709c4da4ba9 Slide/slide.html
--- a/Slide/slide.html	Wed May 29 21:23:52 2019 +0900
+++ b/Slide/slide.html	Wed May 29 22:29:14 2019 +0900
@@ -184,6 +184,8 @@
   <li>本研究ではMulticastを導入することで、Wifi環境下における画面配信の遅延対策の検討を行なった</li>
 </ul>
 
+<p>(途中に無線接続,全体delay図)</p>
+
 
 
 </div>
@@ -206,9 +208,27 @@
   <!-- _S9SLIDE_ -->
 <h2 id="multicastによる画面配信">Multicastによる画面配信</h2>
 <ul>
-  <li>配信PC画面の変更があった部分のみをマルチキャストで一度のみ送信する</li>
+  <li>配信PC画面の変更があった部分のみをUpdateRectangleとしてマルチキャストで一度のみ送信する</li>
+  <li>RFBプロトコルでは画像データをRectangleで送信しているため、UpdateRectangleには複数のRectangleが入るような構成をとる</li>
+</ul>
+
+<center><img src="./fig/UpdateRectangleStruct.svg" alt="message" width="450" height="350" /></center>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h2 id="multicastの問題点">Multicastの問題点</h2>
+<ul>
   <li>wifiのMulticast Paketの最大サイズは64KBである</li>
-  <li>4Kの画面を更新するためのサイズは8MB x 8Byteで64MBになるため、データの圧縮が必要</li>
+  <li>HDや4Kの画面を更新するためのサイズは大きい
+    <ul>
+      <li>4Kの場合8MB x 8Byteで64MB</li>
+    </ul>
+  </li>
+  <li>送信データの圧縮と64KB毎のパケット変換が必要</li>
 </ul>
 
 
@@ -217,20 +237,29 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="multicastの具体的な実装方法">Multicastの具体的な実装方法</h2>
+<h2 id="rfbプロトコルのエンコードタイプ">RFBプロトコルのエンコードタイプ</h2>
 <ul>
-  <li>データの圧縮、Blocking、RFBプロトコルを利用した画像データの送信の3つを行うことでMulticastが実現可能</li>
-  <li></li>
-  <li></li>
+  <li>ZRLEとはRFBプロトコルでサポートされているエンコードタイプの1つ</li>
+  <li>zlib圧縮、タイリング、run lengthエンコードを組み合わせている</li>
+  <li>解凍に必要な辞書を書き出すことができないため、途中からデータを受け取ると正確に解凍できなくなる</li>
 </ul>
 
+<p>(タイリングとrun lengthの説明図)</p>
+
 
 
 </div>
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="圧縮形式">圧縮形式</h2>
+<h2 id="treevncの画像データ圧縮方法">TreeVNCの画像データ圧縮方法</h2>
+<ul>
+  <li></li>
+  <li></li>
+  <li></li>
+</ul>
+
+<center><img src="./fig/EncodeZRLEE.svg" alt="message" width="550" height="450" /></center>
 
 
 
@@ -240,7 +269,13 @@
   <!-- _S9SLIDE_ -->
 <h2 id="ブロッキング">ブロッキング</h2>
 
-<p>##</p>
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h2 id="paket-lossする可能性">paket lossする可能性</h2>
 
 <!-- ## TreeVNC の構造
 - TreeVNCは接続してきたクライアントをNodeとし、木構造状に管理する
diff -r 444d5f272a92 -r 2709c4da4ba9 Slide/slide.md
--- a/Slide/slide.md	Wed May 29 21:23:52 2019 +0900
+++ b/Slide/slide.md	Wed May 29 22:29:14 2019 +0900
@@ -63,29 +63,47 @@
 - 現在のTreeVNCのデータ転送方法だと、無線接続で送信するには大きすぎる 
 - 本研究ではMulticastを導入することで、Wifi環境下における画面配信の遅延対策の検討を行なった
       
+(途中に無線接続,全体delay図)
+
 ## TreeVNCの画面配信方法
 - RFB (Remote Frame Buffer) プロトコルを利用し、自身の画面をネットワークを通じて送信し他者の画面に表示する
 - 他人のPC画面が表示される側と、FrameBufferへの更新が行われる(自身のPC画面を送信する)側に分かれ、それぞれをRFBクライアント、RFBサーバと呼ぶ
 - FrameBufferは、メモリ上に置かれた画像データのこと
 - RFBクライアントに送信するデータは画面全てではなく、変更があった部分のFrameBufferを送る
 
+
 ## Multicastによる画面配信
-- 配信PC画面の変更があった部分のみをマルチキャストで一度のみ送信する
-- wifiのMulticast Paketの最大サイズは64KBである
-- 4Kの画面を更新するためのサイズは8MB x 8Byteで64MBになるため、データの圧縮が必要
+- 配信PC画面の変更があった部分のみをUpdateRectangleとしてマルチキャストで一度のみ送信する
+- RFBプロトコルでは画像データをRectangleで送信しているため、UpdateRectangleには複数のRectangleが入るような構成をとる
+
+<center><img src="./fig/UpdateRectangleStruct.svg" alt="message" width="450" height="350"></center>
 
-
+## Multicastの問題点
+- wifiのMulticast Paketの最大サイズは64KBである
+- HDや4Kの画面を更新するためのサイズは大きい
+    - 4Kの場合8MB x 8Byteで64MB
+- 送信データの圧縮と64KB毎のパケット変換が必要
 
-## Multicastの具体的な実装方法
-- データの圧縮、Blocking、RFBプロトコルを利用した画像データの送信の3つを行うことでMulticastが実現可能
+## RFBプロトコルのエンコードタイプ
+- ZRLEとはRFBプロトコルでサポートされているエンコードタイプの1つ
+- zlib圧縮、タイリング、run lengthエンコードを組み合わせている
+- 解凍に必要な辞書を書き出すことができないため、途中からデータを受け取ると正確に解凍できなくなる
+
+(タイリングとrun lengthの説明図)
+
+## TreeVNCの画像データ圧縮方法
+- 
 - 
 - 
 
-## 圧縮形式
+<center><img src="./fig/EncodeZRLEE.svg" alt="message" width="550" height="450"></center>
+
+ 
 
 ## ブロッキング
 
-## 
+
+## paket lossする可能性
 
 
 
diff -r 444d5f272a92 -r 2709c4da4ba9 Slide/slide.pdf.html
--- a/Slide/slide.pdf.html	Wed May 29 21:23:52 2019 +0900
+++ b/Slide/slide.pdf.html	Wed May 29 22:29:14 2019 +0900
@@ -168,6 +168,8 @@
   <li>本研究ではMulticastを導入することで、Wifi環境下における画面配信の遅延対策の検討を行なった</li>
 </ul>
 
+<p>(途中に無線接続,全体delay図)</p>
+
 
 
 </div>
@@ -190,9 +192,27 @@
   <!-- _S9SLIDE_ -->
 <h2 id="multicastによる画面配信">Multicastによる画面配信</h2>
 <ul>
-  <li>配信PC画面の変更があった部分のみをマルチキャストで一度のみ送信する</li>
+  <li>配信PC画面の変更があった部分のみをUpdateRectangleとしてマルチキャストで一度のみ送信する</li>
+  <li>RFBプロトコルでは画像データをRectangleで送信しているため、UpdateRectangleには複数のRectangleが入るような構成をとる</li>
+</ul>
+
+<center><img src="./fig/UpdateRectangleStruct.svg" alt="message" width="450" height="350" /></center>
+
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h2 id="multicastの問題点">Multicastの問題点</h2>
+<ul>
   <li>wifiのMulticast Paketの最大サイズは64KBである</li>
-  <li>4Kの画面を更新するためのサイズは8MB x 8Byteで64MBになるため、データの圧縮が必要</li>
+  <li>HDや4Kの画面を更新するためのサイズは大きい
+    <ul>
+      <li>4Kの場合8MB x 8Byteで64MB</li>
+    </ul>
+  </li>
+  <li>送信データの圧縮と64KB毎のパケット変換が必要</li>
 </ul>
 
 
@@ -201,20 +221,29 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="multicastの具体的な実装方法">Multicastの具体的な実装方法</h2>
+<h2 id="rfbプロトコルのエンコードタイプ">RFBプロトコルのエンコードタイプ</h2>
 <ul>
-  <li>データの圧縮、Blocking、RFBプロトコルを利用した画像データの送信の3つを行うことでMulticastが実現可能</li>
-  <li></li>
-  <li></li>
+  <li>ZRLEとはRFBプロトコルでサポートされているエンコードタイプの1つ</li>
+  <li>zlib圧縮、タイリング、run lengthエンコードを組み合わせている</li>
+  <li>解凍に必要な辞書を書き出すことができないため、途中からデータを受け取ると正確に解凍できなくなる</li>
 </ul>
 
+<p>(タイリングとrun lengthの説明図)</p>
+
 
 
 </div>
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="圧縮形式">圧縮形式</h2>
+<h2 id="treevncの画像データ圧縮方法">TreeVNCの画像データ圧縮方法</h2>
+<ul>
+  <li></li>
+  <li></li>
+  <li></li>
+</ul>
+
+<center><img src="./fig/EncodeZRLEE.svg" alt="message" width="550" height="450" /></center>
 
 
 
@@ -224,7 +253,13 @@
   <!-- _S9SLIDE_ -->
 <h2 id="ブロッキング">ブロッキング</h2>
 
-<p>##</p>
+
+
+</div>
+
+<div class='slide'>
+  <!-- _S9SLIDE_ -->
+<h2 id="paket-lossする可能性">paket lossする可能性</h2>
 
 <!-- ## TreeVNC の構造
 - TreeVNCは接続してきたクライアントをNodeとし、木構造状に管理する