Mercurial > hg > Papers > 2014 > taninari-master
diff paper/conclusion.tex @ 26:aec4085dd5db
update
author | Taninari YU <you@cr.ie.u-ryukyu.ac.jp> |
---|---|
date | Tue, 04 Feb 2014 03:50:01 +0900 |
parents | 2d6118b66367 |
children | 7149e38f717c |
line wrap: on
line diff
--- a/paper/conclusion.tex Mon Feb 03 22:14:54 2014 +0900 +++ b/paper/conclusion.tex Tue Feb 04 03:50:01 2014 +0900 @@ -6,7 +6,7 @@ 実装を行っていく中で必要になる、新しいEncodingタイプZRLLEの開発、木の再構成の機能、MulticastQueue等の機能が必要だとわかったので、これらの設計を行い実装を行った。 更に、TreeVNCをゼミで使用した際、画面の切り替え機能、ディスプレイの指定機能などが必要だと感じたので、それらの設計、実装を行った。 検証では、学科で用意されている並列計算環境を使用して、木のRoot Nodeから一番下のNodeまでの画像送信の遅延やTimeOutThreadによる画像のロスト率の検証を行い、木の分岐数の最適化について考察を行った。 -それから、実装した画面切り替えUIの妥当性について考察を行った。 +それから、開発したエンコードZRLEEとZRLEのデータ量の比較を行った。 @@ -17,6 +17,7 @@ Java6までは、圧縮を行うライブラリDeflaterにflushの機能がなく、TreeVNCでは独自のEncoding、ZRLEEを作成する必要があった。 しかし、ZRLEEを使用すると、通常のVNCでは、データをdecodeすることができないので、Javaを実行できないIPadなどではTreeVNCを使用することができない。 そこで、Java7から実装されたDeflaterのflush機能を使用して、ZRLEEをZRLEに変換することで、通常のVNCでdecodeすることができるようになる。 +それにより、Javaの実行環境を持たない端末の使用も可能になる。 \subsection{Multicast対応} Broadcastはパケットロス率が高すぎるので使用することは難しいが、Multicastのロス率だと、うまくいく見込がある。 @@ -28,6 +29,6 @@ 画像データは、一旦Root Nodeで解凍されるので、headerの情報を読み込み、適切なサイズに画像を加工し、headerを適切な値に変更することで、画面の範囲を指定できるようになる。 TreeVNCでは、画像の配信にMulticastQueueを使用している。 高解像度のディスプレイを使用すると、MulticastQueueのデータ量が増えてしまい、Memory Over Flowを起こす可能性がある。 -画面範囲の指定ができるようになれば、Mac Book Retina等の高解像度ディスプレイでも安定して画面共有をすることができるようになる。 +画面範囲の指定ができるようになれば、データ量を減らすことができるので、Mac Book Retina等の高解像度ディスプレイでも安定して画面共有をすることができるようになる。