How to detect TCP disconnections faster

[lzsssr]

Hello,
When a TCP connection is disconnected, the application layer relies on heartbeat detection to discover the disconnection and perform reconnection. If the counterparty only accepts a fixed heartbeat interval, how can we achieve second-level disconnection detection?
Is it possible to define a connection health check task?

[chrjohn]

What do you mean? When the session is disconnected, the initiator tries to reconnect immediately, independent from the configured HB interval.
Or maybe I misunderstood your question. Could you please elaborate?

[lzsssr]

For example, if a firewall change causes a TCP connection to be disconnected, session does not know that it has been disconnected and has to rely on heartbeat detection to find out, so is it possible to implement a faster detection method than heartbeat?

[chrjohn]

If it's disconnected, then it's disconnected. That should be reported immediately. Or do you rather receive a connection timeout?
Do you have messages from your log that show what you mean?

[lzsssr]

Sorry, let me rephrase that.If the underlying TCP connection is accidentally disconnected (e.g., unplugged, server crashes), but the sessionClosed() callback is not triggered, Quickfixj is unaware of it until the heartbeat timeout. Is it possible to implement a second-by-second TCP connection disconnection awareness mechanism in this case?
log like this:
outgoing:35 -- FIX.4.2:TB->FL: 8=FIX.4.2 35=D 52=20250528-21:31:40.546 56=FL ... 10=095

**outgoing**:35 -- FIX.4.2:TB->FL: 8=FIX.4.2 **35=1** 52=20250528-21:31:52.390 56=FL ... 10=186

**outgoing**:35 -- FIX.4.2:TB->FL: 8=FIX.4.2 **35=D** 52=20250528-21:32:05.546 56=FL .... 10=095
**outgoing**:35 -- FIX.4.2:TB->FL: 8=FIX.4.2 **35=D** 52=20250528-21:32:45.546 56=FL .... 10=095

**Disconnecting: Timed out waiting for heartbeat**
**MINA session created**

 **outgoing**:35 -- FIX.4.2:TB->FL: 8=FIX.4.2 **35=A** 52=20250528-21:32:47.546 56=FL .... 10=095
 **incoming**:35 -- FIX.4.2:TB->FL: 8=FIX.4.2 **35=A** 52=20250528-21:32:47.646 56=FL .... 10=095

[chrjohn]

I am not entirely sure to be honest but I believe the time it takes to detect such a timeout on the network is configured on OS level. When that timeout is larger than the HB interval, you'll have to wait for the HB to timeout.