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 W
– Zone Zone X
X
• (2)分割されたデータの
W
一貫性保持
– 調停ノードの導入
– Zone owner Y
• (3)応答性の維持
– 調停ノードとデータ要求ノードの Zone Z
直接接続 Z
• (4)データの保管 V
– データの管理と保管を分離 Zone Y
Zone V
– DHTを用いてデータ保管
10
(1)サーバ機能の分散
局所性と構造に着目
• データおける局所性:あるノードの用いるデータは全体の一部
– 全体の一部のデータのみを把握することでゲーム世界の共有が可能
– サーバ機能はデータを単位として分割可能
• ゲームにおけるデータの構造 Game
– 座標、方向、数、状態など様々
– ある程度の関連性を持つ Map MapA 川の場所
町の場所
• 関連性を基にした分割
– 柔軟な分割単位の指定 MapB 森の場所
• 文字列による分割単位へのアクセス 村の場所
プレイヤの現在地 プレイヤA
Zone:データ分割の単位 プレイヤB
ログイン情報 11
(2)分割されたデータの一貫性保持
ゲーム進行に伴う各Zoneのデータの変更が生じる。
各ゲーム参加ノードがデータの変更を要求する。
調停ノードが必要
– 各分割単位（Zone）ごとに一つの管理ノードが必要
– 調停ノードがゲームのルールを知っている必要がある
• ゲーム参加ノードが管理ノードを行う
12
Zoneの分割統治
• データ管理ノードの決定
– 指名制
• ゲーム参加ノードの事前登録
• 指名のための複雑化
– 立候補制
• ゲーム参加ノードのみが立候補
• 指名部分を分離による単純化
• 本提案では立候補制を選択
– インフラが複雑化することを避ける
13
(3)応答性の維持
• ゲームは応答性に敏感
– 200ms以下での応答性が必要
• 人間がストレスを感じる
• クライアント・サーバ形での実現手法
– クライアントとサーバを直接接続する
• 中継ノードを介さない
• 本提案での実現手法
– 調停ノードとデータを必要とするノードを直接接続する
– クライアント・サーバ形と同程度の応答性を確保
14
(4)データの保管
• データの保管とデータの管理を分割
– データの保管にデータの管理能力は必要ない
– 複数ゲームでのデータ保管
• Distributed Hash Table (DHT) の利用
– DHT
ゲーム(データ管理)
• 複数のノードでハッシュ表を共有
ゲームA ゲームB ゲームC
• 検索に対してO(log N)のノードを
経由することで検索可能
– ZoneをHash Keyとする
– Zoneに関係するデータを全て保存
• データ管理ノードの決定 DHT
• データ要求ノードの登録
• Zoneのデータの記録 データ保管
15
ちょっと宣伝・・・
現在できている実装
• libcookai
– ライブラリとして提供 Game Program
• C言語にて実装
– 動作確認済みプラットホーム
• NetBSD- (1.6, 2.0*)
• FreeBSD-4.*/ -5.* libcookai
• Vine Linux 2.6 Pastry
• Sun OS 5.8
• Mac OS X
– http://libcookai.sourceforge.net 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
時間の許す限りディスカッション
意見募集！
名刺忘れました。takuji-i@is.naist.jp をメモって頂けるとうれしいです
せっかく作ったのにー
28