1

私は数年間正常に実行されているC＃アプリケーションを持っています。TCP / IPソケットを介して、株式取引の実行を送信するマシンに接続します。

最近、ハードウェアファイアウォールの背後にある新しいデータセンターの一部のマシンに展開しようとしましたが、奇妙な切断が発生し始めました。

切断が発生すると、私のアプリ（クライアント側）では、ソケットを介したデータの受信を停止することを除いて、異常なことは何も表示されません。Wiresharkは、データがソケットに到達しておらず、デバッガーでアプリケーションを停止すると、Receive（）呼び出しでアプリケーションの受信スレッドがブロックされていることを確認します。ソケットはnetstatでESTABLISHEDとして表示されます。

しかし、サーバー側からは、クライアントが切断されているように見えます。ログを見ると、通常、その端のソケットは（nRecvd = -1、errno = 104）または（nRecvd = 0、errno = 11）のいずれかで終わるように見えます。（104はピアによってリセットされた接続です）。

切断は、非アクティブな期間の後にのみ発生するようです。今のところ、クライアントとサーバーの間にハートビートを実装して、20秒ごとに短いメッセージを送信し、応答を受け取ることで、これを解決しました。これにより、過去数日間で切断が0に低下しました。

最初は、ハードウェアファイアウォールが問題だと思いました。非アクティブになった後、ソケットがタイムアウトする原因でした。しかし、ファイアウォールの担当者は、このポート（8887）での接続のタイムアウトは2160分であると主張しています。

WindowsServer2003と.NET3.5を実行しています。トレードサーバーはLinuxマシンです（sles9はわかりませんが、私は信じています）。

何が起こっているのかについて何かアイデアはありますか？ファイアウォールログにア​​クセスできず、トレードサーバーのコードを変更する機能がない場合、これをさらにデバッグするにはどうすればよいですか？

ありがとう、マイク

4

2 に答える 2

1

あなたが説明したことは一般的であり、ハートビートを実装して、そのようなファイアウォール/ゲートウェイを介してTCPソケットを存続させるのが一般的です。

そのハードウェアには 2160 分のハード タイムアウトがある可能性があります (私の経験では 20 ～ 30 分がより一般的です) が、何らかの負荷がある場合、接続は通常より積極的に切断されます。このようなファイアウォールはリソースが限られているため、より多くの接続追跡が必要な場合、ハード タイムアウトの設定に関係なく、追跡された最も古い接続をアクティビティなしでドロップする傾向があります。

これをさらにデバッグしたい場合は、ファイアウォールのサーバー側を調べて、サーバーが切断されたときに何が起こるかを確認してください。

于 2009-09-10T07:50:28.500 に答える
0

ファイアウォールの両側にワイヤーシャープをセットアップして、TCP (および下位レベル) で何が起こるかを確認します。そして、管理者が「接続のタイムアウト」と言うときは何かです。それは、アイドル状態の確立された接続のタイムアウトですか? それ以外は意味がないと思います。

また、TCP に KeepAlive オプションを使用していますか? そして、それはファイアウォールによって転送されますか?

私が言ったように、おそらくファイアウォールの両側でwiresharkを実行したいでしょう...

于 2009-09-10T03:19:41.560 に答える