my_*_*ion 5 quickfix fix-protocol
我查看了 FIX v4.2 规范，我不清楚当 TCP 连接在会话中间丢失时应该是什么预期行为。
更具体地说，假设当前的序列号是 100 并且此时 TCP 连接丢失，当任何一方尝试恢复会话时，它重新发送消息号 100，或者启动一个新的登录会话？
在描述 FIX 会话时，规范说一个会话有一个登录和一个注销，但可以跨越多个物理连接。这让我认为当 TCP 连接丢失时，恢复过程不应该以登录消息开始，但我对此并不乐观。
提前致谢！
小智 2
FIX协议没有定义任何与传输协议相关的内容。官方网站上有一些文档仅建议如何在这个或那个协议之上实现它，但只是建议。
\n\n因此，TCP/IP 断开连接时的预期行为取决于实现。例如，有可能有一个系统根本不关心 TCP/IP 断开连接，这将使这些细节变得无关紧要。在这种情况下，预期的行为是在重新建立连接后继续发送接收消息，当然继续执行丢失消息的 \xe2\x80\x9crecovery\xe2\x80\x9d（如果有）。但实际上，我从未见过这样的系统。
\n\n实际上，所有系统都将 TCP/IP 断开连接视为隐式会话丢失，并期望客户端在重新连接时发送登录信息。
\n\n登录时，有两个选项 \xe2\x80\x94 重新连接会话可能会发送下一个传出序列号，或者可能会要求服务器重置序列（为 1）。在第一种情况下，如果序列号大于或等于预期的序列号，服务器端可以发送登录确认，或者如果接收到的序列号小于预期的序列号，则关闭（甚至拒绝）会话。此外，如果序列大于预期，服务器将发出重传。客户端会话也监视服务器的序列，如果检测到间隙（接收到的序列大于预期），则需要请求重新传输。在第二种情况下，如果服务器支持序列重置，则输入和输出序列都将重置为 1，并且不会恢复任何消息。
\n\n在您的情况下，如果在发送序列号为 100 的消息后连接丢失，客户端将必须重新连接并发送序列号为 101 的登录信息，然后从那里继续。或者，连接并重置序列，在这种情况下，某些消息可能会丢失。
\n\n另外，不要忘记检查您连接的地点的具体信息。可能存在 FIX 协议根本没有指定的非常奇怪的细节，甚至是那些违反 FIX 协议的细节。例如，ICE（实际上是最脑残的交易所之一）是这方面最愚蠢的交易所之一\xe2\x80\x94它不允许\xe2\x80\x99在前15秒内重新连接，并且那么如果客户端在 30 秒内无法连接，则应切换到故障转移服务器。如果发生故障转移，它们无法保持序列号完整，客户端别无选择，只能重置序列号。
\n\n希望它能让你的事情变得更清楚一些。祝你好运！
\n