5

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

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

4

3 回答 3

9

由于接受的答案仅涵盖特定于应用程序的行为，因此我将列出该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 会话出现乱序情况。

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

于 2020-03-09T14:32:52.437 回答
3

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

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

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

于 2019-10-10T14:41:54.927 回答
0

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

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

于 2020-02-12T16:32:53.730 回答