P2Pでマルチプレイヤ・ゲームを行うには: 理想と現実飯村卓司 1 自己紹介 • 電通大出身です – 大学にはかなり長い間在籍しました • どうやったら長期間在籍できるかは別途ご相談を • NAIST – 奈良先端科学技術大学院大学と長い名前 – 現在修士2年 – NAIST良いトコ一度はおいで • ゲームゲームと浮ついたことを言っていてもちゃんと研究として認めてくれ… ていると信じています 2 ネットワーク・ゲーム一言でネットワーク・ゲームといってもいろいろあります – １人～10人程度まで • ルーレット、囲碁、オセロ、麻雀主にすばやい動作の必要ないもの – 数人～数十人、百人程度まで • FPS、RTS 主にすばやい動作が必要なもの – 数百人～数千、数万人 • RPG、アバター(チャット) 主に多人数ということに重点を置き、他人とのかかわりを重視するものネットワーク・ゲームのうち、複数人が同時に遊ぶものを Multi-player Online Game (MOG)と呼びます 3 MOGをとりまく諸所の単語 • ゲームの種類 – テーブル, FPS, RTS, RPG, アバター • 課金方法 – 一ヶ月固定料金、アイテム課金 • サーバの運用形態 – マッチング・サーバ、中央集権サーバ • 外部との連携 – オフライン・イベント、ピザの宅配、メッセンジャ 4 １ユーザの立場から… サーバがあると困るんです • 今までのゲーム – ゲーム機、ソフト、オプションの全てを買うことができた • ネットワーク・ゲーム – ゲーム機、ソフト、オプションは買えても、サーバは買えないことが多いだから、サーバがなくなると遊べなくなってしまうんです 5 ぶっちゃけ鉄騎大戦のサービスがいつ終わるかと戦々恐々なんですサーバがなくなると、何が起こる？ • マッチング・サーバ形式 – ゲームの進行はユーザ・ノードで行うので、ゲームを続けることができる – サーバの管理していたデータは消える • 中央集権サーバ形式 – ゲームの進行役がいなくなるので、ゲームの続行が不可能ゲームの進行役が居なくなることと、データが消えることが問題・ゲームの進行役をサーバにやらせてはいけない・ゲームのデータをサーバに持たせてはいけない 6 サーバをなくそう！サーバがなくなってもユーザ・ノードはなくならない何故なら、ゲームを遊ぶためには遊ぶ人、即ちユーザ・ノードが必要だから。ゲームの進行役もデータの保管もユーザ・ノードで行う要するにP2P 最近のゲーム用PCやゲーム機は能力高いものが多いのでなんとかなるかもとりあえずやってみよう！ 7 当面の目標と解決策目標ゲーム進行を妨げる要因を中央集権化させない – 消滅することでゲーム進行を妨げる要因 • ゲームの進行役 • データの消滅 – 消滅することでゲーム進行を妨げない要因 • ユーザへの課金ゲームの進行役とデータの消滅を救う 8 大まかに考えると • ゲーム進行役の分散 – データを分割することでのサーバ機能の分散 – ゲームのルールを知っているノードによる管理その他に必要な事 • 応答性の重視 • データ消滅への対策 – 複数のノードで保持しあう 9 提案: Zoned Federation Model • (1)サーバ機能の分散 – 局所性と構造を元にデータを分割 – Zone ゲームワールド全体 Zone X Zone W X • (2)分割されたデータの一貫性保持 W – 調停ノードの導入 – Zone owner Y • (3)応答性の維持 – 調停ノードとデータ要求ノードの直接接続 • (4)データの保管 – データの管理と保管を分離 – DHTを用いてデータ保管 Zone Z Z V Zone V Zone Y 10 (1)サーバ機能の分散局所性と構造に着目 • データおける局所性:あるノードの用いるデータは全体の一部 – 全体の一部のデータのみを把握することでゲーム世界の共有が可能 – サーバ機能はデータを単位として分割可能 • ゲームにおけるデータの構造 – 座標、方向、数、状態など様々 – ある程度の関連性を持つ Game MapA 川の場所町の場所 MapB 森の場所村の場所プレイヤの現在地プレイヤA プレイヤB Map • 関連性を基にした分割 – 柔軟な分割単位の指定 • 文字列による分割単位へのアクセス Zone:データ分割の単位ログイン情報 11 (2)分割されたデータの一貫性保持ゲーム進行に伴う各Zoneのデータの変更が生じる。各ゲーム参加ノードがデータの変更を要求する。調停ノードが必要 – 各分割単位（Zone）ごとに一つの管理ノードが必要 – 調停ノードがゲームのルールを知っている必要がある • ゲーム参加ノードが管理ノードを行う 12 Zoneの分割統治 • データ管理ノードの決定 – 指名制 • ゲーム参加ノードの事前登録 • 指名のための複雑化 – 立候補制 • ゲーム参加ノードのみが立候補 • 指名部分を分離による単純化 • 本提案では立候補制を選択 – インフラが複雑化することを避ける 13 (3)応答性の維持 • ゲームは応答性に敏感 – 200ms以下での応答性が必要 • 人間がストレスを感じる • クライアント・サーバ形での実現手法 – クライアントとサーバを直接接続する • 中継ノードを介さない • 本提案での実現手法 – 調停ノードとデータを必要とするノードを直接接続する – クライアント・サーバ形と同程度の応答性を確保 14 (4)データの保管 • データの保管とデータの管理を分割 – データの保管にデータの管理能力は必要ない – 複数ゲームでのデータ保管 • Distributed Hash Table (DHT) の利用 – DHT • 複数のノードでハッシュ表を共有 • 検索に対してO(log N)のノードを経由することで検索可能ゲーム(データ管理) ゲームA ゲームB ゲームC – ZoneをHash Keyとする – Zoneに関係するデータを全て保存 • データ管理ノードの決定 • データ要求ノードの登録 • Zoneのデータの記録 DHT データ保管 15 ちょっと宣伝・・・現在できている実装 • libcookai – ライブラリとして提供 • C言語にて実装 Game Program – 動作確認済みプラットホーム • • • • • NetBSD- (1.6, 2.0*) FreeBSD-4.*/ -5.* Vine Linux 2.6 Sun OS 5.8 Mac OS X – http://libcookai.sourceforge.net • Pastry libcookai Network DHT – オンラインゲームに特化させたPastry実装 • C言語にて実装 • Hash関数としてSHA-1を使用 – 破られたというけれど大丈夫？ • PastryはMS lab. だけどパテント大丈夫？ – DHTであれば良いのでDHT層は分離可能 • Distributed Rally-X – サンプル実装 16 問題点サーバ機能をユーザ・ノードへと分散した時の問題 – 悪意のあるノード • • • • データの改竄チート個人情報など取り扱い注意データの管理不正を行ったノードの排除 • お金の取らせ方 – 課金情報の管理 – いろいろな課金方法 • ゲーム参加ノードの一定量確保 – 遊んでいる人の数が減った場合のデータ保管 • サーバ機能の分離による問題 – 課金無しで遊べてしまう可能性 – ベンダの手を離れたゲームをベンダは許すのか • ゲーム特有の問題 – 速度の確保 17 悪意のあるノードの問題(1) • データ改竄、チート – 中継ノードによる攻撃主にDHT層での攻撃 – 接続したノードそのものからの攻撃主に調停ノードとデータを必要とするノードの間での攻撃 • 対策 – 相対的に多い(であろう)善意のノードによる監視 • 多数決論理での排除 – 機械的判定 – 人間による判定 • 善意のノードのふりをする悪意のあるノード群からの攻撃に弱い – ゲームベンダなどによる抜き打ち検査 • 特権ノードを用いての排除 – 抜き打ち検査用に作業logを記録/報告 • ゲームベンダがサポートをやめたときの問題の再発 – その他の対策 • 複数の経路を使っての防御 – 完全な乱数とXORしたデータの二つを複数経路を用いて送信 – データ保管ノードを複数のDHTを用いて検索 18 悪意のあるノードの問題(2) • 個人情報など取り扱い注意データの管理 – 自由に検索できることによる問題 – どこまでが取り扱い注意の個人情報なのか • 課金情報 • 友達情報 • ハイスコア、個人所有のキャラクタ対策 • 自由に検索できなくする • 取り扱い注意データ用サーバの導入 – 課金情報などの管理 • 対象鍵暗号などでの個人情報の隠蔽 – 暗号鍵を所持している者が接続することで解除 – 手元に持っていることと同じ – 実は無意味 19 悪意のあるノードの問題(3) • 不正を行ったノードの排除 – DHTオーバレイからの排除 • 接続時に判定 – 一時的なIPアドレスによる規制 – ユーザ名とパスワードの組などでのログインによる規制 • 発見次第排除 20 お金の取らせ方お金を稼げないと企業は参入しない • 課金情報の管理 – 個人情報保管問題とかぶる • 課金サーバの導入 – お金はベンダによるサービスに対する対価 • GMによる監視 • ベンダ主導イベント • 新規要素の追加無くても(一応)ゲームの続行は可能か？ • いろいろな課金方法のサポート – 月額課金 • 接続時に認証 – アイテム課金 • 課金を行った者のみが使うことのできるデータ • 個々のデータそれぞれに対して認証が必要データを分割している場合、個々のデータに対する認証はコスト高 • 認証を行うデータの保管場所 – 暗号化などをしない場合は認証されたノードにしかデータを置けない – 暗号化をしても不安だとすれば、サーバを用意するしかない？ 21 ゲーム参加ノードの一定量確保 • 遊んでいる人の数とデータ保管は反比例 – プレイ人口の変化 • 一日の変化夜は多いけれど朝には減る • 時間のたつにつれて減少するプレイ人口さすがに10年も経ってしまったゲームは…… – 対策 • データ保存期間の設定 – 保存する期間の違うデータのサポート (重要なデータはできるだけ取っておくように) – お金を払った人のデータは優先して残す • 保存期間とユーザ数に対する保存量の比率によるデータ削除 – ひとつのノードが保持するデータ量を一定量までにする (うまく分散させる必要がある。特にノード数が減った場合) • データ保管のみを行うサービス – データの保管のみであることから、ゲームベンダである必要は無い 22 ISPなどによるデータ保管サービス ISPも巻き込んだ運用形態ユーザゲームベンダ ISP ネットワーク回線の提供マネジメント AAA サーバアカウント管理コンテンツコンテンツサーバゲームプレイヤ新しいイベントやゲームの提供バックアップ CPU資源ストレージ資源ストレージサーバ CPU サーバ耐障害性の確保 23 サーバ機能の分離による問題 • 課金無しで遊べてしまう可能性クライアントのみ入手すればユーザ・ノードだけで遊ぶことができる • ゲーム本体の販売での売り上げ既存のコピーソフトの問題と同じ問題を抱える – ネットワークを用いた認証はしやすい • サービスの充実によるユーザの引きとめ – ベンダ主導イベント – 新要素の定期的な配信 • ベンダの手を離れたゲームをベンダは許すのか – これを許してもらわないことには話を続けられない？ – ベンダ不在による管理不能状態 • 不正防止パッチのサポート停止 24 その他の問題 • ゲーム特有の問題 – 速度を確保しなければならない • PKIを使っての認証は時間がかかる • 問題はサーバをなくすだけで解決するのか – サービスの停止には怯えるのだろうか – 問題の本質は別のところにあったりはしないか • P2P的問題 – 初期ノード問題、NAT越え 25 問題点のまとめ • 問題山積みです – P2Pにすることによる問題 • 悪意のあるノード • 取り扱い注意データ • ユーザ数の減少 – ベンダの存在による問題 • 課金 • サーバレスを許さないベンダ – ゲーム特有の問題 • 速度を確保しようとするとPKIは大変カモ – 問題はサーバ機能の分散で解決したのか？ • 結局サービスの停止に怯えるのではないだろうか • けれど、(一応)遊び続けることはできそうだ 26 未来像 • 地球の裏側のノードが昼間のゲーム人口減少を支える？ – データがノードを追って地球をぐるぐると移動していく… • 複数ゲームの同じネットワーク・ゲーム・プラットホームの使用 – ゲーム間での情報共有が容易に • 同タイトルの新版へのデータ移行 – EverQuestとEverQuest2の間で～ • 別タイトルでのデータ共有 – ポケモンなんたらとピカチュウなんたらの間で～ゲーム人口の特定ゲームへの固定化を避ける • 作り捨てMOGの発生 – アップデートなどが無い、長期のサポートが無い • ゲーム以外との情報共有 – IM (now playing TEKKI TAISEN) – ピザ宅配いろいろ考えて！そろそろ新しいMOGがほしいよ！ 27 時間の許す限りディスカッション意見募集！名刺忘れました。[email protected] をメモって頂けるとうれしいですせっかく作ったのにー 28