Mercurial > hg > Papers > 2019 > oshiro-midterm
changeset 4:538cc3c7dcc8
Temporary intermediate proposal
author | oshiro |
---|---|
date | Fri, 16 Nov 2018 17:48:19 +0900 |
parents | b57a41c000a1 |
children | 7d5e681b2c0e |
files | midterm.pdf midterm.tex |
diffstat | 2 files changed, 52 insertions(+), 48 deletions(-) [+] |
line wrap: on
line diff
--- a/midterm.tex Thu Nov 15 16:05:10 2018 +0900 +++ b/midterm.tex Fri Nov 16 17:48:19 2018 +0900 @@ -21,11 +21,11 @@ \begin{document} \title{TreeVNCの拡張} \author{学籍番号 155702F 氏名 {大城}{由也} 指導教員 : {河野}{真治}} -\date{平成30年 11月 22日} +\date{平成30年 11月 16日} \maketitle -\begin{abstract} -\end{abstract} +%\begin{abstract} +%\end{abstract} \thispagestyle{fancy} @@ -49,26 +49,21 @@ \section{RFB(Remote Frame Buffer) プロトコル} RFB プロトコルは、自身の画面を送信しネットワーク越しに他者の画面に表示するプロトコルである。ユーザがいる側を RFB クライアント、Framebuffer への更新が行われる側を RFB サーバと呼ぶ。Framebuffer とは、メモリ上に置かれた画像データである。 -プロトコルを起動した際の動作は以下の順である。\\ -1.プロトコルバージョンの確認や認証を行う。\\ -2.クライアントに向けて Framebuffer の大きさやデスクトップに付けられた名称などが含まれた初期メッセージが送信される。\\ -3.RFB サーバ側は Framebuffer の更新が行われるたびに RFB クライアントに対して Framebuffer の変更部分だけを送信する。\\ -4.RFB クライアントから FramebufferUpdateRequest が来るとそれに返信する。 +プロトコルを起動した際の動作は以下の順である。 +\begin{itemize} + \item プロトコルバージョンの確認や認証を行う。 + \item クライアントに向けて Framebuffer の大きさやデスクトップに付けられた名称などが含まれた初期メッセージが送信される。 + \item RFB サーバ側は Framebuffer の更新が行われるたびに RFB クライアントに対して Framebuffer の変更部分だけを送信する。 + \item RFB クライアントから FramebufferUpdateRequest が来るとそれに返信する。 +\end{itemize} \section{TreeVNC の構造} TreeVNC は Java を用いて作成された TightVNC を元に構成されている。TreeVNC はクライアント同士を接続させ、データを受け取ったクライアントが次のクライアントにそのデータを流す方式を取っている。また、サーバへ接続しにきたクライアントをバイナリツリー状に接続する(図\ref{fig:tree})。バイナリツリー状に接続することで、N 台のクライアントが接続しにきた場合、画面配信の画像データをコピーする回数が従来の VNC ではサーバが N 回コピーする必要があるが、TreeVNC では各ノードが2回ずつコピーするだけで済み、負荷を分散することができる。 TreeVNC で送受信される画像データ量は莫大であり、大きなネットワークスループットが必要となるため、現在では有線接続が必須となっている。 -バイナリツリーのルートのノードを Root Node と呼び、そこに接続されるノードを Node と呼ぶ。Root Node は\\ -1.子 Node にデータを流す機能\\ -2.各 Node の管理\\ -3.VNC サーバから流れてきたデータの管理\\ -を担っている。\\ -各 Node は\\ -1.親 Node から送られてきたデータを自身の子 Node に流す機能\\ -2.子 Node から送られてきたデータを親 Node に流す機能\\ -を担っている。 +バイナリツリーのルートのノードを Root Node と呼び、そこに接続されるノードを Node と呼ぶ。Root Node は子 Node にデータを流す機能・各 Node の管理・VNC サーバから流れてきたデータの管理 +を担っている。各 Node は親 Node から送られてきたデータを自身の子 Node に流す機能・子 Node から送られてきたデータを親 Node に流す機能を担っている。 \begin{figure}[htbp] \begin{center} @@ -105,44 +100,53 @@ \end{center} \end{table} -\section{圧縮形式} -TreeVNC は ZRLEE というエンコードでデータのやり取りを行う。ZRLEE は RFB プロトコルで使えるエンコーディングタイプの ZRLE を元に生成され、ZRLE は Zlib で圧縮されたデータとそのデータのバイト数がヘッダーとして付けて送られてくる。また Zlib は java.util.zip.deflater と java.util.zip.inflater で圧縮と解凍が行える。 - -しかし、java.util.zip.deflater は解凍に必要な辞書を書き出す(flush)ことが出来ない。 -そのため図\ref{fig:zrleFail} のように、Zlib 圧縮されたデータを途中から受け取ってもデータを正しく解凍することが出来ない。 - -そこで ZRLEE は 一度 Root Node で受け取った ZRLE のデータを unzip し、 データを update rectangle という画面毎のデータに辞書を付けて zip し直すことで初めからデータを呼んでいなくても解凍を行えるようになっている(図\ref{fig:zrlee})。 -一度 ZRLEE に変換してしまえば子 Node はそのデータをそのまま流すだけで良い。ただし、deflater と inflater では前回までの通信で得た辞書をクリアしないといけないため、 Root Node と Node 側では毎回新しく作る必要がある。 - -\begin{figure}[htbp] - \begin{center} - \includegraphics[scale=0.4]{./images/zrleFail.pdf} - \end{center} - \caption{ZRLEでの問題点} - \label{fig:zrleFail} -\end{figure} - -\begin{figure}[htbp] - \begin{center} - \includegraphics[scale=0.4]{./images/zrlee.pdf} - \end{center} - \caption{ZRLEE} - \label{fig:zrlee} -\end{figure} +%\section{圧縮形式} +%TreeVNC は ZRLEE というエンコードでデータのやり取りを行う。ZRLEE は RFB プロトコルで使えるエンコーディングタイプの ZRLE を元に生成され、ZRLE は Zlib で圧縮されたデータとそのデータのバイト数がヘッダーとして付けて送られてくる。また Zlib は java.util.zip.deflater と java.util.zip.inflater で圧縮と解凍が行える。 +% +%しかし、java.util.zip.deflater は解凍に必要な辞書を書き出す(flush)ことが出来ない。 +%そのため図\ref{fig:zrleFail} のように、Zlib 圧縮されたデータを途中から受け取ってもデータを正しく解凍することが出来ない。 +% +%そこで ZRLEE は 一度 Root Node で受け取った ZRLE のデータを unzip し、 データを update rectangle という画面毎のデータに辞書を付けて zip し直すことで初めからデータを呼んでいなくても解凍を行えるようになっている(図\ref{fig:zrlee})。 +%一度 ZRLEE に変換してしまえば子 Node はそのデータをそのまま流すだけで良い。ただし、deflater と inflater では前回までの通信で得た辞書をクリアしないといけないため、 Root Node と Node 側では毎回新しく作る必要がある。 +% +%\begin{figure}[htbp] +% \begin{center} +% \includegraphics[scale=0.4]{./images/zrleFail.pdf} +% \end{center} +% \caption{ZRLEでの問題点} +% \label{fig:zrleFail} +%\end{figure} +% +%\begin{figure}[htbp] +% \begin{center} +% \includegraphics[scale=0.4]{./images/zrlee.pdf} +% \end{center} +% \caption{ZRLEE} +% \label{fig:zrlee} +%\end{figure} \newpage -\section{マルチキャスト配信への対応} -TreeVNC は現在有線接続でのみ安定した動作をみせている。しかし、講義の際、毎回コードを持参することは負担であるため、無線接続での安定した動作を確立したい。そこで、Wi-Fiを利用したマルチキャストの対応を行う。 +\section{課題} + +%1) TreeVNCのbug取り (VNCserver側を止めらると暴走するとか) +%2) Christie を使った実装(現状の実装の通信部分の切り分け +%3) Christie によるNAT越え +%4) Multicast・Broadcast によるWifiでの使用 + +現在の TreeVNC の問題として、 VNC サーバ側を停止することでクライアントとの接続が切断されると error ログをはき続けて暴走してしまう点や、無線接続では動作が安定しない点が挙げられる。今後の方針として、暴走を止めるためのコード修正と、無線接続での安定した動作を確立のために Wi-Fi を利用した Multicast ・ Broadcast の対応を行う。 + +また本研究室では、データ通信に対して信頼性と拡張性の高い通信の提供を目的とした分散フレームワークシステム Christie の開発・設計を行っており、その前身となった Alice で AliseVNC の実装がすでに行われているため、 Christie を使用した TreeVNC の再実装を行う。 +%その際、 Christie による NAT 越えの実装も行う。 \section{まとめ} -本研究では TreeVNC によるマルチキャスト配信への対応を行っている。 +本研究で Multicast ・ Broadcast による Wi-Fi での使用の対応・ Christie を使用した再実装を行うことで、 TreeVNC の安定した動作を実現することができ、講義などでの使用がより現実的になる。 + -この研究により今後の TreeVNC の利用時に無線 LAN を使っての接続がより快適なものになると考えられる。 - -今後の課題としては、 無線 LAN で送信できるサイズへのデータ分割、圧縮などが挙げられる。 - +% 参考文献 +\def\line{−\hspace*{-.7zw}−} \nocite{*} \bibliographystyle{junsrt} \bibliography{reference} + \end{document} \ No newline at end of file