1


1

私は数年間問題なく動作しているC#アプリケーションを持っています。 それは私に株式取引執行を送るマシンにTCP / IPソケットを介して接続します。

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

私のアプリ(クライアント側)で接続が切断されたとき、私はソケットを介してデータを受信するのを止めることを除いて珍しいことは何も見ない。 Wiresharkは、データがソケットに到達していないことと、デバッガで停止したときにアプリケーションの受信スレッドがReceive()呼び出しでブロックしていることを確認します。 ソケットはnetstatでESTABLISHEDと表示されます。

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

切断は活動中の期間の後にだけ起こるようです。 私は今のところ私のクライアントと彼らのサーバーの間に20秒ごとに短いメッセージを送って返信を受け取るだけのハートビートを実装することでこれを解決しました。 これにより、過去数日間で切断数が0に減少しました。

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

Windows Server 2003と.NET 3.5を実行しています。 取引サーバーはLinuxマシンです(私はよくわかりませんがsles9と思います)。

何が起こっている可能性がありますかについての任意のアイデア? ファイアウォールのログにアクセスできず、取引サーバーのコードを変更できない場合、これをさらにデバッグするために何ができますか。

ありがとう、マイク

2 Answer


1


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

そのハードウェアは、2160分のハードタイムアウト(私の経験では、20〜30分がより一般的です)を持っているかもしれませんが、接続が何らかの種類の負荷がある場合、通常はるかに積極的に落とされます。 このようなファイアウォールはリソースが限られており、さらに多くの接続追跡が必要な場合は、ハードタイムアウトの設定に関係なく、追跡せずに追跡された最も古い接続をドロップする傾向があります。

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


0


TCP(およびそれより下位のレベル)で何が起こるのかを確認するために、ファイアウォールの両側でwiresharpを設定します。 そして、管理者が「接続のタイムアウト」と言ったときに何かがあります。 アイドル状態の確立された接続のタイムアウトですか。 他には何も意味がありません。

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

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