通信分析 - (2012/09/05 (水) 01:19:50) の最新版との変更点
追加された行は緑色になります。
削除された行は赤色になります。
*通信分析
#contents
ゲーム中の通信についてキャプチャしたパケットから分析。
記述内容は、Ver.102.75.20.84(2012/07/27)以降の送受信パケットを前提。
これ以前のバージョンのパケットは持ち合わせてない。今後のアップデートで多少変更されるはず・・・だよね。
PS3内部でどんな処理をしているかは不明だが、パケットの送受信には意味があるはずなので、パケットの流れを見ておおよその検討をつけた。
推測した結論に達するまでの途中経過(仮定、試行、消去法など)は記述しても長くなるので省略。
パケットデータは01の数値のみで、プロトコルフォーマット、PS3やバトオペ内部の定数値はわからないが、比較や結果から当たりをつけた。
内容についてはプレイしていれば経験から何となくわかっている人もいるはず。
※分析や判断のミスもあるので正確な情報ではないことに注意。用語とかは検索を。
-PS3のネット対戦ゲームに関する参考サイト。
--[[PS3のNATタイプやUPnP、使用するポート番号>>http://manuals.playstation.net/document/jp/ps3/current/settings/connecttest.html]]
--[[PS3 wikiの回線についての質問>>http://www.ps3wiki.net/index.php?%E3%82%88%E3%81%8F%E3%81%82%E3%82%8B%E8%B3%AA%E5%95%8F%E9%9B%86#eaa31d57]]
--[[PS3機動戦士ガンダムEXVSの対戦の仕組み>>http://www29.atwiki.jp/arcgundamvs/pages/344.html]]
-関連スレッド
--[[【PS3】 バトルオペレーション 回線評価スレ>>http://toro.2ch.net/test/read.cgi/gamerobo/1341466547/]]
----
**通信している主なPSNサーバと通信ポート
|サーバ名|機能|h
|マッチング|ルーム作成時にルーム情報を登録、ルーム検索時にルーム情報を提供|
|ルックアップ|対戦セッション情報を持つセッションサーバを検索・提供|
|セッション|セッション(ルーム)の管理・制御|
|TCP/UDP|ポート番号|サービス名|用途|h
|TCP|3478|stun|マッチングサーバとの通信|
|TCP|3479|twrpc|ルックアップサーバとの通信|
|TCP|3480|plethora|セッションサーバとの通信|
|UDP|3658|ps-ams|対戦相手とのP2P通信|
**ルーム内の自分のアンテナ本数
ルーム内で自分のIDの横に表示されるアンテナ本数は、都内にあるPSNの統計資源サーバとの下り・上りの帯域計測結果(bps)から評価されている。上下速度で評価の悪い方がアンテナ本数に反映。
計測タイミングは次の3通り。
-ルーム作成で「この条件で作成」を選んでからルーム画面表示まで
-ルーム検索で検索してどこかのホストを選んでからルーム画面表示まで
-クイックマッチでクイックマッチを選んでからルーム画面表示まで
一度計測するとバトオペ起動中は内部で保持しているようで、対戦後退出して別ルームに入室など上の3通りを実行しても通常は帯域測定しないため、アンテナ本数に変化なし。
ただ3通りのタイミングで再度帯域測定が実行される場合もあり、条件がわからない。
自分のアンテナ本数はPSNのとあるサーバとの帯域結果なので、対戦相手との相性(RTT、ping値)とはほぼ関係がない。
-この帯域計測はPS3の[[インターネット接続テスト>>http://manuals.playstation.net/document/jp/ps3/current/settings/connecttest.html]]と同じサーバ、テストデータサイズ。試しに接続テストをキャプチャして、送受信時間とデータサイズから帯域を手計算した結果と接続テストの表示結果が同じ数値になることを確認した。他のソフトも利用していることからSONYが提供している計測プログラム(API)だろう。今後発売するソフトもこれを使うはずだから知っておいて損はない。
-ルーム作成や入室時の帯域計測についてキャプチャデータから「下り/上り速度」を計算した
--アンテナ5本:(29.9/6.5Mbps)、(29.0/5.9Mbps)、(26.6/7.5Mbps)、(21.7/5.9Mbps)、(20.5/7.0Mbps)
--アンテナ3本:(946.7kbps/35.1Mbps)
-回線評価スレの報告
--光マンションVDSL PSN測定、下り10Mbps上り2Mbpsで4本、下り15上り4Mbpsで5本
※自分の回線や中継するネットワーク機器は当然だが、PSNサーバの負荷やトラフィック状況により帯域測定値は変動する
**ルーム作成
ルーム作成をすると、ホストやルームの情報がセッションサーバおよびマッチングサーバに登録される。
-セッションサーバに登録する情報
--PSNID、オンラインネーム、アバターURL、最大人数、バトオペのゲームID、NATタイプ、IPアドレスなど
--2012/08/30のVerUPでブロックリストをセッションサーバに登録
-マッチングサーバに登録する情報
--PSNID、最大人数、参加人数(作成時は1)、階級下限上限、ステージ、アンテナ本数、ルームコメント、セッションサーバ、IPアドレス、ポート番号など
マッチングサーバに登録するアンテナ本数は、ルーム作成時に計測またはすでに保持してある帯域結果(bps)で判定されたもの、つまりMyIDの横に表示してあるアンテナ本数。
-カスタムマッチでルーム検索した結果の画面左下のガイドを選択すると検索画面のガイドに次のようにある
<<カスタムマッチ 検索結果一覧>>ガイド
・ルームの検索候補が表示され、選択することで入室できます。
・<<通信状態>>は、ルームを作成したホストとサーバーとの通信状態を表示しています。
ルーム内でのプレイヤー同士の通信状態とは異なります。
つまり
ルーム検索時に表示されるホストのアンテナ本数=ルーム内の自分のアンテナ本数=PSNサーバとの帯域速度による判定
-現状バトオペ起動後の最初のルーム作成では、ルーム内の自分のアンテナは5本にもかかわらず、マッチングサーバに登録するアンテナ本数が3本になっている
--ルーム内アンテナ5本限定なのか、0~4本の場合もマッチングサーバには3本で登録するかはわからないが、ルームコメントで5本アンテナについて書いてるホストを見て「あれ?あなたは3本じゃない?」というケースはこの現象と思われる
--対処方法は、バトオペ起動後ルームを作成して閉じるまたはルームに入室して退出するなど、一度ルームに入室することを実行してから再度ルーム作成をすればいい(ジョインなら一戦闘後退出でもいい)
---典型的な初期ルートのプログラムバグだろう
**ルーム作成したときの流れ(ホスト)
-「この条件で作成」を選んでルーム作成時にセッションサーバとマッチングサーバに自分の情報を登録
-検索する人がマッチングサーバから情報をもらい、ホストの自分に向けて3658/udpかpingを送信してくるので応答を送信
-ルームに人が入ってくると、セッションサーバから更新されたセッション情報(入室した人の情報)をもらい、その人たちとP2P(3658/udp)通信
--以降、ルーム内のメンバとはP2P通信
--以降、セッションサーバとは8秒ごとのキープアライブ、戦闘開始前ロード中や戦闘終了後に何らかの制御情報を通信
--以降、マッチングサーバとは8秒ごとのキープアライブ、戦闘終了後にルーム情報の更新通知
**ルーム検索からルーム入室したときの流れ(ジョイン)
-ルーム検索するとマッチングサーバからホストの情報(最大20人)をもらい、情報リストの上位10人のホストに対して3658/udpかpingを送信して検索結果が表示
--ホストのポート(3658/udp)が開いてない場合はping送信になるが、pingにホストが応答しなくても検索結果は表示されるので、マッチングサーバが提供したホスト情報が検索結果のすべてを表す
-検索結果のどこかのルームに入室すると、セッションサーバに自分の情報を登録
-セッションサーバからルーム内のメンバ情報を取得
--メンバ情報は、PSNID、オンラインネーム、アバターURL、チームID(所属)、NATタイプ、IPアドレスなど
-ルーム内にいる各メンバに対してP2P(3658/udp)通信
--以降、ルーム内のメンバとはP2P通信
--以降、セッションサーバとは8秒ごとのキープアライブ
--出撃します後のロード中にマッチングサーバとは通信終了
**対戦相手のアンテナ
ルーム入室してからルーム内画面が表示されるまでの間、ルーム内の各メンバに対して2つのP2P(3658/udp)通信を行っている
-パケット往復時間によるRTT(マイクロ秒)の測定
--122バイトのUDPデータを自分から3回送信し、相手からの応答受信
--122バイトのUDPデータを相手から3回受信し、応答を送信
-Packet Pairによる帯域幅(bps)を測定
--自分から相手に対して、1146バイトのUDPデータ2組同時送信、これを9回実施
--相手から自分に対して同時に2組送信された1146バイトのUDPデータを受信、これを9回実施
--1146バイトと2つのパケットの到着時間差から帯域を測定する
RTTは、3回測定の平均、最小、最大のどれを利用しているかは不明。
Packet Pairによる帯域幅測定は、9回も行ってるので平均値を使ってるだろう。
この2つの測定結果から相手のアンテナ表示が評価されていると思われる。
ルームで質問して聞いた限り、自分から見た相手のアンテナ本数と相手から見た自分のアンテナ本数は必ずしも一致するわけではないようで、pingによる単純なRTT測定とは異なるようだ。
**対戦の接続形態
対戦中のP2Pパケットの送受信相手は以下のようになる。
-ホスト
--ホストはジョイン全員からデータ受信
--4VS4のホストは7人の内3人にデータ送信
--5VS5のホストは9人の内4人にデータ送信
--6VS6のホストは11人の内4人にデータ送信
-ジョイン
--ジョインはホストにデータ送信
--ジョインはホストを含む誰か1人または2人からデータ受信
--ジョインはホストを含む誰か1人または2人へデータ送信
-全メンバ
--各メンバと10秒ごとにキープアライブ送受信
--各メンバと60秒ごとにパケットペア送受信
6VS6のときのデータの流れを図に示す
-連邦E1~E6、ジオンZ1~Z6がどのような接続配置になるかは入室した順で決まり、誰かが退出すると流れが一部変わる
-ホストが全パケットを集約しているので処理落ちが激しい理由がわかる
-図から回線の低い人に全体が合わせられるのがわかる
-ホスト以外の誰かがLOSTしても一部変わるがこの接続形態を維持する
&tt(){┏━━━━━┓ ┏━━━━━┓}
&tt(){┃ ┃ ┏━━━━━━>┃ ┃}
&tt(){┃ ┃ ┃ ┃ ┃}
&tt(){┃ ┃━>Z1━>E2━>┃ ┃}
&tt(){┃ ┃ ┃ ┃}
&tt(){┃ ┃ ┏━━━━━━>┃ ┃}
&tt(){┃ ┃ ┃ ┃ ┃}
&tt(){┃ ┃━>Z2━>E3━>┃ ┃}
&tt(){┃ ┃ ┃ ┃ ┃}
&tt(){┃ ┃ ┗━━>E4━>┃ ┃}
&tt(){┃ ┃ ┃ ┃}
&tt(){┃ ホスト ┃ ┏━━━━━━>┃ ホスト ┃}
&tt(){┃ E1 ┃ ┃ ┃ E1 ┃}
&tt(){┃ ┃━>Z3━>E5━>┃ ┃}
&tt(){┃ ┃ ┃ ┃ ┃}
&tt(){┃ ┃ ┗━━>E6━>┃ ┃}
&tt(){┃ ┃ ┃ ┃}
&tt(){┃ ┃ ┏━━━━━━>┃ ┃}
&tt(){┃ ┃ ┃ ┃ ┃}
&tt(){┃ ┃━>Z4━>Z5━>┃ ┃}
&tt(){┃ ┃ ┃ ┃ ┃}
&tt(){┃ ┃ ┗━━>Z6━>┃ ┃}
&tt(){┗━━━━━┛ ┗━━━━━┛}
----
**PS3のMTU値
対戦中のP2P(3658/udp)パケットを見るとIPヘッダのフラグメントがたびたび起きている。PS3のネットワーク設定でMTUを自動にしていれば1500バイトがMTUとして設定されてるはず。さらに回線事業者ごとにMTUが異なる。ユーザーの多いBフレッツだとMTUは1454バイト。この状態だと次のようなことになる。
+バトオペのアプリケーション内で1500バイトを超えるデータを送信
+PS3のプロトコルスタック(IP層)でフラグメント処理が行われ、パケットが1500バイトと超えたバイトに分割される
+BフレッツのMTUの影響で自宅のルータでフラグメント処理が行われ、1500バイトが1454バイトと46バイトに分割される
+分割パケット3つが相手側のPS3で再構築されバトオペに渡る
バトオペ側で分割パケットがでないような設計をしてないのでどうしようもないが、自分の回線事業者のMTUをPS3のMTUに設定すればルータにおける無駄な分割は避けられる。微々たるものだが相手に届く分割パケットが少なければ、到着のずれによる遅延や再構築のときの余分な処理を減らせる。
ただ対戦相手の事業者のMTUまで考慮してMTUを設定すべきかは何ともいえない。
**出撃しますからの無限ロードの流れ
-ロード中、自分からホストへの3658/udp送信に対してDestination unreachable (Port unreachable)が返却
--何らかの理由によりホストが自分の信号を受け付けてくれない
-セッションサーバから何らかのエラー通知を受信し、自分からセッションサーバに切断通知
--バトオペ側でこの後の処理がないせいでXMBから終了せざるを得ない
--この後も対戦相手からのP2P通信は1分くらいは受信する
**対戦相手との相性
相手との相性(RTT、ping値)については、自分と相手との物理的距離(通信路の距離)、プロバイダや回線事業者のネットワーク機器の処理能力、インターネットエクスチェンジによる地域格差、トラフィック状態などいろいろな要因が影響する。相性は、自分と相手という相対的なもので常に変わる。なので相性のいい人、悪い人がいる。
**正常に対戦できず困っている場合
-ルータを使用しているならポート開放ができてるか確認
--NAT2にする。PS3の通信対戦はUDPのポート番号3658でP2Pを実現しているから必須
-無線LANを使用しているならすべて有線にする
--無線LANは半二重通信であり毎回待ち時間が必ず入るから
-自宅内のネットワーク機器やケーブルが正常か確認、また問題報告がある製品か調べる
-自宅の回線帯域、ルータ、ハブの負荷を軽減するために、ゲーム中は配信やストリーミング、IP電話、大きいファイルのアップやダウンロードなど控える
-自分の家から一番最初に接続するISPの接続先サーバを確認
--Windowsのコマンドプロンプトで tracert www.yahoo.co.jp(サイトはどこでもいい) を実行。実行した結果、ルータがないなら1番上、ルータ1台あるなら上から2番目を見る。右端にISPのホスト名があることを確認し、その左横の数字3つを確認。その数字はミリ秒単位で3回pingしたことと同じ。自分の家からの通信は必ずこのISPサーバを経由するので、誰と通信するにもこの数字より速いping値は出せない。だから自宅からISPの接続先サーバへのping値は知っておいた方がいい。
-最終手段はISPや回線事業者の見直し
--FTTH、ADSL、CATVの中ではCATVが上りがネックで不自由を受けてる報告を各地で見る
--対戦の通信量程度なら普通はだいじょうぶだが、ISPによってはP2P規制や帯域規制があるから注意
----
**コメント
#pcomment(reply,below,enableurl,nsize=20)
*通信分析
#contents
ゲーム中の通信についてキャプチャしたパケットから分析。
記述内容は、Ver.102.75.20.84(2012/07/27)以降の送受信パケットを前提。
これ以前のバージョンのパケットは持ち合わせてない。今後のアップデートで多少変更されるはず・・・だよね。
PS3内部でどんな処理をしているかは不明だが、パケットの送受信には意味があるはずなので、パケットの流れを見ておおよその検討をつけた。
推測した結論に達するまでの途中経過(仮定、試行、消去法など)は記述しても長くなるので省略。
パケットデータは01の数値のみで、プロトコルフォーマット、PS3やバトオペ内部の定数値はわからないが、比較や結果から当たりをつけた。
内容についてはプレイしていれば経験から何となくわかっている人もいるはず。
※分析や判断のミスもあるので正確な情報ではないことに注意。用語とかは検索を。
-PS3のネット対戦ゲームに関する参考サイト。
--[[PS3のNATタイプやUPnP、使用するポート番号>>http://manuals.playstation.net/document/jp/ps3/current/settings/connecttest.html]]
--[[PS3 wikiの回線についての質問>>http://www.ps3wiki.net/index.php?%E3%82%88%E3%81%8F%E3%81%82%E3%82%8B%E8%B3%AA%E5%95%8F%E9%9B%86#eaa31d57]]
--[[PS3機動戦士ガンダムEXVSの対戦の仕組み>>http://www29.atwiki.jp/arcgundamvs/pages/344.html]]
-関連スレッド
--[[【PS3】 バトルオペレーション 回線評価スレ>>http://toro.2ch.net/test/read.cgi/gamerobo/1341466547/]]
----
**通信している主なPSNサーバと通信ポート
|BGCOLOR(lightgray):サーバ名|BGCOLOR(lightgray):機能|h
|マッチング|ルーム作成時にルーム情報を登録、ルーム検索時にルーム情報を提供|
|ルックアップ|対戦セッション情報を持つセッションサーバを検索・提供|
|セッション|セッション(ルーム)の管理・制御|
|BGCOLOR(lightgray):TCP/UDP|BGCOLOR(lightgray):ポート番号|BGCOLOR(lightgray):サービス名|BGCOLOR(lightgray):用途|h
|TCP|3478|stun|マッチングサーバとの通信|
|TCP|3479|twrpc|ルックアップサーバとの通信|
|TCP|3480|plethora|セッションサーバとの通信|
|UDP|3658|ps-ams|対戦相手とのP2P通信|
**ルーム内の自分のアンテナ本数
ルーム内で自分のIDの横に表示されるアンテナ本数は、都内にあるPSNの統計資源サーバとの下り・上りの帯域計測結果(bps)から評価されている。上下速度で評価の悪い方がアンテナ本数に反映。
計測タイミングは次の3通り。
-ルーム作成で「この条件で作成」を選んでからルーム画面表示まで
-ルーム検索で検索してどこかのホストを選んでからルーム画面表示まで
-クイックマッチでクイックマッチを選んでからルーム画面表示まで
一度計測するとバトオペ起動中は内部で保持しているようで、対戦後退出して別ルームに入室など上の3通りを実行しても通常は帯域測定しないため、アンテナ本数に変化なし。
ただ3通りのタイミングで再度帯域測定が実行される場合もあり、条件がわからない。
自分のアンテナ本数はPSNのとあるサーバとの帯域結果なので、対戦相手との相性(RTT、ping値)とはほぼ関係がない。
-この帯域計測はPS3の[[インターネット接続テスト>>http://manuals.playstation.net/document/jp/ps3/current/settings/connecttest.html]]と同じサーバ、テストデータサイズ。試しに接続テストをキャプチャして、送受信時間とデータサイズから帯域を手計算した結果と接続テストの表示結果が同じ数値になることを確認した。他のソフトも利用していることからSONYが提供している計測プログラム(API)だろう。今後発売するソフトもこれを使うはずだから知っておいて損はない。
-ルーム作成や入室時の帯域計測についてキャプチャデータから「下り/上り速度」を計算した
|アンテナ|下り速度/上り速度(単位:bps)|h
|CENTER:5本|29.9M/6.5M、29.0M/5.9M、26.6M/7.5M、21.7M/5.9M、20.5M/7.0M、18.3M/7.2M|
|CENTER:4本|5.5/3.0M、5.5/2.7M|
|CENTER:3本|35.1M/946.7k|
|CENTER:2本|5.5M/539.4k、5.5M/520.9k|
-回線評価スレの報告
--光マンションVDSL PSN測定、下り10Mbps上り2Mbpsで4本、下り15上り4Mbpsで5本
※自分の回線や中継するネットワーク機器は当然だが、PSNサーバの負荷やトラフィック状況により帯域測定値は変動する
**ルーム作成
ルーム作成をすると、ホストやルームの情報がセッションサーバおよびマッチングサーバに登録される。
-セッションサーバに登録する情報
--PSNID、オンラインネーム、アバターURL、最大人数、バトオペのゲームID、NATタイプ、IPアドレスなど
--2012/08/30のVerUPでブロックリストをセッションサーバに登録
-マッチングサーバに登録する情報
--PSNID、最大人数、参加人数(作成時は1)、階級下限上限、ステージ、アンテナ本数、ルームコメント、セッションサーバ、IPアドレス、ポート番号など
マッチングサーバに登録するアンテナ本数は、ルーム作成時に計測またはすでに保持してある帯域結果(bps)で判定されたもの、つまりMyIDの横に表示してあるアンテナ本数。
-カスタムマッチでルーム検索した結果の画面左下のガイドを選択すると検索画面のガイドに次のようにある
<<カスタムマッチ 検索結果一覧>>ガイド
・ルームの検索候補が表示され、選択することで入室できます。
・<<通信状態>>は、ルームを作成したホストとサーバーとの通信状態を表示しています。
ルーム内でのプレイヤー同士の通信状態とは異なります。
つまり
ルーム検索時に表示されるホストのアンテナ本数=ルーム内の自分のアンテナ本数=PSNサーバとの帯域速度による判定
-現状バトオペ起動後の最初のルーム作成では、ルーム内の自分のアンテナは5本にもかかわらず、マッチングサーバに登録するアンテナ本数が3本になっている
--アナウンスはなかったが2012/10/04のアップデートで修正。要望の効果あったかも。
**ルーム作成したときの流れ(ホスト)
-「この条件で作成」を選んでルーム作成時にセッションサーバとマッチングサーバに自分の情報を登録
-検索する人がマッチングサーバから情報をもらい、ホストの自分に向けて3658/udpかpingを送信してくるので応答を送信
-ルームに人が入ってくると、セッションサーバから更新されたセッション情報(入室した人の情報)をもらい、その人たちとP2P(3658/udp)通信
--以降、ルーム内のメンバとはP2P通信
--以降、セッションサーバとは8秒ごとのキープアライブ、戦闘開始前ロード中や戦闘終了後に何らかの制御情報を通信
--以降、マッチングサーバとは8秒ごとのキープアライブ、戦闘終了後にルーム情報の更新通知
**ルーム検索からルーム入室したときの流れ(ジョイン)
-ルーム検索するとマッチングサーバからホストの情報(最大20人)をもらい、情報リストの上位10人のホストに対して3658/udpかpingを送信して検索結果が表示
--ホストのポート(3658/udp)が開いてない場合はping送信になるが、pingにホストが応答しなくても検索結果は表示されるので、マッチングサーバが提供したホスト情報が検索結果のすべてを表す
-検索結果のどこかのルームに入室すると、セッションサーバに自分の情報を登録
-セッションサーバからルーム内のメンバ情報を取得
--メンバ情報は、PSNID、オンラインネーム、アバターURL、チームID(所属)、NATタイプ、IPアドレスなど
-ルーム内にいる各メンバに対してP2P(3658/udp)通信
--以降、ルーム内のメンバとはP2P通信
--以降、セッションサーバとは8秒ごとのキープアライブ
--出撃します後のロード中にマッチングサーバとは通信終了
**対戦相手のアンテナ
ルーム入室してからルーム内画面が表示されるまでの間、ルーム内の各メンバに対して2つのP2P(3658/udp)通信を行っている
-パケット往復時間によるRTT(マイクロ秒)の測定
--122バイトのUDPデータを自分から3回送信し、相手からの応答受信
--122バイトのUDPデータを相手から3回受信し、応答を送信
-Packet Pairによる帯域幅(bps)を測定
--自分から相手に対して、1146バイトのUDPデータ2組同時送信、これを9回実施
--相手から自分に対して同時に2組送信された1146バイトのUDPデータを受信、これを9回実施
--1146バイトと2つのパケットの到着時間差から帯域を測定する
RTTは、3回測定の平均、最小、最大のどれを利用しているかは不明。
Packet Pairによる帯域幅測定は、9回も行ってるので平均値を使ってるだろう。
この2つの測定結果から相手のアンテナ表示が評価されていると思われる。
ルームで質問して聞いた限り、自分から見た相手のアンテナ本数と相手から見た自分のアンテナ本数は必ずしも一致するわけではないようで、pingによる単純なRTT測定とは異なるようだ。
**対戦の接続形態
対戦中のP2Pパケットの送受信相手は以下のようになる。
-ホスト
--ホストはジョイン全員からデータ受信
--4VS4のホストは7人の内3人にデータ送信
--5VS5のホストは9人の内4人にデータ送信
--6VS6のホストは11人の内4人にデータ送信
-ジョイン
--ジョインはホストにデータ送信
--ジョインはホストを含む誰か1人または2人からデータ受信
--ジョインはホストを含む誰か1人または2人へデータ送信
-全メンバ
--各メンバと10秒ごとにキープアライブ送受信
--各メンバと60秒ごとにパケットペア送受信
6VS6のときのデータの流れを図に示す
-連邦E1~E6、ジオンZ1~Z6がどのような接続配置になるかは入室した順で決まり、誰かが退出すると流れが一部変わる
-ホストが全パケットを集約しているので処理落ちが激しい理由がわかる
-図から回線の低い人に全体が合わせられるのがわかる
-ホスト以外の誰かがLOSTしても一部変わるがこの接続形態を維持する
&tt(){┏━━━━━┓ ┏━━━━━┓}
&tt(){┃ ┃ ┏━━━━━━>┃ ┃}
&tt(){┃ ┃ ┃ ┃ ┃}
&tt(){┃ ┃━>Z1━>E2━>┃ ┃}
&tt(){┃ ┃ ┃ ┃}
&tt(){┃ ┃ ┏━━━━━━>┃ ┃}
&tt(){┃ ┃ ┃ ┃ ┃}
&tt(){┃ ┃━>Z2━>E3━>┃ ┃}
&tt(){┃ ┃ ┃ ┃ ┃}
&tt(){┃ ┃ ┗━━>E4━>┃ ┃}
&tt(){┃ ┃ ┃ ┃}
&tt(){┃ ホスト ┃ ┏━━━━━━>┃ ホスト ┃}
&tt(){┃ E1 ┃ ┃ ┃ E1 ┃}
&tt(){┃ ┃━>Z3━>E5━>┃ ┃}
&tt(){┃ ┃ ┃ ┃ ┃}
&tt(){┃ ┃ ┗━━>E6━>┃ ┃}
&tt(){┃ ┃ ┃ ┃}
&tt(){┃ ┃ ┏━━━━━━>┃ ┃}
&tt(){┃ ┃ ┃ ┃ ┃}
&tt(){┃ ┃━>Z4━>Z5━>┃ ┃}
&tt(){┃ ┃ ┃ ┃ ┃}
&tt(){┃ ┃ ┗━━>Z6━>┃ ┃}
&tt(){┗━━━━━┛ ┗━━━━━┛}
----
**PS3のMTU値
対戦中のP2P(3658/udp)パケットを見るとIPヘッダのフラグメントがたびたび起きている。PS3のネットワーク設定でMTUを自動にしていれば1500バイトがMTUとして設定されてるはず。さらに回線事業者ごとにMTUが異なる。ユーザーの多いBフレッツだとMTUは1454バイト。この状態だと次のようなことになる。
+バトオペのアプリケーション内で1500バイトを超えるデータを送信
+PS3のプロトコルスタック(IP層)でフラグメント処理が行われ、パケットが1500バイトと超えたバイトに分割される
+BフレッツのMTUの影響で自宅のルータでフラグメント処理が行われ、1500バイトが1454バイトと46バイトに分割される
+分割パケット3つが相手側のPS3で再構築されバトオペに渡る
バトオペ側で分割パケットがでないような設計をしてないのでどうしようもないが、自分の回線事業者のMTUをPS3のMTUに設定すればルータにおける無駄な分割は避けられる。微々たるものだが相手に届く分割パケットが少なければ、到着のずれによる遅延や再構築のときの余分な処理を減らせる。
ただ対戦相手の事業者のMTUまで考慮してMTUを設定すべきかは何ともいえない。
**出撃しますからの無限ロードの流れ
-ロード中、自分からホストへの3658/udp送信に対してDestination unreachable (Port unreachable)が返却
--何らかの理由によりホストが自分の信号を受け付けてくれない
-セッションサーバから何らかのエラー通知を受信し、自分からセッションサーバに切断通知
--バトオペ側でこの後の処理がないせいでXMBから終了せざるを得ない
--この後も対戦相手からのP2P通信は1分くらいは受信する
**対戦相手との相性
相手との相性(RTT、ping値)については、自分と相手との物理的距離(通信路の距離)、プロバイダや回線事業者のネットワーク機器の処理能力、インターネットエクスチェンジによる地域格差、トラフィック状態などいろいろな要因が影響する。相性は、自分と相手という相対的なもので常に変わる。なので相性のいい人、悪い人がいる。
**正常に対戦できず困っている場合
-ルータを使用しているならポート開放ができてるか確認
--NAT2にする。PS3の通信対戦はUDPのポート番号3658でP2Pを実現しているから必須
-無線LANを使用しているならすべて有線にする
--無線LANは半二重通信であり毎回待ち時間が必ず入るから
-自宅内のネットワーク機器やケーブルが正常か確認、また問題報告がある製品か調べる
-自宅の回線帯域、ルータ、ハブの負荷を軽減するために、ゲーム中は配信やストリーミング、IP電話、大きいファイルのアップやダウンロードなど控える
-自分の家から一番最初に接続するISPの接続先サーバを確認
--Windowsのコマンドプロンプトで tracert www.yahoo.co.jp(サイトはどこでもいい) を実行。実行した結果、ルータがないなら1番上、ルータ1台あるなら上から2番目を見る。右端にISPのホスト名があることを確認し、その左横の数字3つを確認。その数字はミリ秒単位で3回pingしたことと同じ。自分の家からの通信は必ずこのISPサーバを経由するので、誰と通信するにもこの数字より速いping値は出せない。だから自宅からISPの接続先サーバへのping値は知っておいた方がいい。
-最終手段はISPや回線事業者の見直し
--FTTH、ADSL、CATVの中ではCATVが上りがネックで不自由を受けてる報告を各地で見る
--対戦の通信量程度なら普通はだいじょうぶだが、ISPによってはP2P規制や帯域規制があるから注意
----
**コメント
#pcomment(reply,below,enableurl,nsize=20)
表示オプション
横に並べて表示:
変化行の前後のみ表示: