QuickFIX/J 中出现 "Disconnecting: Encountered END_OF_STREAM" 会话消息的原因是什么？
What causes the "Disconnecting: Encountered END_OF_STREAM" session message in QuickFIX/J?
我正在使用 QuickFIX/J version 1.6.4 within Apache Camel 2.17.0，我收到了会话消息 Disconnecting: Encountered END_OF_STREAM。这不是错误，但就我而言，它会导致无意的 Logoff.
什么情况会导致出现此消息？我该如何分析我的情况是哪种情况导致的？
我在 this blog post 中找到了这个问题的答案 bhageera。
In the end the reason was pretty silly… the counterparty I was connecting to allows only 1 connection per user/password (i.e. session with those credentials) at a time. As it turns out there was another application using the same credentials against the same TargetCompID. As soon as that application was killed off, the current one logged in fine.
就我而言，两个具有相同凭据的客户端在两个不同的测试环境中处于活动状态。
NOTE: In ALL cases except the Sequence Reset - Reset<4> message, the FIX session should be terminated if the incoming sequence number is less than expected and the PossDupFlag(43) is not set. A Logout<5> message with some descriptive text should be sent to the other side before closing the session.
https://www.onixs.biz/fix-dictionary/fixt1.1/section_message_recovery.html
由于已接受的答案仅涵盖特定于应用程序的行为，因此我将列出 END_OF_STREAM 事件的一些可能原因。
基本上它有点像 TCP 连接的 "connection reset by peer" 事件。这意味着连接断开，但没有以 Logout 消息干净地结束它。
撇开与网络相关的事情不谈，只要交易对手决定不发送 Logout，就会发生这种情况。大多数情况下，他们不发送注销的原因是出于安全考虑，即交易对手不想泄露有关其系统的信息。
示例：
- SSL 证书不匹配
- 未知的 CompID 或会话（即 CompID 或 FIX 版本不匹配）
- 重复的 CompID（在这个特定问题中就是这种情况）
- 序列号太低（虽然一个体面的 FIX 引擎会发送一个
Logout 来表明这一点）
来自 FIX 规范（FIX 会话协议、FIX 会话级测试用例和预期行为）：
When to send a Logout vs. when to just disconnect
In general a Logout message should always be sent prior to shutting
down a connection. If the Logout is being sent due to an error
condition, the Text field of the Logout should provide a descriptive
reason, so that operational support of the remote FIX system can
diagnosis the problem.
There are exceptions, when it is recommended
that a Logout message not be sent, these include:
• If during a logon
either the SenderCompID, TargetCompID or IP address of the session
initiator is invalid, it is recommended that the session be
immediately terminated and no Logout message sent. This login attempt
might be an unauthorized attempt to break into your system; hence one
does not want to divulge any information about one’s FIX system, such
as: which SenderCompID/TargetCompID values are valid or which version
of FIX is supported.
• If during a Logon one receives a second
connection attempt while a valid FIX session is already underway for
that same SenderCompID, it is recommended that the session acceptor
immediately terminate the second connection attempt and not send a
Logout message. Sending a Logout message runs the risk of interfering
with and possibly adversely affecting the current active FIX
connection. For example, in some FIX system implementations, sending a
Logout message might consume a sequence number that would cause an out
of sequence condition for the established FIX session.
In all other
cases, if sending a Logout does not create risk or violate security, a
Logout message should be sent with a descriptive text message.
我正在使用 QuickFIX/J version 1.6.4 within Apache Camel 2.17.0，我收到了会话消息 Disconnecting: Encountered END_OF_STREAM。这不是错误，但就我而言，它会导致无意的 Logoff.
什么情况会导致出现此消息？我该如何分析我的情况是哪种情况导致的？
我在 this blog post 中找到了这个问题的答案 bhageera。
In the end the reason was pretty silly… the counterparty I was connecting to allows only 1 connection per user/password (i.e. session with those credentials) at a time. As it turns out there was another application using the same credentials against the same TargetCompID. As soon as that application was killed off, the current one logged in fine.
就我而言，两个具有相同凭据的客户端在两个不同的测试环境中处于活动状态。
NOTE: In ALL cases except the Sequence Reset - Reset<4> message, the FIX session should be terminated if the incoming sequence number is less than expected and the PossDupFlag(43) is not set. A Logout<5> message with some descriptive text should be sent to the other side before closing the session.
https://www.onixs.biz/fix-dictionary/fixt1.1/section_message_recovery.html
由于已接受的答案仅涵盖特定于应用程序的行为，因此我将列出 END_OF_STREAM 事件的一些可能原因。
基本上它有点像 TCP 连接的 "connection reset by peer" 事件。这意味着连接断开，但没有以 Logout 消息干净地结束它。
撇开与网络相关的事情不谈，只要交易对手决定不发送 Logout，就会发生这种情况。大多数情况下，他们不发送注销的原因是出于安全考虑，即交易对手不想泄露有关其系统的信息。
示例：
- SSL 证书不匹配
- 未知的 CompID 或会话（即 CompID 或 FIX 版本不匹配）
- 重复的 CompID（在这个特定问题中就是这种情况）
- 序列号太低（虽然一个体面的 FIX 引擎会发送一个
Logout来表明这一点）
来自 FIX 规范（FIX 会话协议、FIX 会话级测试用例和预期行为）：
When to send a Logout vs. when to just disconnect
In general a Logout message should always be sent prior to shutting down a connection. If the Logout is being sent due to an error condition, the Text field of the Logout should provide a descriptive reason, so that operational support of the remote FIX system can diagnosis the problem.
There are exceptions, when it is recommended that a Logout message not be sent, these include:
• If during a logon either the SenderCompID, TargetCompID or IP address of the session initiator is invalid, it is recommended that the session be immediately terminated and no Logout message sent. This login attempt might be an unauthorized attempt to break into your system; hence one does not want to divulge any information about one’s FIX system, such as: which SenderCompID/TargetCompID values are valid or which version of FIX is supported.
• If during a Logon one receives a second connection attempt while a valid FIX session is already underway for that same SenderCompID, it is recommended that the session acceptor immediately terminate the second connection attempt and not send a Logout message. Sending a Logout message runs the risk of interfering with and possibly adversely affecting the current active FIX connection. For example, in some FIX system implementations, sending a Logout message might consume a sequence number that would cause an out of sequence condition for the established FIX session.
In all other cases, if sending a Logout does not create risk or violate security, a Logout message should be sent with a descriptive text message.