【MoE】不正落ちスレ2【NET減少】
244 ：名無しオンライン：
【Moe】対人の戦術、バランス、改善案を語る その13
ttp://live19.2ch.net/test/read.cgi/ogame3/1151393773/
より
967 名前：名無しオンライン[sage] 投稿日：2006/07/10(月) 22:22:41.19 ID:uoN6gPNM
・・・本当に知らないで煽ってるんですかね。
MoEの場合、衝突判定は相手のクライアントで行う。
で、相手クライアント→サーバー（リフレクタ）までの
通知にUDPプロトコルを使っていたので、相手がPCの帯域
制限器でロス率高に設定すれば、いとも簡単に判定を消す
ことができる。モーションも消せる。これがいわゆる「絞り」。
で、今は1本のTCPに全て載るようになったので、絞るとTCPの
輻輳制御アルゴリズムが働いて、極端にレート落ちる。
またTCPにはロスという概念がなく、PC側のFIFOに溜まって
再送という制御を行うため、レートが落ちすぎるとタイムアウト
するし、レートが回復すれば溜まっていたものが一気に流れる。
ゆえにパケットロスを利用することができないので、選択的に
判定だけを消すことはできない。これが「同期改善パッチ」の効果。
970 名前：名無しオンライン[sage] 投稿日：2006/07/10(月) 22:35:28.64 ID:uoN6gPNM
で、ですね。
本隊戦で種の判定でねえ！とか、ゾーンではなく密集した
フィールドでＬＤしやすくなったとか、しばらく無敵かと
思ったら立て続けに攻撃判定出て一挙に死亡〜なんてのは
全てサーバーサイドのTCP輻輳制御で説明できまする。
本来、TCPの方がUDPより負荷高いし、総通信量も増えます。
特に何百本も同時に張っているような場合は、スイッチの
テーブル溢れが深刻な問題になります。
データセンター側強化しないでこのパッチ入れるのは
けっこう自殺行為だと思うんですけどね・・・
971 名前：名無しオンライン[sage] 投稿日：2006/07/10(月) 22:37:52.32 ID:QQQ9mtLK
でもこのゲームでは判定を消すのも
単純にラグい人たちも両方絞りって言われるのよね
972 名前：名無しオンライン[sage] 投稿日：2006/07/10(月) 22:42:11.33 ID:O9U6Zu+U
スイッチがヤバイってのは結構前から言われてたことだな。
俺はパッチの内容詳しくチェックしてないんだが、
通信関係が本当にTCPベースになったのかぁ。
973 名前：名無しオンライン[sage] 投稿日：2006/07/10(月) 22:42:26.95 ID:mMzjysv/
よくわからんが専門用語並べられても分からん人には説得力がないんだが
結局それって推論なわけでしょ？ 尚更よくわからん
974 名前：名無しオンライン[sage] 投稿日：2006/07/10(月) 22:45:16.91 ID:FCDu9NIh
ちょっとずれる質問だが聞いてくれ。
サーバ（リフレクタ）ってあるんだが、
これどういうこと？
リフレクタってルートリフレクタのことじゃないのけ？
あれは単にAS経路情報伝播してるだけじゃないん？
ttp://live19.2ch.net/test/read.cgi/ogame3/1151393773/
より
967 名前：名無しオンライン[sage] 投稿日：2006/07/10(月) 22:22:41.19 ID:uoN6gPNM
・・・本当に知らないで煽ってるんですかね。
MoEの場合、衝突判定は相手のクライアントで行う。
で、相手クライアント→サーバー（リフレクタ）までの
通知にUDPプロトコルを使っていたので、相手がPCの帯域
制限器でロス率高に設定すれば、いとも簡単に判定を消す
ことができる。モーションも消せる。これがいわゆる「絞り」。
で、今は1本のTCPに全て載るようになったので、絞るとTCPの
輻輳制御アルゴリズムが働いて、極端にレート落ちる。
またTCPにはロスという概念がなく、PC側のFIFOに溜まって
再送という制御を行うため、レートが落ちすぎるとタイムアウト
するし、レートが回復すれば溜まっていたものが一気に流れる。
ゆえにパケットロスを利用することができないので、選択的に
判定だけを消すことはできない。これが「同期改善パッチ」の効果。
970 名前：名無しオンライン[sage] 投稿日：2006/07/10(月) 22:35:28.64 ID:uoN6gPNM
で、ですね。
本隊戦で種の判定でねえ！とか、ゾーンではなく密集した
フィールドでＬＤしやすくなったとか、しばらく無敵かと
思ったら立て続けに攻撃判定出て一挙に死亡〜なんてのは
全てサーバーサイドのTCP輻輳制御で説明できまする。
本来、TCPの方がUDPより負荷高いし、総通信量も増えます。
特に何百本も同時に張っているような場合は、スイッチの
テーブル溢れが深刻な問題になります。
データセンター側強化しないでこのパッチ入れるのは
けっこう自殺行為だと思うんですけどね・・・
971 名前：名無しオンライン[sage] 投稿日：2006/07/10(月) 22:37:52.32 ID:QQQ9mtLK
でもこのゲームでは判定を消すのも
単純にラグい人たちも両方絞りって言われるのよね
972 名前：名無しオンライン[sage] 投稿日：2006/07/10(月) 22:42:11.33 ID:O9U6Zu+U
スイッチがヤバイってのは結構前から言われてたことだな。
俺はパッチの内容詳しくチェックしてないんだが、
通信関係が本当にTCPベースになったのかぁ。
973 名前：名無しオンライン[sage] 投稿日：2006/07/10(月) 22:42:26.95 ID:mMzjysv/
よくわからんが専門用語並べられても分からん人には説得力がないんだが
結局それって推論なわけでしょ？ 尚更よくわからん
974 名前：名無しオンライン[sage] 投稿日：2006/07/10(月) 22:45:16.91 ID:FCDu9NIh
ちょっとずれる質問だが聞いてくれ。
サーバ（リフレクタ）ってあるんだが、
これどういうこと？
リフレクタってルートリフレクタのことじゃないのけ？
あれは単にAS経路情報伝播してるだけじゃないん？
|
|
|
245 ：名無しオンライン：2006/07/13(木) 12:41:03.93 ID:g5OZKqxT
975 名前：名無しオンライン[sage] 投稿日：2006/07/10(月) 22:46:58.81 ID:xMsPFv/X
NET値がどんどん下がっていって切断されるから
体感だとそういう処理していると思う
正確なことを知るにはTCPとUDPのデータ流量を見るとわかりそうだ
976 名前：名無しオンライン[sage] 投稿日：2006/07/10(月) 22:50:47.94 ID:O9U6Zu+U
>>973
相当端折って説明すると、
信頼性が低いけど高速な通信の方法から
信頼性が高いけど低速な通信の方法に変更したんだけど、
その方法は今までに比べて負荷が高くて通信量も多いので、
鯖がパンク寸前になっちゃってLD多発したりしてるってこと。
当たり判定が妙なのとは別の話な。
978 名前：名無しオンライン[sage] 投稿日：2006/07/10(月) 22:53:16.73 ID:FCDu9NIh
いましらべたら確かにTCPつかってるね
UDPでの利用ポートが増えたようには見えない
netstat -a
979 名前：名無しオンライン[sage] 投稿日：2006/07/10(月) 22:54:28.74 ID:uoN6gPNM
プロトコルに関しては、Snifferというツールで
通信時の挙動調べた結果からの推測なんで、
大体正しいとは思っています。
ただデータセンター側は正直わからんですね。
同接でいえば高々2000くらいだと思うんですが、
なんでこんなに滞るのか・・・
>>974 いえフロントエンド鯖側のリフレクタです。
（１）1つ1つのクライアントからFE鯖へ状態報告
（２）同一ゾーンFE鯖内に集約
（３）全クライアントにTCPで同報
という仕組みだったと思います。以前のプロトコルでは。
981 名前：名無しオンライン[sage] 投稿日：2006/07/10(月) 22:57:37.47 ID:uoN6gPNM
長文申し訳ない。ただ、以前のような安易な絞りは
今のプロトコルではできません、これだけ言いたかった。
それでも当たらないのは例の未来像判定による原因が大半で、
ここ直せれば神パッチだと思います。
以上。
985 名前：名無しオンライン[sage] 投稿日：2006/07/10(月) 23:25:50.84 ID:mrqBSxSJ
>>967
禿同。プロトコルU017制御システムの変更によってクライアントによるサーバー制御の
プロセスが恒久的なシステムTCPクライアントレートとなってFIFOPDCA01側のPCによる
処理がよりアルゴリズム的になり、タイムアウトを防ぐためにレート回復の基本的な
処理パケットのロスを消去することで、より効率的なプロセス処理がTCP→FIFOできるようになる訳だな。
激しく納得した。
NET値がどんどん下がっていって切断されるから
体感だとそういう処理していると思う
正確なことを知るにはTCPとUDPのデータ流量を見るとわかりそうだ
976 名前：名無しオンライン[sage] 投稿日：2006/07/10(月) 22:50:47.94 ID:O9U6Zu+U
>>973
相当端折って説明すると、
信頼性が低いけど高速な通信の方法から
信頼性が高いけど低速な通信の方法に変更したんだけど、
その方法は今までに比べて負荷が高くて通信量も多いので、
鯖がパンク寸前になっちゃってLD多発したりしてるってこと。
当たり判定が妙なのとは別の話な。
978 名前：名無しオンライン[sage] 投稿日：2006/07/10(月) 22:53:16.73 ID:FCDu9NIh
いましらべたら確かにTCPつかってるね
UDPでの利用ポートが増えたようには見えない
netstat -a
979 名前：名無しオンライン[sage] 投稿日：2006/07/10(月) 22:54:28.74 ID:uoN6gPNM
プロトコルに関しては、Snifferというツールで
通信時の挙動調べた結果からの推測なんで、
大体正しいとは思っています。
ただデータセンター側は正直わからんですね。
同接でいえば高々2000くらいだと思うんですが、
なんでこんなに滞るのか・・・
>>974 いえフロントエンド鯖側のリフレクタです。
（１）1つ1つのクライアントからFE鯖へ状態報告
（２）同一ゾーンFE鯖内に集約
（３）全クライアントにTCPで同報
という仕組みだったと思います。以前のプロトコルでは。
981 名前：名無しオンライン[sage] 投稿日：2006/07/10(月) 22:57:37.47 ID:uoN6gPNM
長文申し訳ない。ただ、以前のような安易な絞りは
今のプロトコルではできません、これだけ言いたかった。
それでも当たらないのは例の未来像判定による原因が大半で、
ここ直せれば神パッチだと思います。
以上。
985 名前：名無しオンライン[sage] 投稿日：2006/07/10(月) 23:25:50.84 ID:mrqBSxSJ
>>967
禿同。プロトコルU017制御システムの変更によってクライアントによるサーバー制御の
プロセスが恒久的なシステムTCPクライアントレートとなってFIFOPDCA01側のPCによる
処理がよりアルゴリズム的になり、タイムアウトを防ぐためにレート回復の基本的な
処理パケットのロスを消去することで、より効率的なプロセス処理がTCP→FIFOできるようになる訳だな。
激しく納得した。
246 ：名無しオンライン：2006/07/13(木) 12:41:18.76 ID:g5OZKqxT
988 名前：名無しオンライン[sage] 投稿日：2006/07/11(火) 00:08:53.93 ID:Ks7h8QON
>>985
それはちょっと違うんじゃないか？FIFOシステムの基本的なアルゴリズムは
TCPクライアントによるものだから、タイムアウト処理をUDPにすることによる利点
の方が大きい。これによりボトルネックだったリフレクションはデータ量を制御することが
可能となり、経路伝達によるロスをなくす事が可能となる。よって
ルートリフレクタのスイッチがTCPになったと仮定した場合の処理効率が格段に
上昇する訳だ。ただしこれによる伝達ロスはFEサーバーサイドの負荷として
扱われるため、送通信量が増え、結果的にUDPデータのタイムアウトが発生し、
スイッチのテーブル溢れとなる訳だ。これが「搾り」の基本的な要因となる。
そこでこの対処のためにテーブルサーバーのアルゴリズムをUDPから
FIFOシステムとすることで、輻輳制御リコールレイションアルゴリズムが働く。
これが、パケットロスを無くす為の最も有効な手段として取り入れられているのが、
今回の同期改善パッチの内容として有力なのではないかと私は考えるがどうだろう？