如何让QuickFix处理来自重发请求的消息？

Question

我正在编写一个接受器应用程序并使用持久性FIX会话。我正在尝试编写一个恢复模式，这样如果我离线或我的程序重新启动，当我重新连接时，我想重新处理在白天发送给我的所有消息，以恢复到当前状态。

为此，当我启动时，我向服务器发送所有消息的重发请求。他们向我发回所有相关信息，并标记为possdupflag = Y和possresend = Y.在每条消息之前，它们会为他们即将发送的重复消息发送序列重置。

问题是，我的消息破解者似乎没有处理这些消息。 fromAdmin和fromApp都没有收到这些消息。我认为它们因为dup标志和/或重发而被忽略。那么有没有办法告诉QuickFIX我想要看到这些消息？

就此而言 - 如果有人对更好的恢复过程有任何建议，我会向他们开放。

感谢。

Answer 1

此恢复策略至少存在一些潜在问题。首先，它对您的交易对手不是很友好。如果您在会话期间只收到少量消息，那么这可能不是问题，但如果您收到数十万条消息，那么您的对手方可能会抱怨大量重播。

另一个问题是消息重发旨在用于错误恢复，并由会话协议层管理。在QuickFIX / J（和其他FIX引擎）中，除了在检测到序列号间隙时自动发送ResendRequest，会话还保持恢复状态。如果将下一个预期的传入序列号重置为1，则您的方法可能有效。当会话收到具有更高序列号的下一条消息时，它将检测间隙并请求丢失的消息。如果消息经过验证，它们将被转发到设置了PossDup标志的应用层。如果您自己发送ResendRequest消息，则行为未定义，因为会话状态将不会正确设置。

我建议使用MessageLog实现将传入的消息存储在您可以在应用程序启动时用于恢复的表单中。您可以查看现有消息日志（FileLog，JdbcLog）的实现，以获得一些想法。

Answer 2

行为发生的原因是引擎的持久性系统告诉它收到的消息是重新发送的消息，因此（根据FIX协议规范）被丢弃。在这里，我们将FIXml字符串保存到我们的数据库中，以提供与您描述的相似的恢复能力（出于其他原因，它们也被写入磁盘上的xml文件）。我不相信有任何方法可以告诉quickfix您希望看到重复的消息，但最好使用不同的表单或持久性来节省连接开销。 Quickfix确实提供了一种在邮件进入时将文件输出到文件的方法。如果有帮助的话。

Answer 3

我也有同样的问题，弗兰克说的是绝对正确的， 只需使用以下方法将目标序列号设置为所需重发请求的开始序号。

 getSession()->setNextTargetMsgSeqNum(atoi(seq.c_str()));

引擎在内部识别出目标数量太大并自动发送重发请求，并且所有消息都将像往常一样在onMessage回调中捕获