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

问题描述

当我们收到重新发送的消息与新消息/新消息交错时,修复程序(即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,它(错误地?)触发了新的重新发送。

解决方法

暂无找到可以解决该程序问题的有效方法,小编努力寻找整理中!

如果你已经找到好的解决方法,欢迎将解决方案带上本链接一起发送给小编。

小编邮箱:dio#foxmail.com (将#修改为@)

相关问答

Selenium Web驱动程序和Java。元素在(x,y)点处不可单击。其...
Python-如何使用点“。” 访问字典成员?
Java 字符串是不可变的。到底是什么意思?
Java中的“ final”关键字如何工作?(我仍然可以修改对象。...
“loop:”在Java代码中。这是什么,为什么要编译?
java.lang.ClassNotFoundException:sun.jdbc.odbc.JdbcOdbc...