# HG changeset patch # User Tatsuki IHA # Date 1448792177 -32400 # Node ID aaa9a0f50d3f9f112df455d4c0690be52902d0d3 # Parent 6daaf5e03e4d61af6efe246c55bda20a2be2a959 Update 11_29_19:16 diff -r 6daaf5e03e4d -r aaa9a0f50d3f paper/pic/checkDelay.pdf Binary file paper/pic/checkDelay.pdf has changed diff -r 6daaf5e03e4d -r aaa9a0f50d3f paper/pic/checkDelay.xbb --- a/paper/pic/checkDelay.xbb Sat Nov 28 19:52:32 2015 +0900 +++ b/paper/pic/checkDelay.xbb Sun Nov 29 19:16:17 2015 +0900 @@ -1,8 +1,8 @@ -%%Title: checkDelay.pdf +%%Title: pic/checkDelay.pdf %%Creator: extractbb 20150315 -%%BoundingBox: 0 0 586 191 -%%HiResBoundingBox: 0.000000 0.000000 585.750000 191.250000 -%%PDFVersion: 1.3 +%%BoundingBox: 0 0 857 370 +%%HiResBoundingBox: 0.000000 0.000000 857.000000 370.000000 +%%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Tue Nov 10 00:36:38 2015 +%%CreationDate: Sun Nov 29 16:57:36 2015 diff -r 6daaf5e03e4d -r aaa9a0f50d3f paper/pic/directConnection.graffle Binary file paper/pic/directConnection.graffle has changed diff -r 6daaf5e03e4d -r aaa9a0f50d3f paper/pic/directConnection.pdf Binary file paper/pic/directConnection.pdf has changed diff -r 6daaf5e03e4d -r aaa9a0f50d3f paper/pic/directConnection.xbb --- a/paper/pic/directConnection.xbb Sat Nov 28 19:52:32 2015 +0900 +++ b/paper/pic/directConnection.xbb Sun Nov 29 19:16:17 2015 +0900 @@ -1,8 +1,8 @@ -%%Title: directConnection.pdf +%%Title: pic/directConnection.pdf %%Creator: extractbb 20150315 -%%BoundingBox: 0 0 860 375 -%%HiResBoundingBox: 0.000000 0.000000 860.000000 375.000000 +%%BoundingBox: 0 0 719 375 +%%HiResBoundingBox: 0.000000 0.000000 719.000000 375.000000 %%PDFVersion: 1.4 %%Pages: 1 -%%CreationDate: Tue Nov 10 15:59:04 2015 +%%CreationDate: Sun Nov 29 16:43:34 2015 diff -r 6daaf5e03e4d -r aaa9a0f50d3f paper/prosym.pdf Binary file paper/prosym.pdf has changed diff -r 6daaf5e03e4d -r aaa9a0f50d3f paper/prosym.tex --- a/paper/prosym.tex Sat Nov 28 19:52:32 2015 +0900 +++ b/paper/prosym.tex Sun Nov 29 19:16:17 2015 +0900 @@ -60,8 +60,8 @@ \begin{abstract} ゼミや授業等で、それぞれがPC端末を持っている場合では、PCの機能を活かしたコミュニケーションが可能である。教員が操作する画面をそのまま学生に配信したり, ゼミなどで、発表する学生の画面を切り替えたりすることを可能にしたい。 - TreeVNCは参加したクライアントをバイナリツリー状に接続し、配信コストを分散させる仕組みを取っている。そのため,多人数が参加しても処理性能が下がらない。また、ツリーのRootが見ているVNCサーバーを変更することで、ケーブルの差し替えなしに画面の切替が可能となる。 - 今研究ではTreeVNCの改良として、WANへの対応、 マルチディスプレイへの対応を行う。 + 画面配信システムTreeVNCは参加したクライアントをバイナリツリー状に接続し、配信コストを分散させる仕組みを取っている。そのため,多人数が参加しても処理性能が下がらない。また、ツリーのルートが参照しているVNCサーバーを変更することで、ケーブルの差し替えなしに画面の切替が可能となる。 + 今研究ではTreeVNCの改良として、WANへの対応、 マルチディスプレイへの対応を行った。 \end{abstract} \begin{jkeyword} @@ -71,16 +71,16 @@ % Body %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \section{研究背景と目的} +% 後で考える ゼミや授業等で、それぞれがPC端末を持っている場合では、 PCの機能を活かしたコミュニケーションが可能である。 -教員が操作する画面をそのまま学生に配信したり、 -ゼミなどで、発表する学生の画面を切り替えたりすることを可能にしたい。 -TreeVNC\cite{oc:thesis}\cite{taninari:2012a}は参加したクライアントをバイナリツリー状に接続し、 +画面配信システム TreeVNC\cite{oc:thesis}\cite{taninari:2012a}は参加したクライアントをバイナリツリー状に接続し、 配信コストをクライアントにバランスさせる仕組みになっている。 -そのため、多人数が参加しても処理性能が下がらない。 -また、RFBプロトコルを用いているので、ケーブルの差し替えなしに -共有している画面の切り替えが可能になっている。 +そのため、授業で先生の画面を表示する際、多人数の生徒が参加しても処理性能が下がらない。 + +また、ツリーのルートが参照している VNCサーバーを変更することで、共有する画面の切替が可能となる。 +これはゼミの際に発表者の画面切り替えを円滑に行うための機能で、プロジェクターなどのケーブルの差し替えの手間を省くことが出来る。 本研究では WAN 、マルチディスプレイへの対応を行った。 WANへの対応として、新しい接続方法を提案し、実装を行った。 @@ -91,8 +91,6 @@ VNC(Virtual Network Computing) は、 RFBプロトコルを用いて遠隔操作を行うリモートデスクトップソフトウェアである。 VNC はサーバー側とクライアント(ビューア)側に分かれている。 サーバを起動し、クライアントがサーバに接続を行い遠隔操作を可能とする。 -VNCを使用すればクライアント側にサーバー側の画面を表示することが可能である。 しかし、多人数のクライアントが1つのサーバーに接続してしまうと処理性能が落ちてしまうという問題点がある。 - \subsection{RFBプロトコル} RFB(remote frame buffer)プロトコル\cite{rfbProtocol}とは、自身の画面を送信し、ネットワーク越しに他者の画面に表示するプロトコルである。 ユーザが居る側をRFBクライアント側と呼び、Framebufferへの更新が行われる側はRFBサーバと呼ぶ。 @@ -103,15 +101,22 @@ 更にRFBクライアントのFramebufferUpdateRequestが来るとそれに答え返信する。 RFBプロトコルは、描画データに使われるエンコードが多数用意されており、また独自のエンコードを実装することもできるプロトコルである。 +\subsection{多人数で VNC を使用する時の問題点} +VNCを使用すればクライアント側にサーバー側の画面を表示することが可能である。 +しかし、多人数のクライアントが1つのサーバーに接続してしまうと処理性能が落ちてしまうという問題点がある。 + +また、 ゼミ等の発表で画面配信者が頻繁に切り替わる場合、 +配信者が替わる度にアプリケーションを終了し、接続をし直さないといけないという問題がある。 + \subsection{TreeVNC の構造} TreeVNC は Java を用いて作成された TightVNC(Tight Virtual Network Computing)\cite{tightvnc} を元に作成されている。 -TreeVNC は クライアント同士を接続させ、画面描画のデータを受け取ったクライアントが次のクライアントにデータを流す。 +TreeVNC は クライアント同士を接続させ、画面描画のデータを受け取ったクライアントが次のクライアントにデータを流す方式を取っている。 +また、サーバへ接続しに来たクライアントをバイナリツリー状に接続する(図\ref{fig:tree})。 +バイナリツリー状に接続することで、$N$台のクライアントが接続しに来た場合、画面配信の画像データをコピーする回数は従来の VNC ではサーバ側で$N$回する必要があるが、TreeVNCでは各ノードが2回ずつコピーするだけで済む。 -TreeVNC はサーバへ接続しに来たクライアントをバイナリツリー状に接続する(図\ref{fig:tree})。 -バイナリツリーなら、各nodeに最大2台分のクライアントしか接続されない。 -$N$台のクライアントが接続しに来た場合、画面配信の画像データをコピーする回数は従来の VNC ではサーバ側で$N$回する必要があるが、TreeVNCでは各ノードが2回ずつコピーするだけで済む。 -TreeVNC は ルートへの負荷を各ノードに分散することにより、処理性能が向上している。 +バイナリツリーのルートのノードを Root Node と呼ぶ。 +Root Node は子ノードにデータを流す機能に加え、各ノードの管理と VNC サーバーから流れてきた画像データの管理を行う。 \begin{figure}[ht] \begin{center} @@ -121,18 +126,6 @@ \label{fig:tree} \end{figure} -\subsection{TightVNC} -TightVNC(Tight Virtual Network Computing)\cite{tightvnc}はJavaを用いて作成されたRFBプロトコルのクライアントである。 -本研究で作成したTreeVNCはTightVNCを元に作成されている。 - - - -\subsection{多人数で VNC を使用する時の問題点} -多人数で従来の VNC を使用する際、1つのコンピュータに多人数が同時につながり、 -処理が集中してしまい、性能が大幅に落ちてしまうという問題が生じる。 - -ゼミ等の画面配信者が頻繁に切り替わる場合、 -配信者が替わる度にアプリケーションを終了し、接続をし直さないといけないという問題がある。 \subsection{node 間で行われるメッセージ通信} RFBプロトコルで提供されているメッセージに加え、 TreeVNC 独自のメッセージを使用している。 @@ -176,19 +169,17 @@ \end{table} -図\ref{fig:message}は -TreeVNC で node が root に接続し、画像データを受信するまでのメッセージ通信の様子である。 - -手順として +図\ref{fig:message}は TreeVNC で Node が Root Node に接続し、画像データを受信するまでのメッセージ通信の様子である。 +図 \ref{fig:message}の手順として \begin{itemize} - \item nodeはMulticast通信でrootに対してFIND\_ROOTを送信する(1:findRoot()) - \item rootがFIND\_ROOTを受信し、FIND\_ROOT\_REPLYを送信する(2:findRootReplay()) - \item node側で、どのrootに接続するかを選択するパネルが表示される - \item nodeはパネルで接続するrootを選択し、rootに対して接続先を要求するWHERE\_TO\_CONNECTを送信する(3:whereToConnect()) - \item 受信したrootはnodeの接続先をCONNECT\_TOで送信する(4:connectTo) - \item nodeはrootの指定した接続先に接続しに行く - \item root・node間の接続が確立後、rootからnodeに対して定期的に画像データFRAME\_BUFFER\_UPDATEを送信する(5:framebufferUpdate()) + \item 接続を行う Node (以下 Client Node)はMulticast通信で Root Node に対してFIND\_ROOTを送信する(1:findRoot()) + \item Root NodeがFIND\_ROOTを受信し、FIND\_ROOT\_REPLYを送信する(2:findRootReplay()) + \item Client Node 側で、どのRoot Nodeに接続するかを選択するパネルが表示される + \item Client Node はパネルで接続するRoot Nodeを選択し、Rootに対して接続先を要求するWHERE\_TO\_CONNECTを送信する(3:whereToConnect()) + \item 受信した Root Node は Client Node の接続先をCONNECT\_TOで送信する(4:connectTo) + \item Client Node は Root の指定した接続先に接続しに行く + \item Root Node, Client Node間の接続が確立後、Root Node から Clinet Node に対して定期的に画像データFRAME\_BUFFER\_UPDATEを送信する(5:framebufferUpdate()) \end{itemize} を行っている。 @@ -206,31 +197,23 @@ ゼミでは発表者が順々に入れ替わる。発表者が入れ替わる度に共有する画面の切り替えが必要となる。 ゼミを円滑に進めるために、画面の切り替えをスムーズに行いたい。 -画面の共有にプロジェクタを使用する場合、 -発表者が変わる度にケーブルの抜き差しを行わないとならない。 -その際に、ディスプレイ解像度を設定し直す必要が出たり、 -接続不良が起こる等の煩わしい問題が生じることがある。 +画面の共有にプロジェクタを使用する場合、 発表者が変わる度にケーブルの抜き差しを行う必要がある。 +その際に、ディスプレイ解像度を設定し直す必要が出たり、 接続不良が起こる等の煩わしい問題が生じることがある。 -従来のVNCを使用する場合、 -画面の切り替えの度に一旦VNCを終了し、発表者のVNCServerへと再接続を行う必要がある。 +従来のVNCを使用する場合、 画面の切り替えの度に一旦VNCを終了し、発表者のVNCServerへと再接続を行う必要がある。 TreeVNC は、配信者の切り替えの度に生じる問題を解決している。 -TreeVNC を立ち上げることで、ケーブルを使用する必要なしに、 -各参加者の手元のPCに発表者の画面を共有することができる。 -画面の切り替えは、ユーザがVNCSeverへの再接続を行うことなく、 -share button を押すことによって、配信者の切り替えを行うことができる。 +TreeVNC を立ち上げることで、ケーブルを使用する必要なしに、各参加者の手元のPCに発表者の画面を共有することができる。 +画面の切り替えは、ユーザがVNCSeverへの再接続を行うことなく、ビューワの ``Share Screen'' ボタンを押すことによって、配信者の切り替えを行うことができる。 -TreeVNC の root は配信者の VNCServer と通信を行っている。 -VNCServer から画面データを受信し、そのデータを node へと送信している。 -配信者切り替え時に share button が押されると、 -root は share button を押したクライアントの VNCServer と通信を始める。 -TreeVNCは、配信者切り替えの度に VNC を終了し、再接続する必要がない。 +TreeVNC の Root Node は配信者の VNCServer と通信を行っている。 +VNCServer から画面データを受信し、そのデータを 子 Node へと送信している。 +配信者切り替え時に ``Share Screen'' ボタン が押されると、 +Root Node は ``Share Screen'' ボタン を押したクライアントの VNC サーバー と通信を始める。 +そのためTreeVNCは配信者切り替えの度に VNC を終了し、再接続する必要がない。 -しかし、配信者と受信者の画面サイズの違いや、 -マルチディスプレイ全体を共有してしまう問題があるので、 -それらを解決する必要がある。 - -\section{QUALITYモードとSPEEDモード} +\section{TreeVNCの新機能} +\subsection{QUALITYモードとSPEEDモード} 高解像度のまま拡大・縮小の処理を行うと、 PC のスペックによっては描画処理に時間がかかってしまうことがある。 配信者の画面をリアルタイムに取得するため、 @@ -240,10 +223,10 @@ 高画質優先の QUALITY モードと描画速度優先の SPEED モードがある。 今まで TreeVNC は QUALITY モードで使用していた。 -今回、どちらのモードを使用するかを Viewer から変更出来るようにした。 +今回、どちらのモードを使用するかを ビューワ から変更出来るようにした。 これにより、描画処理の遅延を解決することができた。 -\section{マルチディスプレイ対応} +\subsection{マルチディスプレイ対応} 画面配信側のPCがマルチディスプレイの場合、 VNCServer からは複数の画面全体の画像データが送信されてしまう。 @@ -252,9 +235,9 @@ ディスプレイの情報は個々のクライアントでしか取得ができない。 そのため、配信側は画面の切替を行う際に、ディスプレイを選択し、そのディスプレイの左上と右下の座標を取得する。 -その座標を root への画面切り替えを要求する SERVER\_CHANGE\_REQUEST message に付加させる。 -root は 配信側の VNCServer に画像データを要求する FRAMEBUFFER\_UPDATE\_REPLY message に送信された座標を付加する。 -VNCServer は要求された座標内の画像データを FRAMEBUFFER\_UPDATE message で root に送信する。 +その座標を Root Node への画面切り替えを要求する SERVER\_CHANGE\_REQUEST message に付加させる。 +Root Node は 配信側の VNCServer に画像データを要求する FRAMEBUFFER\_UPDATE\_REPLY message に送信された座標を付加する。 +VNC サーバーは要求された座標内の画像データを FRAMEBUFFER\_UPDATE message で Root Node に送信する。 これにより、一画面のみの表示が可能となる。 図\ref{fig:multidisplay} は Display1 のみを画面共有する例を示している。 @@ -267,7 +250,7 @@ \label{fig:multidisplay} \end{figure} -\section{無線LANへの対応} +\subsection{無線LANへの対応} 授業でTreeVNCを使用する場合、 有線を使用するか否かは学生によって違う。 TreeVNCを有線・無線の両方からの接続に対応したい。 @@ -275,9 +258,7 @@ 従来の TreeVNC は、クライアントの接続する木構造が単一であった。 そのため、単一のネットワークインターフェースでしか使用することができなかった。 -この問題を解決するために、 -図\ref{fig:multinetworktree}の様に、ネットワークインターフェース別に -木構造を形成するように設計した。 +この問題を解決するために、 図\ref{fig:multinetworktree}の様に、ネットワークインターフェース別に 木構造を形成するように設計した。 \begin{figure}[ht] \begin{center} @@ -287,114 +268,111 @@ \label{fig:multinetworktree} \end{figure} -TreeVNC は root が TreeManager というオブジェクトを持っている。 +TreeVNC は Root Node が TreeManager というオブジェクトを持っている。 TreeManager は TreeVNC の接続部分を管理している。 TreeManager では木構造を管理する nodeList が生成される。 -この nodeList を元に、新しい node の接続や、node の切断検出時の接続の切り替え等を行う。 +この nodeList を元に、新しい Client Node の接続や、切断検出時の接続の切り替え等を行う。 -root の保持しているネットワークインタフェース毎に -TreeManager を生成する様に変更した。 - -新しい node が接続してきた際、 interfaces から node のネットワークインタフェースと一致する TreeManager を取得する。 -その TreeManager に、node 接続の処理を任せる。 - +Root Node の保持しているネットワークインタフェース毎にTreeManager を生成する様に変更した。 +新しい Client Node が接続してきた際、 interfaces から Client Node のネットワークインタフェースと一致する TreeManager を取得する。 +その TreeManager に、Client Node 接続の処理を任せる。 こうすることによって、TreeVNC を複数のネットワークインターフェース別に 木構造を構成することができる。 -\section{WANへの対応} +\subsection{WANへの対応} 遠隔地からでもゼミや授業に参加できるよう、 別ネットワークから TreeVNC への接続を可能にした。 図\ref{fig:directConnection} に別ネットワークからの接続を示す。 -別ネットワークからTreeVNCに参加する際、 直接配信側のネットワークの root に接続を行う。 +別ネットワークからTreeVNCに参加する際、 直接配信側のネットワークの Root Node に接続を行う。 この接続を Direct Connection と呼ぶ。 -Direct Connection した node はそのネットワークの root になり、node はそのネットワークの root に接続し、木構造を生成する。 +Direct Connection した Client Node はそのネットワークの Root Node になる。 +そのネットワークの他の Client Node はそのネットワークの Root Node に接続し、木構造を生成する。 -配信側の root は Direct Connection で接続された node に対して Framebuffer Update で 画像データを別ネットワークの node に送信する。 -Framebuffer Update が送信された node はそのネットワークの root であるため、子 node に対して Framebuffer Update を送信する。 +配信側の Root Node は Direct Connection で接続された Root Node に対して Framebuffer Update で 画像データを送信する。 +Framebuffer Update が送信された Root Node は そのネットワークの Client Node に対して Framebuffer Update を送信する。 これにより、別ネットワークでの画面共有が可能となる。 \begin{figure}[ht] \begin{center} \includegraphics[width=80mm]{./pic/directConnection.pdf} - \caption{遠隔地 node からの接続} + \caption{遠隔地 Node からの接続} \label{fig:directConnection} \end{center} \end{figure} -\section{評価} -\subsection{木の深さによるメッセージ伝達の遅延} -VNCServer から受信する画像データ、 -TreeVNC で扱われるメッセージ通信は構成された木を伝って伝達される。 -接続する人数が増える毎に木の段数は増えていく。 -そこで root から木の末端の node まで、 -メッセージが遅延することなく伝達できているかを検証する実験を行った。 - +\section{TreeVNC の評価} +\subsection{木の深さによる画像データ伝達の遅延} +VNCサーバー から受信する画像データ、 TreeVNC で扱われるメッセージ通信は構成された木を伝って伝達される。 +接続する人数が増える毎に木の段数は増えていく。 そこで Root Node から木の末端の Clinet Node までの画像データ伝達の遅延を検証する実験を行った。 \subsection{実験環境} 授業を受講している学生が TreeVNC を使用した状態で実験を行った。 -TreeVNC には最大で34名が接続していた。 +TreeVNC には最大で17名が接続していた。 -\subsection*{メッセージを使用した実測} +\subsection{メッセージを使用した実測} TreeVNC を伝搬するメッセージに、CHECK\_DELAY・CHECK\_DELAY\_REPLY を追加した。 -CHECK\_DELAY は root から node の末端まで伝達するメッセージ(図\ref{fig:checkdelay}, 左)、 -CHECK\_DELAY\_REPLY は各 node から root まで伝達するメッセージ(図\ref{fig:checkdelay}, 右)である。 +CHECK\_DELAY は Root Node から 末端の Client Node まで伝達するメッセージと画像データ (図\ref{fig:checkdelay}, 左)、 +CHECK\_DELAY\_REPLY は各 Client Node から Root Node まで伝達するメッセージ(図\ref{fig:checkdelay}, 右)である。 \begin{figure}[ht] \begin{center} - \includegraphics[width=70mm]{./pic/checkDelay.pdf} + \includegraphics[width=80mm]{./pic/checkDelay.pdf} \end{center} \caption{CHECH\_DELAY, CHECK\_DELAY\_REPLY} \label{fig:checkdelay} \end{figure} -CHECK\_DELAY message は、送信時刻を付けて送信する。 -root から CHECK\_DELAY 送信し、 -末端 node まで各 node を伝いながら伝達して行く。 - -CHECK\_DELAY\_REPLY には CHECK\_DELAY から受け取った送信時刻をそのまま付つけて送信する。 -CHECK\_DELAY を受け取った各 node は CHECK\_DELAY\_REPLY を接続している親 node に送信する。 +CHECK\_DELAY メッセージは送信時刻を付けて送信する。 +Root Nodeから CHECK\_DELAY 送信し、末端の Client Node まで各 Node を伝いながら伝達して行く。 -CHECK\_DELAY\_REPLY を受け取った root は、 -メッセージの伝達にどれだけの時間がかかったかを計算する。 +CHECK\_DELAY\_REPLY には CHECK\_DELAY から受け取った送信時刻に画像データのサイズを付けて送信する。 +CHECK\_DELAY を受け取った各 Client Node は CHECK\_DELAY\_REPLY を接続している親 Node に送信する。 -計算方法を以下のソースコード\ref{calc}に記述する。 -各 node にデータを下ろす際も、root にデータが上る際も、 -木を伝い受け渡されている。 -そのため、データが root から末端 node に伝わる時間は、 -CHECK\_DELAY を送信した時間と、 -CHECK\_DELAY\_REPLY を受信した時間の半分であるといえる。 +CHECK\_DELAY\_REPLY を受け取った Root Node はメッセージと画像データの伝達にどれだけの時間がかかったかを計算する。 +データ計算方法を以下のソースコード\ref{calc}に記述する。 この変数``time''は CHECK\_DELAY\_REPLY に付いている送信時刻である。 \begin{table}[htb] -\begin{lstlisting}[label=calc, caption=遅延時間の計算方法] -Long delay = System.currentTimeMillis() - time; -double halfDelay = (double) delay / 2; -\end{lstlisting} + \begin{lstlisting}[label=calc, caption=遅延時間の計算方法] + Long delay = System.currentTimeMillis() - time; + \end{lstlisting} \end{table} -\subsection*{[depth毎の遅延結果]} -バイナリツリーで木を構成した場合、 -node 数が34台だと深さが5となる。 -各木構造の階層毎に、メッセージの伝搬にかかった時間を測定した。 +\subsection{depth毎の遅延結果} +バイナリツリーで木を構成した場合、 Node 数が17台だと深さが4となる。 +各木構造の階層毎に、画像データの伝搬にかかった時間を測定した。 + +図\ref{fig:depth}は遅延の分布を示した散布図である。 +X軸はメッセージ伝達にかかった秒数(ms)、 Y軸は画像データのサイズ(Byte)である。 + -図\ref{fig:test}は遅延の分布を示したヒストグラムである。 -X軸はメッセージ伝達にかかった秒数(ms)、 -Y軸は CHECK\_DELAY\_REPLY を送信した node の割合を表している。 +- 大体1秒以内 + +- 大容量の画像の送信の後のDelayが残っているため、容量が小さいとこでも時間がかかる場合がある + +- Depth3に極端に遅い場合がある → １つのnodeがネックになっている + +- 極端に遅いやつを下に持っていくアルゴリズムが必要(これはまとめにも書く) -ほとんどのメッセージの伝達は 0.0 〜 4.0 ミリ秒内に収まっている。 -木の段数毎に、メッセージ伝達速度の差が生じている。 -深い段数の node ほど、メッセージ伝達速度が落ちている。 - -\begin{figure}[h] +\begin{figure}[ht] + \begin{center} + \includegraphics[width=70mm]{./pic/depth1.eps} + \end{center} + \begin{center} + \includegraphics[width=70mm]{./pic/depth2.eps} + \end{center} \begin{center} - \includegraphics[width=70mm]{./pic/test.pdf} + \includegraphics[width=70mm]{./pic/depth3.eps} \end{center} - \caption{遅延の分布} - \label{fig:test} + \begin{center} + \includegraphics[width=70mm]{./pic/depth4.eps} + \end{center} + \caption{深さ毎のデータサイズと遅延の関係} + \label{fig:depth} \end{figure} \section{まとめ} @@ -410,10 +388,14 @@ それを防ぐために share button が押されるとその時の配信者に切り替え確認を行う処理を追加する。 今回追加した Direct Connection などの一部の機能はコマンドラインオプションで指定する必要があるため、一般ユーザーでは操作するのが困難である。 -そこで、 今までコマンドラインオプションで指定していた機能を Viewer で操作するように変更を行う。 +そこで、 今までコマンドラインオプションで指定していた機能を ビューワ で操作するように変更を行う。 共有機能の追加としては、音声、講義中の質問・意見 等が挙げられる。 +- 新機能の評価方法、評価 + +- 極端に遅いやつを下に持っていくアルゴリズム + \nocite{*} \bibliographystyle{ipsjunsrt} \bibliography{prosym} diff -r 6daaf5e03e4d -r aaa9a0f50d3f prosym.mm --- a/prosym.mm Sat Nov 28 19:52:32 2015 +0900 +++ b/prosym.mm Sun Nov 29 19:16:17 2015 +0900 @@ -2,58 +2,164 @@ - + - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - + + + + + + + + + + + + + + + + + + + + - - - - + + - - + + - - + + + + + - - - - + + + + + + - - - - - + + - + + + + + + + @@ -72,9 +178,15 @@ - + + + + + - + + + @@ -83,16 +195,17 @@ - - + + + + - - - + + @@ -100,11 +213,29 @@ - + + + + + + + + + + + + + + + + + + +