我查看了FIX v4.2规范，我不清楚在会话中间丢失TCP连接时它应该是什么样的预期行为。TCP连接丢失时的预期行为是什么？
更具体地说，假设当前的序列号是100，并且此时TCP连接丢失，当任何一方试图恢复会话时，它重新发送消息号码100，或者通过登录启动新会话？
在描述FIX会话时，规范说一个会话有一个登录和一个注销，但可以跨越多个物理连接。这导致我认为，当TCP连接丢失时，恢复过程不应该以登录消息开始，但我对此不积极。
在此先感谢！
FIX协议没有定义任何与传输协议相关的内容。官方网站上有一些文件只提出了如何在该协议或该协议的基础上实施它，但只是建议。
因此，TCP/IP断开情况下的预期行为取决于实施。例如，有可能有一个系统根本不关心TCP/IP断开连接，这会使这些细节无关紧要。在这种情况下，预期的行为将是在连接重新建立后继续发送接收消息，并且当然继续“恢复”丢失的消息（如果有的话）。但事实上，我从来没有见过这样的系统。
实际上，所有系统都将TCP/IP断开视为会话的隐式丢失，并希望客户端在重新连接时发送登录。
登录时，有两个选项 - 重新连接会话可能会发送下一个出站序列号，或者它可能会要求服务器重置序列（至1）。在第一种情况下，如果序列大于或等于预期的值，服务器端可能会发送登录确认，如果收到的序列号小于预期，则关闭（甚至拒绝）会话。此外，如果序列大于预期，服务器将发出重新传输。客户端会话也会监视服务器的顺序，并且如果检测到间隙（接收顺序比预期更大），则需要请求重新传输。在第二种情况下，如果服务器支持序列重置，则输入和输出序列都将重置为1，并且不会恢复任何消息。
对于您的情况，如果在发送序列号为100的消息后连接丢失，则客户端必须重新连接并发送序列101的登录，然后从该处继续。或者，连接并重置序列，在这种情况下，某些消息可能会丢失。
此外，不要忘记检查你连接到的场地的具体情况。可能有非常奇怪的细节，完全不是由FIX协议规定的，甚至是那些违背FIX协议的细节。例如，ICE（实际上是最常见的脑死亡交易所之一）是这方面最愚蠢的交易之一 - 它不允许在15秒内重新连接，如果客户端无法连接30秒，他们应该切换到故障转移服务器。如果发生故障转移，它们无法保持序列号的完整性，并且客户没有选择，只能重置序列号。
希望它让事情变得更清晰一点。祝你好运！
如果传输层是TCP/IP，我希望本届会议的引发剂到：
序列号在登录消息上使用取决于会话的类型以及与FIX会话接受者达成一致的内容（请参阅规范以了解详细信息）。对于重放任何批量消息没有价值的会话，例如在价格过低的市场数据馈送中，发送序列号为1的登录消息并设置标签141 = Y（重置序列号）是有意义的。对于可能需要重播消息的订单会话，会话发起者通常应该使用比发送的最后一条消息大的序列号登录（并期望来自FIX会话接受器的序列号大于最后1的登录响应收到消息）。
除非您确实需要重播消息，否则每次登录时都会重置序列号更清晰，更容易。这显然取决于FIX会话接受器（FIX服务器）对此的支持。对于像STP提要这样的东西，我发现这样做要可靠得多，而且应用程序协议通常更适合提供应用程序级别的重播功能，而不是依赖于FIX会话重播的脆弱性。