修复协议并重新发送交错的实时消息吗？

如何解决修复协议并重新发送交错的实时消息吗？

当我们收到重新发送的消息与新消息/新消息交错时，修复程序（即quickfix）客户端的正确行为是什么？

我遇到的情况是，我们在登录时检测到大量丢失的消息，msgseqnum比预期的要高。
启动器发出重新发送（开放式）。
收到新的/未经请求的消息并将其放入队列。

有趣的部分是在收到第一个丢失的修复消息后开始的（第一个重新发送的消息为34 = BeginSeqNo）

发生这种情况时，我们的quickfixn启动器端会进入某种模式，并考虑重新发送完成（或某种程度），以及何时 在许多重新发送的消息接收到新的/未经请求的消息后，我们很快就会与重新发送流进行交错，我们的发起方将发送新的重新发送。

此序列继续进行，最终将导致大量并发重发，并且每个重发消息的许多重复填充网络。

由接受者插入实时并重新发送Feed是否正确？

在这种情况下，quickfixn启动器是否应该发送另一个重发消息？
（没有“重新发送完成”消息，因此我可以通过发送新的重新发送来了解其行为，但是已经在进行重新发送了。）

接受者是否应该同时进行并发和重叠重发？

---

编辑/添加问题，因为评论太长。

我们的qfn配置有默认的SendRedundantResendRequests（false），并且在很多“不发送其他邮件”中也有效。

例如参见日志：

20:53:35.087 : Received logon
20:53:35.087 : MsgSeqNum too high,expecting 2999869 but received 3002522
20:53:35.103 : Sent ResendRequest FROM: 2999869 TO: 0
20:53:35.103 : MsgSeqNum too high,expecting 2999869 but received 3002523
20:53:35.103 : Already sent ResendRequest FROM: 2999869 TO: 0.  Not sending another.
 [ very many 'already sent resendrequest' cut away ]
20:53:37.134 : Already sent ResendRequest FROM: 2999869 TO: 0.  Not sending another.
20:53:37.134 : MsgSeqNum too high,expecting 2999869 but received 3004823
20:53:37.134 : Already sent ResendRequest FROM: 2999869 TO: 0.  Not sending another.
20:53:37.134 : MsgSeqNum too high,expecting 2999869 but received 3004824
20:53:37.134 : Already sent ResendRequest FROM: 2999869 TO: 0.  Not sending another.
20:53:37.134 : ResendRequest for messages FROM: 2999869 TO: 0 has been satisfied.
20:53:37.197 : MsgSeqNum too high,expecting 2999877 but received 3004825
20:53:37.197 : Sent ResendRequest FROM: 2999877 TO: 0
20:53:37.197 : ResendRequest for messages FROM: 2999877 TO: 0 has been satisfied.
20:53:37.197 : MsgSeqNum too high,expecting 2999893 but received 3004826
20:53:37.197 : Sent ResendRequest FROM: 2999893 TO: 0
20:53:37.212 : ResendRequest for messages FROM: 2999893 TO: 0 has been satisfied.
20:53:37.244 : Received SequenceReset FROM: 2999893 TO: 2999894
20:53:37.259 : MsgSeqNum too high,expecting 2999905 but received 3004827
20:53:37.259 : Sent ResendRequest FROM: 2999905 TO: 0
20:53:37.259 : ResendRequest for messages FROM: 2999905 TO: 0 has been satisfied.
20:53:37.275 : MsgSeqNum too high,expecting 2999919 but received 3004828
20:53:37.275 : Sent ResendRequest FROM: 2999919 TO: 0
20:53:37.275 : ResendRequest for messages FROM: 2999919 TO: 0 has been satisfied.
20:53:37.275 : MsgSeqNum too high,expecting 2999933 but received 3004829
20:53:37.275 : Sent ResendRequest FROM: 2999933 TO: 0

事件'FROM：2999869 TO：0已被满足'使qfn认为正在进行的重发已完成，并且在下一个'MsgSeqNum太高，期望2999877但收到3004825'的问题下，尽管已经有一个重发，但又发生了重发

这继续，上面的示例给出了多个并发重发。

客户端是否应在3002521之前发送另一个重发请求？

这里发生的是，我们收到了重新发送的消息2999869-2999876，但随后却收到3004825，它（错误地？）触发了新的重新发送。