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