5

我查看了 FIX v4.2 规范，我不清楚当 TCP 连接在会话中间丢失时应该是什么预期行为。

更具体地说，假设当前序列号为 100，此时 TCP 连接丢失，当任何一方尝试恢复会话时，它会重新发送 100 号消息，还是通过登录开始新的会话？

在描述 FIX 会话时，规范说一个会话有一个登录和一个注销，但可以跨越多个物理连接。这使我认为，当 TCP 连接丢失时，恢复过程不应该以登录消息开始，但我对此并不积极。

提前致谢！

4

2 回答 2

2

FIX 协议没有定义与传输协议相关的任何内容。官方网站上有一些文件只建议如何在这个或那个协议之上实现它，但只是建议。

因此，TCP/IP 断开连接时的预期行为取决于实现。例如，可能有一个根本不关心 TCP/IP 断开连接的系统，这会使这些细节变得无关紧要。在这种情况下，预期的行为将是在重新建立连接后继续发送接收消息，当然如果有的话，继续“恢复”丢失的消息。但实际上，我从未见过这样的系统。

实际上，所有系统都将 TCP/IP 断开连接视为会话的隐式丢失，并期望客户端在重新连接时发送登录信息。

登录时，有两个选项 - 重新连接会话可能会发送下一个传出序列号，或者它可能会要求服务器重置序列（为 1）。在第一种情况下，如果序列大于或等于它的预期，服务器端可以发送登录确认，或者如果接收到的序列号小于预期，则关闭（甚至拒绝）会话。此外，如果序列大于预期，服务器将发出重新传输。客户端会话也监视服务器的序列，如果检测到间隙（接收到的序列大于预期），则需要请求重传。在第二种情况下，如果服务器支持序列重置，则输入和输出序列都重置为 1，并且不会恢复任何消息。

在您的情况下，如果在发送序列号为 100 的消息后连接丢失，则客户端必须重新连接并发送序列号为 101 的登录，然后从那里继续。或者，连接并重置序列，在这种情况下，某些消息可能会丢失。

另外，不要忘记检查您连接的场地的具体情况。可能有一些非常奇怪的细节根本没有被 FIX 协议指定，甚至是那些违反 FIX 协议的细节。例如，ICE（实际上是最脑残的交易所之一）在这方面是最愚蠢的交易所之一——它不允许在前 15 秒内重新连接，然后如果客户端无法连接 30 秒，他们应该切换到故障转移服务器。如果发生故障转移，它们无法保持序列号完整，客户端别无选择，只能重置序列号。

希望它能让你更清楚一点。祝你好运！

于 2013-03-27T16:55:45.550 回答
2

如果传输层是 TCP/IP，我希望会话发起者：

  1. 重新建立套接字连接
  2. 发送新的登录消息

登录消息上使用的序列号取决于会话的类型以及与 FIX 会话接受者达成的协议（有关详细信息，请参阅规范）。对于重播任何手数消息没有价值的会话，例如价格过时的市场数据馈送，发送序列号为 1 的登录消息并设置标签 141=Y（重置序列号）是有意义的。对于可能需要重播消息的订单会话，会话发起者通常应该使用比发送的最后一条消息大 1 的序列号登录（并期望来自 FIX 会话接受者的登录响应，其序列号比最后一条消息大 1收到消息）。

除非您确实需要重播消息，否则每次登录时重新设置序列号会更干净、更容易。这显然取决于 FIX 会话接受器（FIX 服务器）对此的支持。对于 STP 提要之类的东西，我发现这要可靠得多，并且应用程序协议通常更好地提供应用程序级重放设施，而不是依赖 FIX 会话重放的脆弱性。

于 2013-04-06T11:47:17.763 回答