3

クライアントとサーバー間のTCP接続を使用するミッションクリティカルなリアルタイムデータアプリケーションがあります。場合によっては、接続が定期的に停止します（SocketException）。問題ありません。再接続して先に進んでください。ただし、これらの断続的な接続の低下に顧客はわくわくしません。

指をどこに向けたらいいのか知りたいのですが。それはクライアントですか、それともサーバーですか？ハードウェアまたはソフトウェア？それはイーサネットリンクについての何かですか？最終的には、接続の状態を示すインジケーターがユーザーに表示されるため、不良リンクを調査して修正できます。

TcpClient、Socket、または接続の状態について教えてくれる他の何かからプルできるメトリックはありますか？おそらく、確認までの平均時間、再試行回数などですか？

特に、イーサネット接続全体だけでなく、TCP接続について知りたいです（LAN接続はダンディかもしれませんが、外部サーバーへの接続に問題がある可能性があります）。

もちろん、リモートホストにpingを実行することはできますが、それによって、探している種類の統計情報が実際に得られるとは思いません。一つには、サーバーがNATの背後に隠れている場合、ルーターにpingを実行している可能性があります。

4

2 に答える 2

5

まず、取得している SocketExceptions の詳細を調べる必要があります。.Net では何が含まれているかわかりませんが、Java では詳細なメッセージに「ピアによって接続が閉じられました」や「接続がリセットされました」などのヒントが表示されます。

私の経験では、ソケット接続がドロップされる一般的な原因は、読み取りタイムアウト例外が他のすべての接続関連の例外と同じ catch 句によって処理されるコードのバグであり、通常、正当な理由もなく接続が閉じられます。 .

企業のセットアップでは、長時間の TCP 接続が閉じられる一般的な原因は、ファイアウォール アプライアンスがトラフィックのない TCP 接続を (たとえば 10 分後に) 閉じたり、トラフィックに関係なく、たとえば 30 分後に経過時間に達した後に接続を閉じたりすることです。 . 一般に、これらのことが起こると想定し、正常に接続を再確立する準備をすることをお勧めします。

適切なアプローチは、接続クローザーにパターンがあるかどうかを確認することです。たとえば、定期的に閉鎖するか、一定時間活動がない場合に閉鎖するかなどです。また、パケット スニファーを実行して、どちらの側が接続のシャットダウンを開始したか、RST パケットを送信したか、およびその理由を確認することもできます。

于 2008-10-15T22:46:03.620 に答える
1

Perfmon はあなたの友達です。すべての IP、TCP、およびネットワーク カウンターのログを実行してください。いつ接続が切断されたかがわかれば、グラフを調べて、ネットワーク エラー、転送なし、IO バイト転送なしなど、何かがあるかどうかを確認できます。

GC、メモリ、CPU 使用率など、いくつかの .NET カウンターも追加します。

最後にできることは、TCP タイムアウトとその他の設定を増やすことです。それらはレジストリにあります

本当にリモート サーバーに問題がある場合は、両端を監視する必要がありますが、カウンターを確認することから始めて、何かが飛び出すかどうかを確認します。

于 2008-10-15T21:49:31.693 に答える