「2014/05/10-01」の編集履歴(バックアップ)一覧はこちら
「2014/05/10-01」(2014/06/07 (土) 18:42:54) の最新版変更点
追加された行は緑色になります。
削除された行は赤色になります。
**PacketMonitor R2
「CTEをPacketMonitorで測定したら2倍のパケットが流れていた」との御連絡を頂きましたが...
----
***極めて簡単な前提知識
ゲームに限らず一般的なコンピュータ間の通信に影響及ぼす物理的な要素は基本的に&b(){3種類}存在します。
&b(){1.送信側ノード}(例 クライアントPC)
&b(){2.通信回線}
&b(){3.受信側ノード}(例 サーバマシン)
単純なお話ですね。
この3種類を&b(){上り}(クライアントからサーバ)と&b(){下り}(サーバからクライアント)に分けて考えると、
2倍の要素になるので&b(){合計6種類}の要素について考える必要があります。
----
***PacketMonitor(R1)が測定していたのは下りのパケットのみです
予想を遙かに超える7,000名超もの方にダウンロードして頂いたPacketMonitor(R1)ですが、
一点根本的な説明をしておりませんでした。
&b(){この段落の題名の通りでございます。}
その理由ですが、上りについては相手が受け取ったか否かを確認する術が無いので、
厳密な測定が出来ないことにあります。
インターネットにて用いられる通信プロトコルとしてはTCP/IPが有名ですが、
リアルタイム性が求められるアクションゲームではTCP/IPではなくUDP/IPなるプロトコルが用いられます。
このプロトコルの重要な特性として「相手に届いたかどうかがわからない」ことが挙げられます。
(この点は必ずしもデメリットだけではなくリアルタイム性を重要視すると実はメリットにもなります)
そのため、上りについてはサーバが受信したかどうかを測定する手段が存在しないため、
無用な機能と考えPacketMonitor(R1)には上りのパケット数測定機能を実装しませんでした。
----
***上りのパケットが「送られた」か否かまでは確認可能
到着したか否かについては不明ですが、出発したか否かまでなら測定可能です。
&b(){6種類の要素別に測定可否を描いてみました}
&image(ClientServerTraffic_20140510.png)
----
***まず下りについて考えてみましょう
①でサーバから送信されたパケットは②の通信回線を経て③でクライアントPCに到達します。
この&b(){③が発生する頻度を測定している}のがPacketMonitor(R1)になります。
そのため、①や②の発生頻度は測定していません。(測定出来ません)
また、パケットロス(③で受信すべきパケットに不足が)発生した場合、
下記2つの原因が考えられますが...
&b(){1.サーバの高負荷などにより①の送信が行われなかった}
&b(){2.通信回線の品質や障害などにより②の過程でロスが発生した}
&b(){この2つのケースのどちらかを特定することは出来ません。}
簡単に申し上げれば、
受け取らなかったのはわかっているが、
途中で行方不明になったのか、そもそも送られなかったのかはわからない。
これが下りの原則になります。
----
***次に上りについて考えてみよう
上りは下りの逆になるだけですので、
④でクライアントPCから送信されたパケットは⑤の通信回線を経て⑥でサーバに到達します。
前述の通りUDP/IPでは相手にパケットが到着したか否かを確認する術が存在しないため、
上りの最終段階である⑥の回数をクライアント側から測定することは出来ません。
また⑤の通信回線上で行方不明になってしまった場合も同様です。
クライアントPCから送信した④の回数までは測定出来ますが、
結果的にサーバに届いたか否かが不明となります。
またクライアントPCの高負荷などが原因で④の送信も出来ないようなケースはまず発生しないと予想しており、
④だけを測定する価値は無いとの判断からPacketMonitor(R1)ではこの機能の実装を見送りました。
----
***PacketMonitorR2で上りのパケット数測定を可能とした理由
単純です。
この記事の一番上に書きましたが「CTEにてパケット数が2倍になった」との情報は
あくまでも「下りのパケットが2倍になった」ことしか測定出来ていません。
だったら上りも測定出来るようにしよう。
これが理由です。
※上りについては前述の通り、サーバに到達したか否かを測定出来ないため、
パケットロスを測定することを目的としておりません。
あくまでも「何回送信しているか」まで測定することが目的です。
----
***PacketMonitorR2の詳細
起動方法などは[[PacketMonitor(R1)>>http://www45.atwiki.jp/goodgames/pages/1250.html]]と同様です。
上り(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のダウンロード
[[こちら>>http://www.goodgames.jp/etc/BF4PacketMonitorR2.zip]]からどうぞ。
ブラウザによっては「怪しいけど本当にいいの?」と聞かれるかもしれません。
----
CTEでは下りが2倍になったとのことですが上りはどうでしょうか...
(&Counter())
**PacketMonitor R2
「CTEをPacketMonitorで測定したら2倍のパケットが流れていた」との御連絡を頂きましたが...
----
***極めて簡単な前提知識
ゲームに限らず一般的なコンピュータ間の通信に影響及ぼす物理的な要素は基本的に&b(){3種類}存在します。
&b(){1.送信側ノード}(例 クライアントPC)
&b(){2.通信回線}
&b(){3.受信側ノード}(例 サーバマシン)
単純なお話ですね。
この3種類を&b(){上り}(クライアントからサーバ)と&b(){下り}(サーバからクライアント)に分けて考えると、
2倍の要素になるので&b(){合計6種類}の要素について考える必要があります。
----
***PacketMonitor(R1)が測定していたのは下りのパケットのみです
予想を遙かに超える7,000名超もの方にダウンロードして頂いたPacketMonitor(R1)ですが、
一点根本的な説明をしておりませんでした。
&b(){この段落の題名の通りでございます。}
その理由ですが、上りについては相手が受け取ったか否かを確認する術が無いので、
厳密な測定が出来ないことにあります。
インターネットにて用いられる通信プロトコルとしてはTCP/IPが有名ですが、
リアルタイム性が求められるアクションゲームではTCP/IPではなくUDP/IPなるプロトコルが用いられます。
このプロトコルの重要な特性として「相手に届いたかどうかがわからない」ことが挙げられます。
(この点は必ずしもデメリットだけではなくリアルタイム性を重要視すると実はメリットにもなります)
そのため、上りについてはサーバが受信したかどうかを測定する手段が存在しないため、
無用な機能と考えPacketMonitor(R1)には上りのパケット数測定機能を実装しませんでした。
----
***上りのパケットが「送られた」か否かまでは確認可能
到着したか否かについては不明ですが、出発したか否かまでなら測定可能です。
&b(){6種類の要素別に測定可否を描いてみました}
&image(ClientServerTraffic_20140510.png)
----
***まず下りについて考えてみましょう
①でサーバから送信されたパケットは②の通信回線を経て③でクライアントPCに到達します。
この&b(){③が発生する頻度を測定している}のがPacketMonitor(R1)になります。
そのため、①や②の発生頻度は測定していません。(測定出来ません)
また、パケットロス(③で受信すべきパケットに不足が)発生した場合、
下記2つの原因が考えられますが...
&b(){1.サーバの高負荷などにより①の送信が行われなかった}
&b(){2.通信回線の品質や障害などにより②の過程でロスが発生した}
&b(){この2つのケースのどちらかを特定することは出来ません。}
簡単に申し上げれば、
受け取らなかったのはわかっているが、
途中で行方不明になったのか、そもそも送られなかったのかはわからない。
これが下りの原則になります。
----
***次に上りについて考えてみよう
上りは下りの逆になるだけですので、
④でクライアントPCから送信されたパケットは⑤の通信回線を経て⑥でサーバに到達します。
前述の通りUDP/IPでは相手にパケットが到着したか否かを確認する術が存在しないため、
上りの最終段階である⑥の回数をクライアント側から測定することは出来ません。
また⑤の通信回線上で行方不明になってしまった場合も同様です。
クライアントPCから送信した④の回数までは測定出来ますが、
結果的にサーバに届いたか否かが不明となります。
またクライアントPCの高負荷などが原因で④の送信も出来ないようなケースはまず発生しないと予想しており、
④だけを測定する価値は無いとの判断からPacketMonitor(R1)ではこの機能の実装を見送りました。
----
***PacketMonitorR2で上りのパケット数測定を可能とした理由
単純です。
この記事の一番上に書きましたが「CTEにてパケット数が2倍になった」との情報は
あくまでも「下りのパケットが2倍になった」ことしか測定出来ていません。
だったら上りも測定出来るようにしよう。
これが理由です。
※上りについては前述の通り、サーバに到達したか否かを測定出来ないため、
パケットロスを測定することを目的としておりません。
あくまでも「何回送信しているか」まで測定することが目的です。
----
***PacketMonitorR2の詳細
起動方法などは[[PacketMonitor(R1)>>http://www45.atwiki.jp/goodgames/pages/1250.html]]と同様です。
上り(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のダウンロード
[[こちら>>http://www.goodgames.jp/etc/BF4PacketMonitorR2.zip]]からどうぞ。
ブラウザによっては「怪しいけど本当にいいの?」と聞かれるかもしれません。
----
CTEでは下りが2倍になったとのことですが上りはどうでしょうか...
&b(){2014/06/07追記}
R3リリースに伴いダウンロードURLが変更となりました。
詳細は[[こちら>>http://www45.atwiki.jp/goodgames/pages/1394.html]]を参照願います。
(&Counter())
表示オプション
横に並べて表示:
変化行の前後のみ表示: