我正在尝试找到一种检测连接丢失的好方法。
我的适配器基于示例之一实现为 Fix::Application。它使用套接字启动器连接到修复网关。
当我拔下互联网时，Fix::Application 的 onLogout 方法大约需要 30 秒才能被触发。似乎某些底层类会更早地意识到套接字存在问题。有没有一种快速的方法来解决这个问题？
【问题讨论】：
标签： c++ sockets connectivity quickfix fix-protocol
当 TCP 断开连接时，您使用的修复引擎可能不会回调，或者它会回调除 onLogout 之外的其他内容。 由于您正在使用修复程序，我猜它会由于错过心跳而强制注销。
快速的方法是查看代码并检查正在处理套接字关闭的位置，以及发生这种情况时执行的路径。
【讨论】：
解决此问题的最佳方法可能是减少您的心跳间隔，以便您更快知道。我不知道任何因 TCP 连接丢失而触发的消息，但我认为 QuickFix 也没有监听操作系统事件。虽然，如果有这样的消息，它可能会通过 fromAdmin 事件。
您是否将问题发布到 QuickFix DL？
【讨论】：
TCP 本身带有称为SO_KEEPALIVE 的本机心跳机制。问题是此心跳的默认间隔可能高达 2 小时。这是在操作系统级别配置的。所以理论上你可以开启SO_KEEPALIVE，在OS层面配置合理的心跳间隔，开心就好。但是，因为如上所述这非常依赖于操作系统，所以大多数应用程序选择在应用程序级别实现心跳，FIX 也不例外。减少您的 FIX 心跳间隔是这里的方法，特别是如果您依赖于断开连接时取消，并且额外的未检测到的连接丢失秒数可能会导致不需要的订单执行。在任何修复引擎之上实现的 FIX 网关应该支持开箱即用的心跳配置。以CoralGateway 为例。 （免责声明：我是 CoralGateway 的开发者之一）
【讨论】：