是什么原因导致QuickFix / J中出现“正在断开连接：遇到了END_OF_STREAM”会话消息？

Question

我正在QuickFix/J 2.17.0内使用Apache Camel版本1.6.4，并收到会话消息Disconnecting: Encountered END_OF_STREAM。这不是错误，但就我而言，它会导致意外的注销。

什么情况下会导致此消息？我如何分析本案中的哪种情况？

Answer 1

由于接受的答案仅涵盖特定于应用程序的行为，因此，我将列出END_OF_STREAM事件的一些可能原因。

基本上，这有点像TCP连接的“对等连接重置”事件。这意味着该连接已断开，而没有以Logout消息结尾。

撇开网络相关的事情，只要对方决定不发送Logout，就会发生这种情况。在大多数情况下，他们不发送注销的原因是出于安全考虑，即交易对手不想透露有关其系统的信息。

示例：

• SSL证书不匹配
• 未知的CompID或会话（即CompID或FIX版本不匹配）
• 重复的CompID（在此特定问题中就是这种情况）
• 序列号太低（尽管像样的FIX引擎会发送Logout来表明这一点）

根据FIX规范（FIX会话协议，FIX会话级测试用例和预期行为）：

何时发送注销与何时断开连接

通常，注销消息始终应在关闭之前发送 断开连接。如果由于错误发送注销信息 条件，“注销”的“文本”字段应提供描述性信息 原因，以便可以对远程FIX系统进行操作支持 诊断问题。

有例外，建议使用 不发送注销消息，这些消息包括：

•如果在登录期间 会话的SenderCompID，TargetCompID或IP地址 启动器无效，建议将会话 立即终止，没有发送注销消息。这次登录尝试 可能是未经授权的尝试侵入您的系统；因此一个 不想泄露有关自己的FIX系统的任何信息，例如 作为：哪些SenderCompID / TargetCompID值有效或哪个版本 支持FIX。

•如果在登录期间有人收到第二秒 有效的FIX会话已经在进行中时尝试连接 相同的SenderCompID，建议会话接受器 立即终止第二次连接尝试，而不发送 注销消息。发送注销消息会产生干扰的风险 与当前的活动FIX一起并可能对其产生不利影响 连接。例如，在某些FIX系统实现中，发送 注销消息可能会消耗可能导致注销的序列号 FIX会话的序列条件的确定。

其他所有 在某些情况下，如果发送注销不会造成风险或违反安全性， 注销消息应与描述性文本消息一起发送。

Answer 2

我在 bhageera 的this blog post中找到了这个问题的答案。

  

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

在我的情况下，具有相同凭据的两个客户端在两个不同的测试环境中处于活动状态。

Answer 3

注意：在 ALL 情况下，除了“序列重置-重置<4>”消息外，如果传入序列号小于预期且未设置PossDupFlag（43），则FIX会话应终止。关闭会话之前，应将带有一些描述性文字的Logout <5>消息发送到另一端。

https://www.onixs.biz/fix-dictionary/fixt1.1/section_message_recovery.html