是什么导致 QuickFIX/J 中出现“Disconnecting: E​​ncountered END_OF_STREAM”会话消息？

Question

我在Apache Camel 2.17.0 中使用QuickFIX/J版本 1.6.4并且我收到会话消息。这不是错误，但在我的情况下，它会导致无意的Logoff。Disconnecting: Encountered END_OF_STREAM

什么情况会导致此消息，我如何分析我的案例中的哪种情况是原因？

Answer 1

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

基本上它有点像 TCP 连接的“对等连接重置”事件。这意味着连接中断了，而没有用一条Logout消息干净地结束它。

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

例子：

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

来自 FIX 规范（FIX Session Protocol、FIX Session-level Test Cases and Expected Behaviors）：

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

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

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

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

• 如果在登录期间收到第二次连接尝试，而同一 SenderCompID 的有效 FIX 会话已在进行中，则建议会话接受者立即终止第二次连接尝试，而不发送注销消息。发送注销消息存在干扰并可能对当前活动 FIX 连接产生不利影响的风险。例如，在某些 FIX 系统实现中，发送 Logout 消息可能会消耗一个序列号，这会导致已建立的 FIX 会话出现乱序情况。

在所有其他情况下，如果发送注销不会产生风险或违反安全性，则应发送带有描述性文本消息的注销消息。

Answer 2

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

\n\n

\n

最后，原因非常愚蠢\xe2\x80\xa6，我连接的对方一次只允许每个用户/密码（即使用这些凭据的会话）1 个连接。事实证明，有另一个应用程序针对相同的 TargetCompID 使用相同的凭据。该应用程序一被杀死，当前的应用程序就可以正常登录。

\n

\n\n

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

\n