QuickFIX/n を FIX レイヤーとして使用する修正クライアントがあります。
何らかの技術的な理由でクライアントが切断された場合、FIX サーバーは、クライアントが存在しないことに気付くまでメッセージを送信し続けます (ハートビートがあると思います)。
クライアントが再接続すると、最初のメッセージのギャップに気付くでしょう。たとえば、クライアントが最後に受信したメッセージに SeqNuM=124 があり、再接続時にサーバーが SeqNum=152 を送信した場合、サーバーが切断を認識する前に 125 から 151 にメッセージを送信したことを意味します。
私の問題は後で起こります。私のクライアントは、BeginSeqNo 7=125 および EndSeqNo=0 で再送信要求 34=2 を送信します (すべてを提供してください)。この再送信中および終了する前に、FIX サーバーは SeqNo=153 の新しいメッセージを送信します
私のクライアントが得るものは次のとおりです。
- Disconnects with last message 124
- Reconnects
- Receive 151
- Ask for Resend from 125 to 0 (everything after 125)
- Receive 125
- Receive 126
- Receive 127
- Receive 152 (35=8) <-- this makes the retransmission abort on my side
- Ask For resend from 128 to 0
---> if the number of message to resend is too high and new messages keep coming in
my client never manages to get the full retransmission in one go.
相手 (サーバーの責任者) と話していると、再送信中に新しいメッセージを送信し続けても問題ないので、再送信が完了するまでメッセージをキャッシュする必要があるとのことです。
QuickFIX/n がこれを実装した方法ではないようですが (この特定のケースを処理するオプションが見つかりませんでした)、FIX ドキュメントを見ると、このキャッシュ手順に関する情報が見つかりません。また、このキャッシュ手順は非常に複雑であると思います。これは、おそらく特定の時間キャッシュする必要があるためです (そうしないと、失われたメッセージを永遠に待つ可能性があります)。
私の質問は簡単です: このキャッシュ手順とは何ですか? また、その仕様はどこにありますか? そして、これは QuickFIX ライブラリによって処理されますか、それともその上に特定のものを実装する必要がありますか?