FIX 协议：在重新传输期间接收序列消息导致重新传输循环
FIX Protocol: Receiving out of Sequence Message during retransmission causes loop in retransmission
我有一个使用 QuickFIX/n 作为 FIX 层的修复客户端。
如果由于某种技术原因我的客户端断开连接，FIX 服务器将继续发送消息，直到它注意到客户端不再存在（我假设有心跳）。
当我的客户端重新连接时，它会注意到第一条消息的间隙。例如，如果我的客户端最后收到的消息有 SeqNuM=124，并且在重新连接时服务器发送 SeqNum=152，这意味着服务器在意识到断开连接之前发送了从 125 到 151 的消息。
我的问题发生在之后。我的客户发送一个 Resend 请求 34=2，BeginSeqNo 7=125 和 EndSeqNo=0（给我一切）。在此重传期间和完成之前，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 库处理的，还是我应该在它之上实现一些特定的东西？
深入挖掘后，我们终于发现真正的问题是我的客户一次又一次地请求相同的重传。
例如，如果我有 4000 个序列号，每次出现序列差异时我都会重新发送重传消息（假设每 10 条消息），我最终可能会针对 1000 多条消息询问 500 次平均。
这会在服务器端造成高度紧张，只会让事情变得更糟。
QuickFIX/J 中有一个选项在 QuickFIX/N 中也可用（但未记录在这个选项中）：SendRedundantResendRequests。通过将其设置为 false，您可以确保您的客户端不会两次请求相同的重传。大大降低了服务器的压力，也方便了重连。
我有一个使用 QuickFIX/n 作为 FIX 层的修复客户端。
如果由于某种技术原因我的客户端断开连接，FIX 服务器将继续发送消息，直到它注意到客户端不再存在（我假设有心跳）。
当我的客户端重新连接时，它会注意到第一条消息的间隙。例如，如果我的客户端最后收到的消息有 SeqNuM=124，并且在重新连接时服务器发送 SeqNum=152，这意味着服务器在意识到断开连接之前发送了从 125 到 151 的消息。
我的问题发生在之后。我的客户发送一个 Resend 请求 34=2，BeginSeqNo 7=125 和 EndSeqNo=0（给我一切）。在此重传期间和完成之前，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 库处理的，还是我应该在它之上实现一些特定的东西？
深入挖掘后，我们终于发现真正的问题是我的客户一次又一次地请求相同的重传。
例如，如果我有 4000 个序列号，每次出现序列差异时我都会重新发送重传消息（假设每 10 条消息），我最终可能会针对 1000 多条消息询问 500 次平均。
这会在服务器端造成高度紧张，只会让事情变得更糟。
QuickFIX/J 中有一个选项在 QuickFIX/N 中也可用（但未记录在这个选项中）：SendRedundantResendRequests。通过将其设置为 false，您可以确保您的客户端不会两次请求相同的重传。大大降低了服务器的压力，也方便了重连。