1

quickfixj 启动器正在断开连接：在尝试登录接受器时遇到 END_OF_STREAM。我们使用供应商的修复引擎作为接受者。来自接受者的反馈是未接受 xxxx 的登录请求，传入太小，期望 305，收到 27。

我阅读了 quickfix 文档，但没有完全了解序列号不匹配的正确解决方案是什么。我知道如果我断开连接，我的发起者将发送一个 35=4 进行重新发送，发起者端 seqnum 要求接受者重新发送消息并填补空白。但是在什么情况下，如果发起者发送较低的 seqnum 将被接收者拒绝并拒绝连接？处理这种拒绝和重新连接的正确程序是什么？为了不丢失任何消息，双方应该如何重置并填补空白？如果发起者和接受者之间有中断，建议的解决方案是什么来保持消息同步而不丢失任何消息？

4

2 回答 2

1

由于您问题的第一句话，我想向您展示同一错误消息的答案 Disconnecting: Encountered END_OF_STREAM。引用了bhageera的一篇博文。

最后，原因很愚蠢……我连接的交易对手一次只允许每个用户/密码（即使用这些凭据的会话）进行 1 个连接。事实证明，有另一个应用程序对相同的 TargetCompID 使用相同的凭据。一旦该应用程序被终止，当前的应用程序就可以正常登录。

我搜索了一段时间的错误原因，直到我意识到我有两个具有相同凭据的启动器在两个不同的测试环境中运行。

于 2019-10-10T14:52:12.877 回答
0

根据 QuickfixJ 中的默认逻辑： QuickfixJ 管理 2 个序列号，expectedSeqNum 接收（targetSeqNum）和 nextSeqNumber 发送。

根据收到的 SeqNum 检查下一个预期目标 SeqNum。如果检测到不匹配，应用以下逻辑：

  • 如果低于预期的 SeqNum，则退出
  • 如果更高，则发送重新发送请求

在您的情况下，收到的数据低于预期，因此它会断开连接。

接收高于预期的 SeqNum 的原因：接收方错过了一些消息，因此这可能是正常情况。

SeqNum 低于预期的原因（您的情况）：交易对手之一重置其序列号，预计不应由双方同意。

在正常情况下，每当您错过消息时，您将收到一个更高的数字，并且它将由 QuickFixJ 管理。

于 2018-06-13T16:57:07.437 回答