2

我正在尝试找到一种检测连接丢失的好方法。

我的适配器基于示例之一实现为 Fix::Application。它使用套接字启动器连接到修复网关。

当我拔下互联网时，Fix::Application 的 onLogout 方法大约需要 30 秒才能被触发。似乎某些底层类会更早地意识到套接字存在问题。有没有一种快速的方法可以解决这个问题？

4

3 回答 3

4

解决此问题的最佳方法可能是减少您的心跳间隔，以便您更快知道。我不知道任何因 TCP 连接丢失而触发的消息，但我认为 QuickFix 也没有监听操作系统事件。虽然，如果有这样的消息，它可能会通过 fromAdmin 事件。

您是否将问题发布到 QuickFix DL？

于 2009-03-06T00:53:22.950 回答
2

当 TCP 断开连接时，您使用的修复引擎可能不会回调，或者它会回调 onLogout 以外的其他东西。由于您使用的是修复，我猜它会由于错过心跳而强制注销。

快速的方法是查看代码并检查正在处理套接字关闭的位置，以及发生这种情况时执行的路径。

于 2008-11-25T00:46:59.037 回答
1

TCP 本身带有一种称为SO_KEEPALIVE的本机心跳机制。问题是此心跳的默认间隔可能高达 2 小时。这是在操作系统级别配置的。所以理论上你可以开启SO_KEEPALIVE，在OS层面配置合理的心跳间隔，开心就好。但是，因为如上所述这非常依赖于操作系统，所以大多数应用程序选择在应用程序级别实现心跳，FIX 也不例外。减少您的 FIX 心跳间隔是这里的方法，特别是如果您依赖于断开连接时取消，并且额外的未检测到的连接丢失秒数可能会导致不需要的订单执行。在任何修复引擎之上实现的 FIX 网关应该支持开箱即用的心跳配置。看看CoralGateway例如。（免责声明：我是 CoralGateway 的开发者之一）

于 2015-03-30T18:20:25.670 回答