Mercurial > hg > Papers > 2019 > riono-sigos

changeset 40:b48db21c9d66

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
comment out to
author e165729 <e165729@ie.u-ryukyu.ac.jp>
date Wed, 29 May 2019 15:52:22 +0900
parents a36e5abf494d
children 565b8345d7ef
files Slide/slide.html Slide/slide.md Slide/slide.pdf.html
diffstat 3 files changed, 133 insertions(+), 251 deletions(-) [+]
line wrap: on
line diff
--- a/Slide/slide.html	Wed May 29 15:09:45 2019 +0900
+++ b/Slide/slide.html	Wed May 29 15:52:22 2019 +0900
@@ -166,7 +166,7 @@
 <ul>
   <li>画面配信は送信するデータ量が多いため、TreeVNCでは無線接続の場合、画面配信の遅延が大きくなってしまう</li>
   <li>現在のTreeVNCのデータ転送方法だと、無線接続で送信するには大きすぎる</li>
-  <li>本研究ではマルチキャストを導入することで、Wifi環境下における画面配信の遅延対策の検討する</li>
+  <li>本研究ではMulticastを導入することで、Wifi環境下における画面配信の遅延対策の検討を行なった</li>
 </ul>
 
 
@@ -175,7 +175,12 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="マルチキャストについて">マルチキャストについて</h2>
+<h2 id="multicastについて">Multicastについて</h2>
+<ul>
+  <li>WifiのMulticast機能を利用することで無線LAN接続時でも画面遅延を軽減できると考える</li>
+  <li>配信PC画面の変更があった部分のみをマルチキャストで送信する</li>
+  <li>wifiのMulticast Paketの最大サイズは64KBとなっているため、データの圧縮が必要</li>
+</ul>
 
 
 
@@ -184,6 +189,11 @@
 <div class='slide'>
   <!-- _S9SLIDE_ -->
 <h2 id="解決手順">解決手順</h2>
+<ul>
+  <li></li>
+  <li></li>
+  <li></li>
+</ul>
 
 
 
@@ -213,139 +223,67 @@
   <li>FrameBufferは、メモリ上に置かれた画像データのこと</li>
 </ul>
 
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="treevnc-の構造">TreeVNC の構造</h2>
-<ul>
-  <li>TreeVNCは接続してきたクライアントをNodeとし、木構造状に管理する</li>
-  <li>ルートのノードをRoot Nodeと呼び、その下に新たなNodeを接続していく</li>
-  <li>Root Nodeが参照しているVNCServerからFrameBufferUpdateを取得し、各Nodeに送信する</li>
-  <li>木構造状に接続することで、画像データのコピーを各Nodeに負担させることができる</li>
-</ul>
-
-<center><img src="./fig/treevnc-crop.svg" alt="message" width="450" height="350" /></center>
-
-
-
-</div>
+<!-- ## TreeVNC の構造
+- TreeVNCは接続してきたクライアントをNodeとし、木構造状に管理する
+- ルートのノードをRoot Nodeと呼び、その下に新たなNodeを接続していく
+- Root Nodeが参照しているVNCServerからFrameBufferUpdateを取得し、各Nodeに送信する
+- 木構造状に接続することで、画像データのコピーを各Nodeに負担させることができる
 
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="木構造の再構成">木構造の再構成</h2>
-<ul>
-  <li>Nodeが切断されたことを検知できなければ木構造が維持できない</li>
-  <li>Root Nodeが木構造のネットワークトポロジーを管理しているため、Root NodeにNodeの切断を知らせる必要がある</li>
-  <li>切断検知には画像データが入っているMulticastQueueを使用</li>
-  <li>MulticastQueueから画像データが一定時間取得されず、Timeoutを検知した場合切断したと判断する</li>
-</ul>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="画像データのエンコード方法">画像データのエンコード方法</h2>
-<ul>
-  <li>TreeVNCではZRLEというエンコードタイプを元にした、ZRLEEというエンコードを用いて画像データを圧縮を行う</li>
-  <li>ZRLEはZlibで圧縮されたデータとそのデータのバイト数がヘッダーとして送られる</li>
-  <li>Zlibとはデータの可逆圧縮アルゴリズムが実装されているライブラリ</li>
-</ul>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="画像データのエンコード方法-1">画像データのエンコード方法</h2>
-<ul>
-  <li>ZRLEでは解凍時に必要な辞書データを書き出すことができない</li>
-  <li>ZRLEEはRoot Nodeで受け取ったZRLEのデータを一度解凍し、辞書データを付与して再圧縮している</li>
-</ul>
-
-<center><img src="./fig/EncodeZRLEE.svg" alt="message" width="550" height="450" /></center>
-
+<center><img src="./fig/treevnc-crop.svg" alt="message" width="450" height="350"></center>
 
 
-</div>
+## 木構造の再構成
+- Nodeが切断されたことを検知できなければ木構造が維持できない
+- Root Nodeが木構造のネットワークトポロジーを管理しているため、Root NodeにNodeの切断を知らせる必要がある
+- 切断検知には画像データが入っているMulticastQueueを使用
+- MulticastQueueから画像データが一定時間取得されず、Timeoutを検知した場合切断したと判断する
 
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="共有画面切り替え">共有画面切り替え</h2>
-<ul>
-  <li>従来のVNCでは、配信者が切り替わるたびに再起動、再接続を行う必要があった</li>
-  <li>TreeVNCでは、画面上にあるShareScreenボタンを押すことで配信者の切り替えが実行できる</li>
-  <li>ShareScreen実行後、Root Nodeに対しSERVER CHANGE REQUESTというメッセージが送信される</li>
-  <li>メッセージを受け取ったRoot Nodeは配信を希望しているNodeのVNCサーバーと通信を行い、切り替え作業に入る</li>
-</ul>
+## 画像データのエンコード方法
+- TreeVNCではZRLEというエンコードタイプを元にした、ZRLEEというエンコードを用いて画像データを圧縮を行う
+- ZRLEはZlibで圧縮されたデータとそのデータのバイト数がヘッダーとして送られる
+- Zlibとはデータの可逆圧縮アルゴリズムが実装されているライブラリ
 
-<center><img src="./fig/ShareScreenSS.svg" alt="message" width="400" height="300" /></center>
+## 画像データのエンコード方法
+- ZRLEでは解凍時に必要な辞書データを書き出すことができない
+- ZRLEEはRoot Nodeで受け取ったZRLEのデータを一度解凍し、辞書データを付与して再圧縮している
+
+<center><img src="./fig/EncodeZRLEE.svg" alt="message" width="550" height="450"></center>
 
-
+## 共有画面切り替え
+- 従来のVNCでは、配信者が切り替わるたびに再起動、再接続を行う必要があった
+- TreeVNCでは、画面上にあるShareScreenボタンを押すことで配信者の切り替えが実行できる
+- ShareScreen実行後、Root Nodeに対しSERVER CHANGE REQUESTというメッセージが送信される
+- メッセージを受け取ったRoot Nodeは配信を希望しているNodeのVNCサーバーと通信を行い、切り替え作業に入る
 
-</div>
+<center><img src="./fig/ShareScreenSS.svg" alt="message" width="400" height="300"></center>
 
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="有線接続との接続の違い">有線接続との接続の違い</h2>
-<ul>
-  <li>現状のTreeVNCでは画面配信のデータ量は多く、無線LAN接続を行うと画面配信の遅延が大きくなる</li>
-  <li>WifiのMulticast機能を利用し、UpdateRectangleを一度だけ送信することで無線LAN接続でも十分に遅延が抑えられると考える</li>
-  <li>HDや4kの画面更新には64MB程度となり、これを圧縮しつつwifiのMulticast paketの最大サイズ64KBに変換、送信する必要がある</li>
-  <li>paket lossがあった場合、再送処理は複雑であると予想できるため、まずBlokingによる実験を行う</li>
-</ul>
+## 有線接続との接続の違い
+- 現状のTreeVNCでは画面配信のデータ量は多く、無線LAN接続を行うと画面配信の遅延が大きくなる
+- WifiのMulticast機能を利用し、UpdateRectangleを一度だけ送信することで無線LAN接続でも十分に遅延が抑えられると考える
+- HDや4kの画面更新には64MB程度となり、これを圧縮しつつwifiのMulticast paketの最大サイズ64KBに変換、送信する必要がある
+- paket lossがあった場合、再送処理は複雑であると予想できるため、まずBlokingによる実験を行う
 
+## RFBプロトコルのUpdateRectangleの構成
+- 1つのUpdateRectangleには複数のRectangleが格納されている
+- RectangleはZlibで圧縮されたデータが指定された長さだけ格納されており、そのデータはさらに64x64 ByteのTileに分割されている
+
+## RFBプロトコルのUpdateRectangleの構成
+- 無線接続の場合、一度に送信できるデータ量が64KBしかないため、それに合わせて更新された部分のRectangleを分割する必要がある
+    - Phase0 行の途中から始まる部分
+    - Phase1 行の最初から最後までの部分
+    - Phase2 行の途中で終わる部分
+
+<center><img src="./fig/FrameUpdateRectangleColor.svg" alt="message" width="550" height="450"></center>
 
 
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="rfbプロトコルのupdaterectangleの構成">RFBプロトコルのUpdateRectangleの構成</h2>
-<ul>
-  <li>1つのUpdateRectangleには複数のRectangleが格納されている</li>
-  <li>RectangleはZlibで圧縮されたデータが指定された長さだけ格納されており、そのデータはさらに64x64 ByteのTileに分割されている</li>
-</ul>
-
-
-
-</div>
+## 木構造とマルチキャストの共存
+- ツリーに無線接続のNodeを加えてしまうと全体の配信遅延に繋がる
+- 無線接続時のMulticastの実装を提案
+- Multicastならば、Serverからの送信は一度で済むため、ツリー構造の形成が必要ない
+- 従って新しいNodeが無線接続であっても、有線接続のツリーの配信には影響が出ない
 
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="rfbプロトコルのupdaterectangleの構成-1">RFBプロトコルのUpdateRectangleの構成</h2>
-<ul>
-  <li>無線接続の場合、一度に送信できるデータ量が64KBしかないため、それに合わせて更新された部分のRectangleを分割する必要がある
-    <ul>
-      <li>Phase0 行の途中から始まる部分</li>
-      <li>Phase1 行の最初から最後までの部分</li>
-      <li>Phase2 行の途中で終わる部分</li>
-    </ul>
-  </li>
-</ul>
-
-<center><img src="./fig/FrameUpdateRectangleColor.svg" alt="message" width="550" height="450" /></center>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="木構造とマルチキャストの共存">木構造とマルチキャストの共存</h2>
-<ul>
-  <li>ツリーに無線接続のNodeを加えてしまうと全体の配信遅延に繋がる</li>
-  <li>無線接続時のMulticastの実装を提案</li>
-  <li>Multicastならば、Serverからの送信は一度で済むため、ツリー構造の形成が必要ない</li>
-  <li>従って新しいNodeが無線接続であっても、有線接続のツリーの配信には影響が出ない</li>
-</ul>
-
-<center><img src="./fig/interface-crop.svg" alt="message" width="500" height="450" /></center>
+<center><img src="./fig/interface-crop.svg" alt="message" width="500" height="450"></center>
+-->
 
 
 
--- a/Slide/slide.md	Wed May 29 15:09:45 2019 +0900
+++ b/Slide/slide.md	Wed May 29 15:52:22 2019 +0900
@@ -53,13 +53,19 @@
 ## 本研究の概要
 - 画面配信は送信するデータ量が多いため、TreeVNCでは無線接続の場合、画面配信の遅延が大きくなってしまう
 - 現在のTreeVNCのデータ転送方法だと、無線接続で送信するには大きすぎる 
-- 本研究ではマルチキャストを導入することで、Wifi環境下における画面配信の遅延対策の検討する
+- 本研究ではMulticastを導入することで、Wifi環境下における画面配信の遅延対策の検討を行なった
       
 
-## マルチキャストについて
+## Multicastについて
+- WifiのMulticast機能を利用することで無線LAN接続時でも画面遅延を軽減できると考える
+- 配信PC画面の変更があった部分のみをマルチキャストで送信する
+- wifiのMulticast Paketの最大サイズは64KBとなっているため、データの圧縮が必要
+
 
 ## 解決手順
-
+- 
+- 
+- 
 
 ## VNC
 - VNC(Virtual Network Computing)は、RFBプロトコルを用いてPCの遠隔操作を行うことを目的としたリモートデスクトップソフトウェア
@@ -73,7 +79,7 @@
 - 他人のPC画面が表示される側と、FrameBufferへの更新が行われる(自身のPC画面を送信する)側に分かれ、それぞれをRFBクライアント、RFBサーバと呼ぶ
 - FrameBufferは、メモリ上に置かれた画像データのこと
 
-## TreeVNC の構造
+<!-- ## TreeVNC の構造
 - TreeVNCは接続してきたクライアントをNodeとし、木構造状に管理する
 - ルートのノードをRoot Nodeと呼び、その下に新たなNodeを接続していく
 - Root Nodeが参照しているVNCServerからFrameBufferUpdateを取得し、各Nodeに送信する
@@ -133,7 +139,7 @@
 - 従って新しいNodeが無線接続であっても、有線接続のツリーの配信には影響が出ない
 
 <center><img src="./fig/interface-crop.svg" alt="message" width="500" height="450"></center>
-
+-->
 
 ## まとめ
 - WifiでMulticast paketを利用する手法についての考察を行なった
--- a/Slide/slide.pdf.html	Wed May 29 15:09:45 2019 +0900
+++ b/Slide/slide.pdf.html	Wed May 29 15:52:22 2019 +0900
@@ -150,7 +150,7 @@
 <ul>
   <li>画面配信は送信するデータ量が多いため、TreeVNCでは無線接続の場合、画面配信の遅延が大きくなってしまう</li>
   <li>現在のTreeVNCのデータ転送方法だと、無線接続で送信するには大きすぎる</li>
-  <li>本研究ではマルチキャストを導入することで、Wifi環境下における画面配信の遅延対策の検討する</li>
+  <li>本研究ではMulticastを導入することで、Wifi環境下における画面配信の遅延対策の検討を行なった</li>
 </ul>
 
 
@@ -159,7 +159,12 @@
 
 <div class='slide'>
   <!-- _S9SLIDE_ -->
-<h2 id="マルチキャストについて">マルチキャストについて</h2>
+<h2 id="multicastについて">Multicastについて</h2>
+<ul>
+  <li>WifiのMulticast機能を利用することで無線LAN接続時でも画面遅延を軽減できると考える</li>
+  <li>配信PC画面の変更があった部分のみをマルチキャストで送信する</li>
+  <li>wifiのMulticast Paketの最大サイズは64KBとなっているため、データの圧縮が必要</li>
+</ul>
 
 
 
@@ -168,6 +173,11 @@
 <div class='slide'>
   <!-- _S9SLIDE_ -->
 <h2 id="解決手順">解決手順</h2>
+<ul>
+  <li></li>
+  <li></li>
+  <li></li>
+</ul>
 
 
 
@@ -197,139 +207,67 @@
   <li>FrameBufferは、メモリ上に置かれた画像データのこと</li>
 </ul>
 
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="treevnc-の構造">TreeVNC の構造</h2>
-<ul>
-  <li>TreeVNCは接続してきたクライアントをNodeとし、木構造状に管理する</li>
-  <li>ルートのノードをRoot Nodeと呼び、その下に新たなNodeを接続していく</li>
-  <li>Root Nodeが参照しているVNCServerからFrameBufferUpdateを取得し、各Nodeに送信する</li>
-  <li>木構造状に接続することで、画像データのコピーを各Nodeに負担させることができる</li>
-</ul>
-
-<center><img src="./fig/treevnc-crop.svg" alt="message" width="450" height="350" /></center>
-
-
-
-</div>
+<!-- ## TreeVNC の構造
+- TreeVNCは接続してきたクライアントをNodeとし、木構造状に管理する
+- ルートのノードをRoot Nodeと呼び、その下に新たなNodeを接続していく
+- Root Nodeが参照しているVNCServerからFrameBufferUpdateを取得し、各Nodeに送信する
+- 木構造状に接続することで、画像データのコピーを各Nodeに負担させることができる
 
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="木構造の再構成">木構造の再構成</h2>
-<ul>
-  <li>Nodeが切断されたことを検知できなければ木構造が維持できない</li>
-  <li>Root Nodeが木構造のネットワークトポロジーを管理しているため、Root NodeにNodeの切断を知らせる必要がある</li>
-  <li>切断検知には画像データが入っているMulticastQueueを使用</li>
-  <li>MulticastQueueから画像データが一定時間取得されず、Timeoutを検知した場合切断したと判断する</li>
-</ul>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="画像データのエンコード方法">画像データのエンコード方法</h2>
-<ul>
-  <li>TreeVNCではZRLEというエンコードタイプを元にした、ZRLEEというエンコードを用いて画像データを圧縮を行う</li>
-  <li>ZRLEはZlibで圧縮されたデータとそのデータのバイト数がヘッダーとして送られる</li>
-  <li>Zlibとはデータの可逆圧縮アルゴリズムが実装されているライブラリ</li>
-</ul>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="画像データのエンコード方法-1">画像データのエンコード方法</h2>
-<ul>
-  <li>ZRLEでは解凍時に必要な辞書データを書き出すことができない</li>
-  <li>ZRLEEはRoot Nodeで受け取ったZRLEのデータを一度解凍し、辞書データを付与して再圧縮している</li>
-</ul>
-
-<center><img src="./fig/EncodeZRLEE.svg" alt="message" width="550" height="450" /></center>
-
+<center><img src="./fig/treevnc-crop.svg" alt="message" width="450" height="350"></center>
 
 
-</div>
+## 木構造の再構成
+- Nodeが切断されたことを検知できなければ木構造が維持できない
+- Root Nodeが木構造のネットワークトポロジーを管理しているため、Root NodeにNodeの切断を知らせる必要がある
+- 切断検知には画像データが入っているMulticastQueueを使用
+- MulticastQueueから画像データが一定時間取得されず、Timeoutを検知した場合切断したと判断する
 
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="共有画面切り替え">共有画面切り替え</h2>
-<ul>
-  <li>従来のVNCでは、配信者が切り替わるたびに再起動、再接続を行う必要があった</li>
-  <li>TreeVNCでは、画面上にあるShareScreenボタンを押すことで配信者の切り替えが実行できる</li>
-  <li>ShareScreen実行後、Root Nodeに対しSERVER CHANGE REQUESTというメッセージが送信される</li>
-  <li>メッセージを受け取ったRoot Nodeは配信を希望しているNodeのVNCサーバーと通信を行い、切り替え作業に入る</li>
-</ul>
+## 画像データのエンコード方法
+- TreeVNCではZRLEというエンコードタイプを元にした、ZRLEEというエンコードを用いて画像データを圧縮を行う
+- ZRLEはZlibで圧縮されたデータとそのデータのバイト数がヘッダーとして送られる
+- Zlibとはデータの可逆圧縮アルゴリズムが実装されているライブラリ
 
-<center><img src="./fig/ShareScreenSS.svg" alt="message" width="400" height="300" /></center>
+## 画像データのエンコード方法
+- ZRLEでは解凍時に必要な辞書データを書き出すことができない
+- ZRLEEはRoot Nodeで受け取ったZRLEのデータを一度解凍し、辞書データを付与して再圧縮している
+
+<center><img src="./fig/EncodeZRLEE.svg" alt="message" width="550" height="450"></center>
 
-
+## 共有画面切り替え
+- 従来のVNCでは、配信者が切り替わるたびに再起動、再接続を行う必要があった
+- TreeVNCでは、画面上にあるShareScreenボタンを押すことで配信者の切り替えが実行できる
+- ShareScreen実行後、Root Nodeに対しSERVER CHANGE REQUESTというメッセージが送信される
+- メッセージを受け取ったRoot Nodeは配信を希望しているNodeのVNCサーバーと通信を行い、切り替え作業に入る
 
-</div>
+<center><img src="./fig/ShareScreenSS.svg" alt="message" width="400" height="300"></center>
 
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="有線接続との接続の違い">有線接続との接続の違い</h2>
-<ul>
-  <li>現状のTreeVNCでは画面配信のデータ量は多く、無線LAN接続を行うと画面配信の遅延が大きくなる</li>
-  <li>WifiのMulticast機能を利用し、UpdateRectangleを一度だけ送信することで無線LAN接続でも十分に遅延が抑えられると考える</li>
-  <li>HDや4kの画面更新には64MB程度となり、これを圧縮しつつwifiのMulticast paketの最大サイズ64KBに変換、送信する必要がある</li>
-  <li>paket lossがあった場合、再送処理は複雑であると予想できるため、まずBlokingによる実験を行う</li>
-</ul>
+## 有線接続との接続の違い
+- 現状のTreeVNCでは画面配信のデータ量は多く、無線LAN接続を行うと画面配信の遅延が大きくなる
+- WifiのMulticast機能を利用し、UpdateRectangleを一度だけ送信することで無線LAN接続でも十分に遅延が抑えられると考える
+- HDや4kの画面更新には64MB程度となり、これを圧縮しつつwifiのMulticast paketの最大サイズ64KBに変換、送信する必要がある
+- paket lossがあった場合、再送処理は複雑であると予想できるため、まずBlokingによる実験を行う
 
+## RFBプロトコルのUpdateRectangleの構成
+- 1つのUpdateRectangleには複数のRectangleが格納されている
+- RectangleはZlibで圧縮されたデータが指定された長さだけ格納されており、そのデータはさらに64x64 ByteのTileに分割されている
+
+## RFBプロトコルのUpdateRectangleの構成
+- 無線接続の場合、一度に送信できるデータ量が64KBしかないため、それに合わせて更新された部分のRectangleを分割する必要がある
+    - Phase0 行の途中から始まる部分
+    - Phase1 行の最初から最後までの部分
+    - Phase2 行の途中で終わる部分
+
+<center><img src="./fig/FrameUpdateRectangleColor.svg" alt="message" width="550" height="450"></center>
 
 
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="rfbプロトコルのupdaterectangleの構成">RFBプロトコルのUpdateRectangleの構成</h2>
-<ul>
-  <li>1つのUpdateRectangleには複数のRectangleが格納されている</li>
-  <li>RectangleはZlibで圧縮されたデータが指定された長さだけ格納されており、そのデータはさらに64x64 ByteのTileに分割されている</li>
-</ul>
-
-
-
-</div>
+## 木構造とマルチキャストの共存
+- ツリーに無線接続のNodeを加えてしまうと全体の配信遅延に繋がる
+- 無線接続時のMulticastの実装を提案
+- Multicastならば、Serverからの送信は一度で済むため、ツリー構造の形成が必要ない
+- 従って新しいNodeが無線接続であっても、有線接続のツリーの配信には影響が出ない
 
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="rfbプロトコルのupdaterectangleの構成-1">RFBプロトコルのUpdateRectangleの構成</h2>
-<ul>
-  <li>無線接続の場合、一度に送信できるデータ量が64KBしかないため、それに合わせて更新された部分のRectangleを分割する必要がある
-    <ul>
-      <li>Phase0 行の途中から始まる部分</li>
-      <li>Phase1 行の最初から最後までの部分</li>
-      <li>Phase2 行の途中で終わる部分</li>
-    </ul>
-  </li>
-</ul>
-
-<center><img src="./fig/FrameUpdateRectangleColor.svg" alt="message" width="550" height="450" /></center>
-
-
-
-</div>
-
-<div class='slide'>
-  <!-- _S9SLIDE_ -->
-<h2 id="木構造とマルチキャストの共存">木構造とマルチキャストの共存</h2>
-<ul>
-  <li>ツリーに無線接続のNodeを加えてしまうと全体の配信遅延に繋がる</li>
-  <li>無線接続時のMulticastの実装を提案</li>
-  <li>Multicastならば、Serverからの送信は一度で済むため、ツリー構造の形成が必要ない</li>
-  <li>従って新しいNodeが無線接続であっても、有線接続のツリーの配信には影響が出ない</li>
-</ul>
-
-<center><img src="./fig/interface-crop.svg" alt="message" width="500" height="450" /></center>
+<center><img src="./fig/interface-crop.svg" alt="message" width="500" height="450"></center>
+-->