QuickFIX/J 中出现“Disconnecting: Encountered END_OF_STREAM”会话消息的原因是什么？

Question

我在 Apache Camel 2.17.0 中使用 QuickFIX/J 版本 1.6.4，我收到会话消息

Disconnecting: Encountered END_OF_STREAM

。这不是错误，但就我而言，它会导致无意的Logoff.

什么情况会导致此消息？我如何分析我的情况是什么情况？

Answer 1

由于接受的答案仅涵盖特定于应用程序的行为，因此我将列举

END_OF_STREAM

事件的一些可能原因。

基本上它有点像 TCP 连接的“连接重置”事件。这意味着连接中断，但没有以

Logout

消息干净地结束它。

撇开与网络相关的事情不谈，只要交易对手决定不发送

Logout

，就会发生这种情况。大多数情况下，他们不发送注销的原因是出于安全考虑，即交易对手不想透露有关其系统的信息。

例子：

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

  Logout

  表明这一点）

正如@macemers 所建议的那样，交易对手的另一个特定于应用程序的问题可能是他们的 FIX 引擎以某种方式卡住了。这最终将导致突然断开连接，因为另一方无法处理消息或回复心跳消息。

来自 FIX 规范（FIX 会话协议、FIX 会话级测试用例和预期行为）：

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

一般情况下，应始终在关闭之前发送注销消息 断开连接。如果由于错误而发送注销 条件，注销的文本字段应提供描述性 原因，以便远程 FIX 系统的操作支持可以 诊断问题。

也有例外，推荐的时候 不发送注销消息，包括：

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

• 如果在登录期间收到第二个 一个有效的 FIX 会话已经在进行时的连接尝试 同样的SenderCompID，建议session acceptor 立即终止第二次连接尝试并且不发送 注销消息。发送注销消息有干扰的风险 对当前活动的 FIX 有并可能产生不利影响 联系。例如，在某些 FIX 系统实现中，发送一个 注销消息可能会消耗一个序列号，这会导致退出 已建立的 FIX 会话的顺序条件。

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

Answer 2

我在bhageera的这篇博文中找到了这个问题的答案。

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

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

Answer 3

注意：在 ALL 情况下，除了序列重置 - Reset<4> 消息，如果传入序列号小于预期且 PossDupFlag(43) 未设置，则 FIX 会话应终止。在关闭会话之前，应向另一方发送带有一些描述性文本的注销<5>消息。

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