Mercurial > hg > Papers > 2014 > taninari-master
view paper/conclusion.tex @ 24:b6a6413ac3ca
add files
author | Taninari YU <you@cr.ie.u-ryukyu.ac.jp> |
---|---|
date | Mon, 03 Feb 2014 16:56:17 +0900 |
parents | 1f4e9f5aedc7 |
children | 2d6118b66367 |
line wrap: on
line source
\chapter{結論} \label{chapter:conclusion} \section{まとめ} 今回の研究では、初めに、プロジェクタを使用している授業の問題点をあげ、解決するために画面共有を使用する新しい授業スタイルを提案した。 そこで、画面共有を多人数で使用した際に発生する問題点について考察した。考察から得られた知見を元に、VNC Serverへの接続者を木構造に接続させ負荷を分散するソフトウェアTreeVNCの設計方法について論じた。 実装を行っていく中で必要になる、新しいEncodingタイプZRLLEの開発、木の再構成の機能、MulticastQueue等の機能が必要だとわかったので、これらの設計を行い実装を行った。 更に、TreeVNCをゼミで使用した際、画面の切り替え機能、ディスプレイの指定機能などが必要だと感じたので、それらの設計、実装を行った。 検証では、学科で用意されている並列計算環境を使用して、木のRoot Nodeから一番下のNodeまでの画像送信の遅延やTimeOutThreadによる画像のロスト率の検証を行い、木の分岐数の最適化について考察を行った。 それから、実装した画面切り替えUIの妥当性について考察を行った。 \section{今後の課題} \subsection{iPad・無線への対応} Java6までは、圧縮を行うライブラリDeflaterにflushの機能がなく、TreeVNCでは独自のEncoding、ZRLEEを作成する必要があった。 しかし、ZRLEEを使用すると、通常のVNCでは、データをdecodeすることができないので、Javaを実行できないIPadなどではTreeVNCを使用することができない。 そこで、Java7から実装されたDeflaterのflush機能を使用して、ZRLEEをZRLEに変換することで、通常のVNCでdecodeすることができるようになる。 \subsection{Multicast対応} Broadcastはパケットロス率が高すぎるので使用することは難しいが、Multicastのロス率だと、うまくいく見込がある。 Multicastを使用する際は、一回に送るデータ量は64000Byteである必要がある。 私が行ったデータのBlockingは64000byte毎にByteBufferのコピーを行っていたので、処理が重くなっていた。しかし、コピーせずBufferをwrapすることで、処理が軽くなる。 \subsection{画面範囲の指定} ディスプレイの指定はできるようになったが、現在は画面の範囲指定ができていない。 画像データは一旦Root Nodeで解凍されるのでその際に画像を加工することで、画面の範囲を指定できるようになる。