P2P でマルチプレイヤ・ゲームを行うには : 理想と現実

1. P2Pでマルチプレイヤ・ゲームを行うには:理想と現実P2Pでマルチプレイヤ・ゲームを行うには:理想と現実 飯村 卓司

2. 自己紹介 • 電通大出身です • 大学にはかなり長い間在籍しました • どうやったら長期間在籍できるかは別途ご相談を • NAIST • 奈良先端科学技術大学院大学と長い名前 • 現在修士2年 • NAIST良いトコ一度はおいで • ゲームゲームと浮ついたことを言っていてもちゃんと研究として認めてくれ… ていると信じています

3. ネットワーク・ゲーム 一言でネットワーク・ゲームといってもいろいろあります • １人～10人程度まで • ルーレット、囲碁、オセロ、麻雀 主にすばやい動作の必要ないもの • 数人～数十人、百人程度まで • FPS、RTS 主にすばやい動作が必要なもの • 数百人～数千、数万人 • RPG、アバター(チャット) 主に多人数ということに重点を置き、他人とのかかわりを重視するもの ネットワーク・ゲームのうち、複数人が同時に遊ぶものをMulti-player Online Game (MOG)と呼びます

4. MOGをとりまく諸所の単語 • ゲームの種類 • テーブル, FPS, RTS, RPG, アバター • 課金方法 • 一ヶ月固定料金、アイテム課金 • サーバの運用形態 • マッチング・サーバ、中央集権サーバ • 外部との連携 • オフライン・イベント、ピザの宅配、メッセンジャ

5. １ユーザの立場から…サーバがあると困るんです１ユーザの立場から…サーバがあると困るんです • 今までのゲーム • ゲーム機、ソフト、オプションの全てを買うことができた • ネットワーク・ゲーム • ゲーム機、ソフト、オプションは買えても、サーバは買えないことが多い だから、サーバがなくなると 遊べなくなってしまうんです ぶっちゃけ鉄騎大戦のサービスがいつ終わるかと戦々恐々なんです

6. サーバがなくなると、何が起こる？ • マッチング・サーバ形式 • ゲームの進行はユーザ・ノードで行うので、ゲームを続けることができる • サーバの管理していたデータは消える • 中央集権サーバ形式 • ゲームの進行役がいなくなるので、ゲームの続行が不可能 ゲームの進行役が居なくなることと、データが消えることが問題 ・ゲームの進行役をサーバにやらせてはいけない ・ゲームのデータをサーバに持たせてはいけない

7. サーバをなくそう！ サーバがなくなってもユーザ・ノードはなくならない 何故なら、ゲームを遊ぶためには遊ぶ人、即ち ユーザ・ノードが必要だから。 ゲームの進行役もデータの保管も ユーザ・ノードで行う 要するにP2P 最近のゲーム用PCやゲーム機は能力高いものが多いので なんとかなるかも とりあえずやってみよう！

8. 当面の目標と解決策 目標 ゲーム進行を妨げる要因を中央集権化させない • 消滅することでゲーム進行を妨げる要因 • ゲームの進行役 • データの消滅 • 消滅することでゲーム進行を妨げない要因 • ユーザへの課金 ゲームの進行役とデータの消滅を救う

9. 大まかに考えると • ゲーム進行役の分散 • データを分割することでのサーバ機能の分散 • ゲームのルールを知っているノードによる管理 その他に必要な事 • 応答性の重視 • データ消滅への対策 • 複数のノードで保持しあう

10. ゲームワールド全体 Zone W Zone X X W Y V Zone Z Z Zone Y Zone V 提案: Zoned Federation Model • (1)サーバ機能の分散 • 局所性と構造を元にデータを分割 • Zone • (2)分割されたデータの一貫性保持 • 調停ノードの導入 • Zone owner • (3)応答性の維持 • 調停ノードとデータ要求ノードの直接接続 • (4)データの保管 • データの管理と保管を分離 • DHTを用いてデータ保管

11. (1)サーバ機能の分散 局所性と構造に着目 • データおける局所性:あるノードの用いるデータは全体の一部 • 全体の一部のデータのみを把握することでゲーム世界の共有が可能 • サーバ機能はデータを単位として分割可能 • ゲームにおけるデータの構造 • 座標、方向、数、状態など様々 • ある程度の関連性を持つ • 関連性を基にした分割 • 柔軟な分割単位の指定 • 文字列による分割単位へのアクセス Zone:データ分割の単位 Game Map MapA 川の場所 町の場所 MapB 森の場所 村の場所 プレイヤの現在地 プレイヤA プレイヤB ログイン情報

12. (2)分割されたデータの一貫性保持 ゲーム進行に伴う各Zoneのデータの変更が生じる。各ゲーム参加ノードがデータの変更を要求する。 調停ノードが必要 • 各分割単位（Zone）ごとに一つの管理ノードが必要 • 調停ノードがゲームのルールを知っている必要がある • ゲーム参加ノードが管理ノードを行う

13. Zoneの分割統治 • データ管理ノードの決定 • 指名制 • ゲーム参加ノードの事前登録 • 指名のための複雑化 • 立候補制 • ゲーム参加ノードのみが立候補 • 指名部分を分離による単純化 • 本提案では立候補制を選択 • インフラが複雑化することを避ける

14. (3)応答性の維持 • ゲームは応答性に敏感 • 200ms以下での応答性が必要 • 人間がストレスを感じる • クライアント・サーバ形での実現手法 • クライアントとサーバを直接接続する • 中継ノードを介さない • 本提案での実現手法 • 調停ノードとデータを必要とするノードを直接接続する • クライアント・サーバ形と同程度の応答性を確保

15. ゲーム(データ管理) ゲームA ゲームB ゲームC DHT データ保管 (4)データの保管 • データの保管とデータの管理を分割 • データの保管にデータの管理能力は必要ない • 複数ゲームでのデータ保管 • Distributed Hash Table (DHT) の利用 • DHT • 複数のノードでハッシュ表を共有 • 検索に対してO(log N)のノードを経由することで検索可能 • ZoneをHash Keyとする • Zoneに関係するデータを全て保存 • データ管理ノードの決定 • データ要求ノードの登録 • Zoneのデータの記録

16. Game Program libcookai Pastry Network ちょっと宣伝・・・現在できている実装 • libcookai • ライブラリとして提供 • C言語にて実装 • 動作確認済みプラットホーム • NetBSD- (1.6, 2.0*) • FreeBSD-4.*/ -5.* • Vine Linux 2.6 • Sun OS 5.8 • Mac OS X • http://libcookai.sourceforge.net • DHT • オンラインゲームに特化させたPastry実装 • C言語にて実装 • Hash関数としてSHA-1を使用 • 破られたというけれど大丈夫？ • PastryはMS lab. だけどパテント大丈夫？ • DHTであれば良いのでDHT層は分離可能 • Distributed Rally-X • サンプル実装

17. 問題点 サーバ機能をユーザ・ノードへと分散した時の問題 • 悪意のあるノード • データの改竄 • チート • 個人情報など取り扱い注意データの管理 • 不正を行ったノードの排除 • お金の取らせ方 • 課金情報の管理 • いろいろな課金方法 • ゲーム参加ノードの一定量確保 • 遊んでいる人の数が減った場合のデータ保管 • サーバ機能の分離による問題 • 課金無しで遊べてしまう可能性 • ベンダの手を離れたゲームをベンダは許すのか • ゲーム特有の問題 • 速度の確保

18. 悪意のあるノードの問題(1) • データ改竄、チート • 中継ノードによる攻撃 主にDHT層での攻撃 • 接続したノードそのものからの攻撃 主に調停ノードとデータを必要とするノードの間での攻撃 • 対策 • 相対的に多い(であろう)善意のノードによる監視 • 多数決論理での排除 • 機械的判定 • 人間による判定 • 善意のノードのふりをする悪意のあるノード群からの攻撃に弱い • ゲームベンダなどによる抜き打ち検査 • 特権ノードを用いての排除 • 抜き打ち検査用に作業logを記録/報告 • ゲームベンダがサポートをやめたときの問題の再発 • その他の対策 • 複数の経路を使っての防御 • 完全な乱数とXORしたデータの二つを複数経路を用いて送信 • データ保管ノードを複数のDHTを用いて検索

19. 悪意のあるノードの問題(2) • 個人情報など取り扱い注意データの管理 • 自由に検索できることによる問題 • どこまでが取り扱い注意の個人情報なのか • 課金情報 • 友達情報 • ハイスコア、個人所有のキャラクタ 対策 • 自由に検索できなくする • 取り扱い注意データ用サーバの導入 • 課金情報などの管理 • 対象鍵暗号などでの個人情報の隠蔽 • 暗号鍵を所持している者が接続することで解除 • 手元に持っていることと同じ • 実は無意味

20. 悪意のあるノードの問題(3) • 不正を行ったノードの排除 • DHTオーバレイからの排除 • 接続時に判定 • 一時的なIPアドレスによる規制 • ユーザ名とパスワードの組などでのログインによる規制 • 発見次第排除

21. お金の取らせ方 お金を稼げないと企業は参入しない • 課金情報の管理 • 個人情報保管問題とかぶる • 課金サーバの導入 • お金はベンダによるサービスに対する対価 • GMによる監視 • ベンダ主導イベント • 新規要素の追加 無くても(一応)ゲームの続行は可能か？ • いろいろな課金方法のサポート • 月額課金 • 接続時に認証 • アイテム課金 • 課金を行った者のみが使うことのできるデータ • 個々のデータそれぞれに対して認証が必要 データを分割している場合、個々のデータに対する認証はコスト高 • 認証を行うデータの保管場所 • 暗号化などをしない場合は認証されたノードにしかデータを置けない • 暗号化をしても不安だとすれば、サーバを用意するしかない？

22. ゲーム参加ノードの一定量確保 • 遊んでいる人の数とデータ保管は反比例 • プレイ人口の変化 • 一日の変化 夜は多いけれど朝には減る • 時間のたつにつれて減少するプレイ人口 さすがに10年も経ってしまったゲームは…… • 対策 • データ保存期間の設定 • 保存する期間の違うデータのサポート(重要なデータはできるだけ取っておくように) • お金を払った人のデータは優先して残す • 保存期間とユーザ数に対する保存量の比率によるデータ削除 • ひとつのノードが保持するデータ量を一定量までにする(うまく分散させる必要がある。特にノード数が減った場合) • データ保管のみを行うサービス • データの保管のみであることから、ゲームベンダである必要は無いISPなどによるデータ保管サービス

23. ユーザ ゲームベンダ ISP マネジメント コンテンツ コンテンツ サーバ ストレージ サーバ AAA サーバ CPU サーバ ISPも巻き込んだ運用形態 ネットワーク 回線の提供 アカウント管理 新しいイベントや ゲームの提供 ゲームプレイヤ CPU資源 ストレージ資源 バックアップ 耐障害性の確保

24. サーバ機能の分離による問題 • 課金無しで遊べてしまう可能性 クライアントのみ入手すればユーザ・ノードだけで遊ぶことができる • ゲーム本体の販売での売り上げ既存のコピーソフトの問題と同じ問題を抱える • ネットワークを用いた認証はしやすい • サービスの充実によるユーザの引きとめ • ベンダ主導イベント • 新要素の定期的な配信 • ベンダの手を離れたゲームをベンダは許すのか • これを許してもらわないことには話を続けられない？ • ベンダ不在による管理不能状態 • 不正防止パッチのサポート停止

25. その他の問題 • ゲーム特有の問題 • 速度を確保しなければならない • PKIを使っての認証は時間がかかる • 問題はサーバをなくすだけで解決するのか • サービスの停止には怯えるのだろうか • 問題の本質は別のところにあったりはしないか • P2P的問題 • 初期ノード問題、NAT越え

26. 問題点のまとめ • 問題山積みです • P2Pにすることによる問題 • 悪意のあるノード • 取り扱い注意データ • ユーザ数の減少 • ベンダの存在による問題 • 課金 • サーバレスを許さないベンダ • ゲーム特有の問題 • 速度を確保しようとするとPKIは大変カモ • 問題はサーバ機能の分散で解決したのか？ • 結局サービスの停止に怯えるのではないだろうか • けれど、(一応)遊び続けることはできそうだ

27. 未来像 • 地球の裏側のノードが昼間のゲーム人口減少を支える？ • データがノードを追って地球をぐるぐると移動していく… • 複数ゲームの同じネットワーク・ゲーム・プラットホームの使用 • ゲーム間での情報共有が容易に • 同タイトルの新版へのデータ移行 • EverQuestとEverQuest2の間で～ • 別タイトルでのデータ共有 • ポケモンなんたらとピカチュウなんたらの間で～ ゲーム人口の特定ゲームへの固定化を避ける • 作り捨てMOGの発生 • アップデートなどが無い、長期のサポートが無い • ゲーム以外との情報共有 • IM (now playing TEKKI TAISEN) • ピザ宅配 いろいろ考えて！そろそろ新しいMOGがほしいよ！

28. 時間の許す限りディスカッション 意見募集！ 名刺忘れました。takuji-i@is.naist.jpをメモって頂けるとうれしいです せっかく作ったのにー