我正在编写一个接受器应用程序并使用一个持久的 FIX 会话。我正在尝试编写一个恢复模式，这样如果我离线或我的程序重新启动，当我重新连接时，我想重新处理白天发送给我的所有消息以恢复到当前状态。
为此，当我启动时，我向服务器发送所有消息的重新发送请求。他们把所有相关的消息都给我开回去了，它们被标记为 possdupflag=Y 和 possresend=Y。在每条消息之前，它们会为即将发送的重复消息发送序列重置。
问题是，这些消息似乎没有被我的消息破解者处理。 fromAdmin 和 fromApp 都不会收到这些消息。我认为由于 dup 标志和/或重新发送，它们被忽略了。那么有没有办法告诉 QuickFIX 我想要看到这些消息？
关于这一点 - 如果有人对更好的恢复过程有任何建议，我会向他们开放。
谢谢。
【问题讨论】：
标签： quickfix fix-protocol
这种恢复策略至少存在几个潜在问题。首先是它对你的交易对手不是很友好。如果您在会话期间仅收到少量消息，那么这可能不是问题，但如果您收到数十万条消息，那么您的交易对手可能会抱怨大量重发。
另一个问题是消息重发旨在恢复错误并由会话协议层管理。在 QuickFIX/J（和其他 FIX 引擎）中，除了在检测到序列号间隙时自动发送 ResendRequest 之外，会话还保持恢复状态。如果您将下一个预期的传入序列号重置为 1，您的方法可能会起作用。当会话接收到具有更高序列号的下一条消息时，它将检测间隙并请求丢失的消息。如果消息通过验证，它们将被转发到设置了 PossDup 标志的应用层。如果您自己发送 ResendRequest 消息，则行为未定义，因为会话状态未正确设置。
我建议使用 MessageLog 实现将传入的消息存储在一种可用于在应用程序启动时进行恢复的形式中。大家可以看看现有的消息日志（FileLog、JdbcLog）的实现来获得一些思路。
【讨论】：
出现这种行为是因为引擎的持久性系统告诉它收到的消息是重新发送的消息，因此（根据 FIX 协议规范）被丢弃。在这里，我们将 FIXml 字符串保存到我们的数据库中，以提供与您描述的类似的恢复能力（由于其他原因，它们也被写入磁盘上的 xml 文件）。我不相信有任何方法可以告诉 quickfix 你想查看重复的消息，但最好使用不同的形式或持久性来节省连接开销。 Quickfix 确实提供了一种将消息输出到文件的方法，如果有帮助的话。
【讨论】：
我也有同样的问题，弗兰克说的是绝对正确的， 只需使用以下方法将目标序列号设置为所需重新发送请求的开始序列号。
getSession()->setNextTargetMsgSeqNum(atoi(seq.c_str()));
引擎内部识别出目标号码太大并自动发送重发请求，所有消息都会像往常一样在onMessage回调中被捕获
【讨论】：