▼過去の日記リストへ

「リネ」

〜 ハロウィンイベントマップ 〜

先週はちょっと忙しかったこともあって1週間遅れのスタートという感じ。 さてさてどんな内容？

思い出した、去年と同じでした＾＾ しかし、画面上に50匹以上現われて、ちょっとがんばってみようって思うとか。。 今回は、BOXを楽しむイベントという感じで、それなりに楽しいかも＾＾

で、去年と変わらず、背景バグる場所も健在＾＾ いっそのこと、思いっきりおかしくしてみた＾＾

魔法の残像もくっきり って、そろそろ直さないのかな＾＾

で、最近のイベントは＋８にしないとアイテムが残らないのがいやですね。 b武器とか魔法書とか確かに暴落はしますけど、たまに出てほしいですね。 そんな中、グローブが出たので、私が持っているものより優秀な所もあるので強化してみたら。。

+7まで強化できた！でも結局燃えた・・・ こういうときbZEL使っているから結構赤字になっちゃいますよね〜 まぁ、いい夢を見させてもらいました＾＾

「ドラゴンクエスト10」

〜 サブクエスト消化 〜

最新のセレドのサブクエストをやってみましたよ。 ここのストーリーは結構泣けそうになるいい話なので好きです＾＾ で、SSは。。

月はでているか。 じゃなくて、いや間違っていないが、なんとなく月を撮ってみたらルーラで帰る人とかで絵になっていたみたいな＾＾

ということで、ここからがメイン（前提なが！） 実際にリネでの通信どうなっているのかをWireSharkというツールでモニタリングして結果からどのくらい効果があるか検証して見ました＾＾ モニタリングしたのはイベント中にカボ達にBOXされている時になります＾＾ まずは、データが見やすいダメージを受け続けている状態（サーバからの情報しか来ない場合、攻撃せずにただBOXされている場合） ----------------------------- 「TcpAckFrequency=2(設定なし)」の場合 見かたをわかる人はマニアだけだと思いますので＾＾、サーバからの情報送信に●をつけました。 これはTCPの送受信が時系列で並んでいて、一番左のTimeの列が経過時間、Lengthの列は送信サイズで、一番右のInfoの列に[ACK]と書いてある列がACK(応答)となります。 これを見ると、まずオンラインゲームではやはり1回の送信データが非常に小さく単発になっていることがわかります。(1秒間に1MByte以上送れるのに1KByteも送っていない。) で、サーバは1回情報を送った後、ACKを受信しなければ次のデータを送信しないこともわかりました。 よって、PCは0.2秒(タイムアウト)経ってからACKを返却し、サーバはそれを受け0.03秒後に次のデータを出しています。 つまり、サーバからの情報は0.23秒以上間隔を置いてくることとなります。 「TcpAckFrequency=1(設定あり)」の場合 （※ 全く同じデータを受信しているわけではありませんので送信数は比較対象にはなりません。） これを見ると、サーバからの1回の送信に対して0.2秒かからずにACKを返却しており、サーバも次の送信を早く送信できています。 サーバからの情報は(この区間では)0.04〜0.11秒と間隔が短くなっています。 （ばらつくのは、TCP待ち時間がなくなり、サーバやPCの上位側ソフトの処理/反応時間がそのまま時間に出ている形と思われる。） よって、サーバから送られるmobの移動や攻撃およびダメージがリアルタイムに反映されることとなります。 実際にリネでHPバーを見ていると減り方が細かいのが実感できます。 尚、送信サイズ(Length)を見るとTcpAckFrequency=2のほうが大きいことから、サーバは前回送信時からの変化分をまとめて送っているようで、 間隔が0.23秒であれば0.23秒の間で減ったダメージ量を送る感じで、スタックされて大きく遅延していくということではないようです。） 次に、ダメージを受け続けているときに攻撃をした時の状態（サーバからの情報しか来ない場合） ----------------------------- 「TcpAckFrequency=2(設定なし)」の場合 サーバからの情報送信に●を、PCからの情報送信に●をつけました。 サーバからの1回目の送信後にPCからの情報送信があるとそれ自体がACKの役割もしているため、サーバとしてはすぐ2回目の情報を送信している。 サーバからの2回目の送信後、PCからの情報送信がなければACKは0.2秒後となり、サーバとしては3回目の情報送信が遅延している。 サーバからの3回目の送信後、2回目のPCからの情報送信があります。前回からは0.3秒後となっています。他の箇所においても0.2〜0.3秒ほどとなっていました。 「TcpAckFrequency=1」の場合 こちらは、サーバからの情報送信に即ACKを返却されているためにサーバもクライアントも0.2秒よりも短い間隔でやり取りされています。 PCからの情報送信の間隔は0.07秒。他の箇所においても0.05秒ほどの所が存在。 ここで、設定が違っていても共通する点は、PCからの情報送信後のサーバからの2回目の送信後は何も送らず、サーバからの3回目の送信後に送っている所。 このことから、PCからの情報送信後のサーバからのACK情報は3回目に含まれていて、このACKを受けてPCからの2回目の情報送信が行われていると考えられる。 そうなると、TcpAckFrequency=2の時サーバからの2回目の情報送信に対するACKを返すのに0.2秒かかるため、サーバからの3回目の送信も遅れ、 PCからの2回目の情報送信も遅れが生じることとなる。これが攻撃のラグとなっている原因だと思われます。 ----------------------------- 「まとめ」 TcpAckFrequency=2(設定なし)では、以下のずれが生じる。 ・攻撃モーションやHPの減りのずれ 　サーバからの送信が0.2秒以上間隔を置くためにダメージを受けてからHPが更新されるまでわずかに遅れる場合がある。 　ただ、PCからの送信があるとサーバからすぐ次の情報が送信されるので、HPバーの減りや攻撃モーションなどが不規則に見える原因となっている。 ・攻撃支持の遅れ 　サーバはPCからの送信があると、ACK受信待ちになっているデータを1度送ってから、その次にACKを含むデータを送っている。(ACKを1つ飛ばす。) 　よって、ACK受信待ちになっているデータを送る際に必ず0.2秒以上のACK待ちが発生するために次の情報（攻撃支持等）をすばやく出しても最低0.2秒は待たされてしまう。 　よって、リネでも「TcpAckFrequency=1」とすることで、画面がよりリアルタイムに更新されるようになり、 わずかな攻撃遅延が起こらなくなります。 　尚、上記理屈からは、BOXの量やタイミングによってはACK受信待ち等が発生しない場合もあり、 　TcpAckFrequency=2でも、毎回、表示更新のずれや攻撃支持の遅れが発生するわけでもなく、 　TcpAckFrequency=1(設定なし)に設定してもサーバーやPCの性能やソフトの情報収集間隔に依存して若干ずれは生じます。 「設定した時の悪影響」 　いろんなサイトにはほぼなしと書いていますが。。 　TcpAckFrequency=1にすると、データ送受信の頻度が上がるのでデータ送受信回数が多くなりヘッダの分データ量が若干増えます。 　画面更新も頻繁に行われるので、細かく言えばPCの負荷が上がり、古いPCだと少しちらつきます。また、ほんのわずかだけですが電力が上がります。 　Web更新やファイルダウンロードや(UDPが多いと思いますが)TCPの動画配信など通信量が多い場合に若干少し遅くなります。 　※ っと書いてみましたが、確かにリネほど軽いゲームだと体感できるほどにはならないかもしれませんね。 ※ 実測やネットワークの知識に基づき見解を出していますが、実測結果の標本が少ないこともあり完全にすべてが合っているとは言い切れません。 　ただ実測と理屈が一致する点が多いので、おおむね正しいという見解です。 う〜長いし時間かかった〜〜＾＾ 何でこんなに調べたくなったかって？ 別件だけど、某クラン員に、理屈を知りたがっているのに自分で調べないんだね。って言われたから＾＾；；；；； っていうのは冗談というか、それでなんか久々に調べてみたくなったってことです＾＾