quickfix - 是什么导致 QuickFIX/J 中的“断开连接：遇到 END_OF_STREAM”会话消息？

Question

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

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

标签： quickfixfix-protocolquickfixjcamel-quickfix

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 会话出现乱序情况。

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