トポロジ構築最適化機構の評価

!

"#

$

46:6*,/;0<2)45=78+

>

?6@,AB1CED,F1G,H I=J'K#L6I'MN

I=J'K#L6I'MNI=J'K#L6I'MN I=J'K#L6I'MN

OPQ$R OPQ$R OPQ$R OPQ$RSS SS

T$U T$U T$U T$U

図 5.3: 内部転送処理遅延評価個所 評価結果

外部送信処理遅延の送信回数と処理平均時間の結果を図 5.4に、標準偏差を図 5.5 に示す。

送信する端末台数が増加するにつれ処理時間がかかり、且つ送信するタイミングに ばらつきが出ることがわかる。一般的FPSの体感許容遅延200ミリ秒程度である。ま たQuake2と同ジャンルであるCounter-Strike [35]のネットワーク片道遅延が50〜150 ミリ秒に集中することを考慮すると、単一の端末で許容できる送信処理遅延は30〜40 ミリ秒程度であると考慮でき、これよりプロトタイプでは500台程度までが規模の限 界である。

!"

!"

!"

!"#

$%

&#

$%&#

$%

&#

$%

&'

(

!"

)*

'

(!")*'

(

!"

)*

'

(!")*++ ++,-,-,-,-

++,-,-,-,-.. ++,-,-,-,-..// //

図 5.4: メッセージ外部送信処理遅延平均値

遅延報告機能・経路最適化機能を有する。そして2種類の評価用アプリケーションを 作成し評価を行った。アプリケーションは平面上でアバタが動き、移動毎にその座標 が各ユーザにUDPで送られるプログラムである。アバタの移動はスクリプトにて自 動で行い全ての実験において同じ動きになるようにした。評価用アプリケーションの 画面を図 5.7に示す。

また評価用の2種類のアプリケーションの違いを下記に示す。

• メッシュ接続型P2Pアバタ移動アプリケーション(メッシュ型)

トポロジ参加時に全てのユーザとアプリケーションレベルで直接メッセージを送 受信する。ネットワークトポロジがフルメッシュになる。

• 最適化機能内蔵P2Pアバタ移動アプリケーション(最適化内蔵型)

トポロジ参加時に全てのユーザと直接メッセージを送受信し始めるが送受信API に最適化機能を使用しており、原理に基づき遅延とメッセージ損失率を監視し、

経路切り替えを行う。尚、今回はマスタノードが事前に決められており、アプリ ケーション起動後他の端末はマスタノードである端末に向けて遅延報告を行う。

上記2種類の評価用アプリケーションは送受信API以外を全て同一のコードを利用 した。また評価時の動作を公平にするため、アバタの操作をスクリプトで記述するこ とで自動化し、同一の移動パターンに統一した。そして各ノードの遅延計測メッセー ジを送信する間隔を100ミリ秒から1000ミリ秒まで変化させ各計測間隔ごとに15回 ずつ計測し平均値を算出した。1回の計測で行った時間は実際に短時間で遊ぶゲーム を想定し、10分とした。

!

"#

!"# !

"#

!"#$

%&

'$

%&'$

%&

'$

%&'()*+()*+()*+()*+

図 5.5: メッセージ外部送信処理遅延標準偏差

評価で利用した各設定値について述べる。各ノードの遅延報告間隔を5回、マスタ ノードにおける経路探索間隔の回数も5回毎に設定した。またマスタノードでの経路 最適化アルゴリズムにおける切り替え判断の閾値として遅延が200ミリ秒またはメッ セージ損失率が50 %を超えた場合に経路を切り替えるよう定めた。

評価軸

評価は経路収束時間と制御通信増加量について行う。経路収束時間とは本最適化機 能が遅延計測に基づき、より最短の経路を発見し経路切り替えメッセージがマスタノー ドで発行されたときの時間とする。また制御通信増加量は評価用アプリケーションに おいてメッシュ型に対する最適化内蔵型の受信データ量増加率を量った。受信データ 量は3台で計測し合計の差を求めている。

評価結果

経路収束時間の結果を図 5.8に示す。横軸が各ノードが遅延計測を行う遅延計測間 隔であり、縦軸がマスタノードにて経路切り替え命令が発行された経路収束時間であ る。前述した評価環境から予測できるように、およそ遅延計測間隔×遅延報告間隔か ら算出される時間で経路の切り替えメッセージが発行された。

また今回計測した環境では計測間隔1秒時において経路収束時間がが最高約5秒半 となる。主要FPSクライアントのゲーム参加時間を1週間に渡って計測したChangら の研究では、平均接続時間が15から30分であると述べている[9]。このことから5秒

!#"%$'&)(

* +,

* +,

* +,

* +,

図 5.6: 評価環境とANGEL適応図

図 5.7: 評価アプリケーション画面

半は割合として微小であり、ゲーム中の大半の時間は最適化された状態で進められる と判断する。

次に制御通信増加率のグラフを図 5.9に示す。横軸は上記同様各ノードの遅延計測 間隔であり、縦軸はメッシュ型アプリケーションに対する最適化内蔵型の通信量の増 加率を示す制御通信増加率である。通信量は計測間隔が1秒の時に最大で11 %増加す る。しかし今回のサンプルアプリケーションではユーザ1人あたり毎秒約1500バイト のデータを送信しており、人気FPSであるCounter-Strike では毎秒約3200バイト送 信することが分かっている [10]。そのため一般的ネットワークゲームに本機能を採用 した場合、本機能の制御通信増加率の割合はより抑えられると予測する。