我正在使用 QuickFix/J (FIX 4.2) 将订单提交给接受者 FIX 引擎。基本上我需要两个帐户的帮助：
当我第一次尝试与接受者建立连接时，接受者拒绝初始登录请求，说“Msg Seq No too Low”。在此之后，我的发起者继续将传出序列号增加一，当这个序列号增加时。和没有。接受器引擎匹配所期望的，我得到了稳定的连接。为了加快这个过程，我开始提取预期的序列。不。从接受器引擎发送的拒绝消息中，并更改了传出序列号。我的引擎使用
session.setNextTargetMsgSeqNum(expectedSeqNo).但是，稍后，如果我的引擎找到传入的序列号。高于预期，它发送一个重新发送请求。作为响应，另一方发回一个 Sequence Reset msg (35=4, 123=Y)。现在收到这个消息后，传入的序列号。因为我的引擎应该自动设置为它从 Seq Reset msg 收到的那个。但这并没有发生，我的引擎继续要求消息重新发送请求，而传入的序列号没有变化。有趣的是，当我首先没有明确更改传出序列号时（使用 setNextTargetMsgSeqNum），我发现这个东西可以工作。
为什么我的引擎在收到序列重置消息时没有显示预期的行为？
我已经和对方谈过了，他们的配置中不会有 ResetOnLogon=Y。因此，每次我的引擎启动时，它通常都会发送带有 seq no 的登录请求。低于预期（从 1 开始）。有没有更好的方法来快速建立连接？就像我可以以某种方式让我的引擎使用序列号。从它下降之前的点恢复？理想的方法应该是什么？
所以我现在将消息保存在一个处理序列号的文件中。然而，再次令人不安的是，我的快速修复启动器引擎没有响应序列重置消息。现在根本没有管理员回电。
我注意到，当我从一台服务器连接到接受器然后关闭该会话并使用不同的服务器使用相同的会话 ID 连接到接受器时，几乎总是没有响应序列重置消息。一旦登录被接受，我希望一切正常。但是，当另一个引擎将序列重置发送到特定数字（基本上是间隙填充）时，我的修复引擎不会响应它，这意味着它不会重置其预期的序列号并继续向接受者发送重新发送请求。任何帮助将不胜感激！