goodgames
10-01
最終更新:
goodgames
-
view
PacketMonitor R2
「CTEをPacketMonitorで測定したら2倍のパケットが流れていた」との御連絡を頂きましたが...
極めて簡単な前提知識
ゲームに限らず一般的なコンピュータ間の通信に影響及ぼす物理的な要素は基本的に3種類存在します。
1.送信側ノード(例 クライアントPC)
2.通信回線
3.受信側ノード(例 サーバマシン)
2.通信回線
3.受信側ノード(例 サーバマシン)
単純なお話ですね。
この3種類を上り(クライアントからサーバ)と下り(サーバからクライアント)に分けて考えると、
2倍の要素になるので合計6種類の要素について考える必要があります。
2倍の要素になるので合計6種類の要素について考える必要があります。
PacketMonitor(R1)が測定していたのは下りのパケットのみです
予想を遙かに超える7,000名超もの方にダウンロードして頂いたPacketMonitor(R1)ですが、
一点根本的な説明をしておりませんでした。
一点根本的な説明をしておりませんでした。
この段落の題名の通りでございます。
その理由ですが、上りについては相手が受け取ったか否かを確認する術が無いので、
厳密な測定が出来ないことにあります。
厳密な測定が出来ないことにあります。
インターネットにて用いられる通信プロトコルとしてはTCP/IPが有名ですが、
リアルタイム性が求められるアクションゲームではTCP/IPではなくUDP/IPなるプロトコルが用いられます。
リアルタイム性が求められるアクションゲームではTCP/IPではなくUDP/IPなるプロトコルが用いられます。
このプロトコルの重要な特性として「相手に届いたかどうかがわからない」ことが挙げられます。
(この点は必ずしもデメリットだけではなくリアルタイム性を重要視すると実はメリットにもなります)
(この点は必ずしもデメリットだけではなくリアルタイム性を重要視すると実はメリットにもなります)
そのため、上りについてはサーバが受信したかどうかを測定する手段が存在しないため、
無用な機能と考えPacketMonitor(R1)には上りのパケット数測定機能を実装しませんでした。
無用な機能と考えPacketMonitor(R1)には上りのパケット数測定機能を実装しませんでした。
上りのパケットが「送られた」か否かまでは確認可能
到着したか否かについては不明ですが、出発したか否かまでなら測定可能です。
6種類の要素別に測定可否を描いてみました
まず下りについて考えてみましょう
①でサーバから送信されたパケットは②の通信回線を経て③でクライアントPCに到達します。
この③が発生する頻度を測定しているのがPacketMonitor(R1)になります。
この③が発生する頻度を測定しているのがPacketMonitor(R1)になります。
そのため、①や②の発生頻度は測定していません。(測定出来ません)
また、パケットロス(③で受信すべきパケットに不足が)発生した場合、
下記2つの原因が考えられますが...
下記2つの原因が考えられますが...
1.サーバの高負荷などにより①の送信が行われなかった
2.通信回線の品質や障害などにより②の過程でロスが発生した
2.通信回線の品質や障害などにより②の過程でロスが発生した
この2つのケースのどちらかを特定することは出来ません。
簡単に申し上げれば、
受け取らなかったのはわかっているが、
途中で行方不明になったのか、そもそも送られなかったのかはわからない。
受け取らなかったのはわかっているが、
途中で行方不明になったのか、そもそも送られなかったのかはわからない。
これが下りの原則になります。
次に上りについて考えてみよう
上りは下りの逆になるだけですので、
④でクライアントPCから送信されたパケットは⑤の通信回線を経て⑥でサーバに到達します。
④でクライアントPCから送信されたパケットは⑤の通信回線を経て⑥でサーバに到達します。
前述の通りUDP/IPでは相手にパケットが到着したか否かを確認する術が存在しないため、
上りの最終段階である⑥の回数をクライアント側から測定することは出来ません。
また⑤の通信回線上で行方不明になってしまった場合も同様です。
上りの最終段階である⑥の回数をクライアント側から測定することは出来ません。
また⑤の通信回線上で行方不明になってしまった場合も同様です。
クライアントPCから送信した④の回数までは測定出来ますが、
結果的にサーバに届いたか否かが不明となります。
結果的にサーバに届いたか否かが不明となります。
またクライアントPCの高負荷などが原因で④の送信も出来ないようなケースはまず発生しないと予想しており、
④だけを測定する価値は無いとの判断からPacketMonitor(R1)ではこの機能の実装を見送りました。
④だけを測定する価値は無いとの判断からPacketMonitor(R1)ではこの機能の実装を見送りました。
PacketMonitorR2で上りのパケット数測定を可能とした理由
単純です。
この記事の一番上に書きましたが「CTEにてパケット数が2倍になった」との情報は
あくまでも「下りのパケットが2倍になった」ことしか測定出来ていません。
この記事の一番上に書きましたが「CTEにてパケット数が2倍になった」との情報は
あくまでも「下りのパケットが2倍になった」ことしか測定出来ていません。
だったら上りも測定出来るようにしよう。
これが理由です。
これが理由です。
※上りについては前述の通り、サーバに到達したか否かを測定出来ないため、
パケットロスを測定することを目的としておりません。
あくまでも「何回送信しているか」まで測定することが目的です。
パケットロスを測定することを目的としておりません。
あくまでも「何回送信しているか」まで測定することが目的です。
PacketMonitorR2の詳細
起動方法などはPacketMonitor(R1)と同様です。
上り(UpLink)と下り(DownLink)を同時に測定する必要があるため、
画面出力フォーマットを変更致しました。
画面出力フォーマットを変更致しました。
localhost <-> 216.12.220.180:25300 (DL 20:UL 30)
localhost <-> 216.12.220.180:25300 (DL 20:UL 29)
localhost <-> 216.12.220.180:25300 (DL 20:UL 30)
localhost <-> 216.12.220.180:25300 (DL 18:UL 30)
localhost <-> 216.12.220.180:25300 (DL 20:UL 29)
localhost <-> 216.12.220.180:25300 (DL 20:UL 30)
localhost <-> 216.12.220.180:25300 (DL 19:UL 30)
localhost <-> 216.12.220.180:25300 (DL 18:UL 30)
localhost <-> 216.12.220.180:25300 (DL 20:UL 30)
localhost <-> 216.12.220.180:25300 (DL 20:UL 30)
細かい説明は不要でしょう。
PacketMonitorR2のダウンロード
こちらからどうぞ。
ブラウザによっては「怪しいけど本当にいいの?」と聞かれるかもしれません。
CTEでは下りが2倍になったとのことですが上りはどうでしょうか...
( - )