アクセプター FIX エンジンに注文を送信するために、QuickFix/J (FIX 4.2) に取り組んでいます。基本的に、次の 2 つのアカウントについてサポートが必要です。
アクセプターとの接続を初めて確立しようとすると、アクセプターは「Msg Seq No too Low」という最初のログオン要求を拒否します。この後、私のイニシエーターは発信シーケンス番号を 1 ずつインクリメントし続けます。そしていいえ。アクセプターエンジンの一致が期待されているため、安定した接続が得られます。このプロセスを高速化するために、予想される seq の抽出を開始しました。番号。アクセプターエンジンによって送信された拒否メッセージから、発信シーケンス番号を変更しました。私のエンジンの使用
session.setNextTargetMsgSeqNum(expectedSeqNo).ただし、後で、エンジンが着信シーケンス番号を見つけた場合。予想よりも高い場合、再送信リクエストを送信します。それに応じて、相手はシーケンス リセット メッセージ (35=4、123=Y) を返します。このメッセージを受信した後、着信 seq no. 私のエンジンは、Seq Reset msg から受け取ったものに自動的に設定されるはずです。しかし、これは起こらず、私のエンジンは受信シーケンス番号を変更せずにメッセージの再送信要求を要求し続けます。興味深いのは、(setNextTargetMsgSeqNum を使用して) 最初に発信シーケンス番号を明示的に変更しない場合に、このことが機能することを発見したことです。
シーケンス リセット メッセージを受信したときに、エンジンが予期した動作を示さないのはなぜですか?
相手方と話しましたが、構成に ResetOnLogon=Y が含まれていません。そのため、エンジンが起動するたびに、seq no. を含むログオン要求を送信することがよくあります。予想より低い (1 から開始)。接続をすばやくセットアップするためのより良い方法はありますか? どうにかしてエンジンにシーケンス番号を使用させることができますか。落ちる直前から再開？理想的なアプローチは何ですか？
そのため、シーケンス番号を処理するファイルにメッセージを永続化しています。ただし、ここでも厄介なのは、私のクイックフィックス イニシエーター エンジンがシーケンス リセット メッセージに応答しないことです。現在、管理者のコールバックはまったくありません。
あるサーバーからアクセプターに接続し、そのセッションを閉じて、同じセッション ID を使用して別のサーバーを使用してアクセプターに接続すると、ほとんどの場合、シーケンス リセット メッセージへの応答がないことに気付きました。ログオンが受け入れられたら、問題なく動作することを期待しています。ただし、他のエンジンがシーケンス リセットを特定の番号に送信している間 (基本的にはギャップ フィル)、私の修正エンジンはそれに応答しません。つまり、予想されるシーケンス番号をリセットせず、アクセプターに再送信要求を送信し続けます。どんな助けでも大歓迎です！