2

我有一个使用 QuickFIX/n 作为 FIX 层的修复客户端。

如果由于某种技术原因我的客户端断开连接，FIX 服务器将继续发送消息，直到它注意到客户端不再存在（我假设有心跳）。

当我的客户端重新连接时，它会注意到第一条消息的间隙。例如，如果我的客户端最后收到的消息 SeqNuM=124 并且在重新连接时服务器发送 SeqNum=152，这意味着服务器在意识到断开连接之前将消息从 125 发送到 151。

我的问题发生在之后。我的客户发送一个重新发送请求 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 库处理的，还是我应该在它之上实现一些特定的东西？

4

1 回答 1

1

当进一步挖掘时，我们终于发现真正的问题是我的客户一次又一次地要求相同的重传。

例如，如果我在 4000 个序列号之外，并且每次出现序列差异时（假设每 10 条消息）我都会重新发送一条重传消息，我最终可能会要求 500 次平均超过 1000 条以上的消息。

这会在服务器端产生高度紧张，只会让事情变得更糟。

QuickFIX/J 中有一个选项，QuickFIX/N 中也有一个选项（但在这个选项中没有记录）SendRedundantResendRequests：. 通过将其设置为false您确保您的客户端不会要求两次相同的重传。这极大地降低了服务器的压力并简化了重新连接。

于 2020-03-15T11:04:54.420 回答