2

接続の切断を検出する良い方法を見つけようとしています。

私のアダプターは、サンプルの 1 つに基づいて Fix::Application として実装されています。ソケット イニシエーターを使用して修正ゲートウェイに接続します。

インターネットのプラグを抜くと、Fix::Application の onLogout メソッドが起動されるまでに約 30 秒かかります。一部の基になるクラスは、ソケットに問題があることをずっと前に認識しているようです。これにフックした簡単な方法はありますか？

4

3 に答える 3

4

これを解決する最善の方法は、おそらくハートビート間隔を短くして、すぐにわかるようにすることです. TCP 接続が失われたときに発生するメッセージについては知りませんが、QuickFix が OS イベントをリッスンしているとは思いません。ただし、そのようなメッセージがあった場合、fromAdmin イベントを通過する可能性があります。

質問を QuickFix DL に投稿しましたか?

于 2009-03-06T00:53:22.950 に答える
2

TCP が切断されたときに、使用している修正エンジンがコールバックしないか、onLogout 以外でコールバックする可能性があります。修正を使用しているため、ハートビートが失われたためにログアウトが強制されると思います。

簡単な方法は、コードを調べて、ソケットのクローズが処理されている場所と、これが発生したときに実行されるパスを確認することです。

于 2008-11-25T00:46:59.037 に答える
1

TCP 自体には、SO_KEEPALIVEと呼ばれるネイティブのハートビート メカニズムが付属しています。問題は、このハートビートのデフォルトの間隔が 2 時間にもなる可能性があることです。これは、OS レベルで構成されます。したがって、理論的には、SO_KEEPALIVE をオンにして、OS レベルで妥当なハートビート間隔を構成すれば、満足することができます。ただし、前述のようにこれは OS に大きく依存するため、ほとんどのアプリケーションはアプリケーション レベルでハートビートを実装することを選択しており、FIX も例外ではありません。FIX ハートビート間隔を短くすることがここでの方法です。特に、切断時のキャンセルに依存しており、検出されない接続損失の余分な秒数が不要な注文の実行につながる可能性がある場合. 修正エンジンの上に実装された FIX ゲートウェイは、すぐに使用できるハートビート構成をサポートする必要があります。CoralGatewayを見てみましょうたとえば。(免責事項: 私は CoralGateway の開発者の 1 人です)

于 2015-03-30T18:20:25.670 に答える