ソケット通信の送受信遅延-02 その後

前回のNo.1031658 「ソケット通信の送受信遅延」に追加させてもらいます


その後、プロトコルアナライザで現状調査を行い以下の現象を確認しました
◇正常時
　サーバがメッセージ送信
　TCPヘッダ内フラグ ACK:1, PSH:1　+ 送信データあり
↓
　0.2msec前後で クライアントが 返信
　TCPヘッダ内フラグ ACK:1, PSH:1 + 返信データあり
↓
　10msecで サーバが送信
　TCPヘッダ内フラグ ACK:1, PSH:1　+ 送信データあり
↓
　0.2msec前後で クライアントが 返信
　TCPヘッダ内フラグ ACK:1, PSH:1 + 返信データあり
↓
　　　　　　　　　以下繰り返り

◇不具合時
　サーバがメッセージ送信
　TCPヘッダ内フラグ ACK:1, PSH:1　+ 送信データあり
↓
　0.2msec前後で クライアントが 返信
　TCPヘッダ内フラグ ACK:1, PSH:1 + 返信データあり
↓
　10msecで サーバが送信
　TCPヘッダ内フラグ ACK:1, PSH:1　+ 送信データあり
↓
　約130msec前後で クライアントが 返信
　TCPヘッダ内フラグ ACK:1, PSH:0 + 返信データなし
↓
　約250msec前後で クライアントが 返信
　TCPヘッダ内フラグ ACK:1, PSH:1 + 返信データあり
↓

といった状況です　どう解釈すれば良いのでしょうか
遅延の原因はソケットなのかそれ以外なのでしょうか？是非アドバイスをおねがいします。

No.2 ベストアンサー 回答者： MASATO3 回答日時： 2004/10/08 18:55

クライアント側の問題ではないかと思われます。

でもクライアントのソフトはメッセージに応答するだけのソフトで他に何もしないソフトなんですよね。

とするとプロトコルスタックに原因がありそうですね・・・。
もしそうだとすると、OS内部のことなので、手が出にくい場所です。

以下のような観察を行うともうちょい原因が絞り込めるかもしれません(原因を絞り込んでも解決は難しそうですが)。
・クライアントがWindowsXPで動いているのでしたらQoSを切ってみてどうなるか観察する。
・OSそのものを変えてみて状況が変わるか観察する
・送信データ量を減らしてみて挙動を観察する。

この回答への補足

すみませんがQoSのきり方をサルでもわかるように教えていただけないでしょうか
よろしくお願いしますm(__)m

補足日時：2004/10/09 09:37

この回答へのお礼

何度も回答本当にありがとうございます。涙が出る程心強いです。
MASATO3さんのアドバイスに従って観察してみます。
とりあえずQoSとは何か調べます。

お礼日時：2004/10/08 21:29

No.3 回答者： MASATO3 回答日時： 2004/10/10 17:31

> QoSのきり方

WindowsXPであれば、
マイ ネットワークのプロパティ
→ローカル エリア接続のプロパティ
から操作できます。

また、状況が改善するかもしれない方法を挙げておきます。
まだ原因が分かっていませんので手間をかけて改造した結果無駄に終わる可能性もあり、あまり勧めはしません。
・TCPではなくUDPを使う
・TCPでもソケットを非ブロッキングモードではなくブロッキングモードで使う

この回答への補足

何度も丁寧な回答ありがとうございます。教えて頂いたとおりQoSを切ってみましたが、パケットのやり取りが止まってしまいました。他の方法も試してみます。
またお気づきの点がありましたら、
「WindowsプロセスにおけるQoSのきり方」http://oshiete1.goo.ne.jp/kotaeru.php3?q=1034671
までおねがいします。

補足日時：2004/10/15 19:09

No.1 回答者： MASATO3 回答日時： 2004/10/07 21:56

不具合時の各パケットに番号をつけます。

(1)サーバがメッセージ送信
　TCPヘッダ内フラグ ACK:1, PSH:1　+ 送信データあり
(2)0.2msec前後で クライアントが 返信
　TCPヘッダ内フラグ ACK:1, PSH:1 + 返信データあり
(3)10msecで サーバが送信
　TCPヘッダ内フラグ ACK:1, PSH:1　+ 送信データあり
(4)約130msec前後で クライアントが 返信
　TCPヘッダ内フラグ ACK:1, PSH:0 + 返信データなし
(5)約250msec前後で クライアントが 返信
　TCPヘッダ内フラグ ACK:1, PSH:1 + 返信データあり

(3)と(4)の間に、「(3)をクライアントが受信」という現象があるはずですが、

これは(3)の0.2msec程度後でしょうか？
もしそうならば、クライアント側の問題です。

それとも(3)の130msec程度後でしょうか？
もしそうならば、ネットワークの低い層(物理層とかデータリンク層)の問題です。

不具合時のシーケンス番号とACK番号はどのようになっているかが分かるともっと色々なことが分かりそうです。

仮にクライアントの問題だったとします。、
前の質問を見るに、CAsyncScoketつかって非ブロッキングモードで通信をしていると思うのですが、
クライアント側で描画処理やその他何か重たい処理を行って、300msくらいメッセージループに戻らないことがあるでしょうか？
もしそういうときがあるとしたらそこが原因の可能性があります。

この回答へのお礼

丁寧な回答ありがとうございます。とても困っているのに困り度を1にしてしまって、回答が来ないんじゃないかと心配していました。本当にありがとうございます。

>(3)と(4)の「(3)をクライアントが受信」は
　(3)の0.2msec程度後です。

>不具合時のシーケンス番号とACK番号はどのようになっているかが分かるともっと色々なことが分かりそうです

　体験版アナライザ使用のため記録がないので、調べてみます

>クライアント側で描画処理やその他何か重たい処理を行って、300msくらいメッセージループに戻らないことがあるでしょうか？

応答メッセージ作成のみで1msec以内で処理は完了していることをログで確認済みです

ちなみにこの不具合はサーバがメッセージを送信してクライアントからの返信を受信するまでを1トランザクションとして
5000トランザクションに1度程度発生します
この程度なら我慢しなさいとおっしゃりたいでしょうが是非なんとかしたいのです。
とにかく本当に回答ありがとうございます

お礼日時：2004/10/07 22:53