Heartbeat (connection keep-alive)

Why connections need them

A network connection can die silently: a router drops it, a laptop sleeps, a firewall forgets it. Without traffic, neither side notices. Heartbeats create traffic on a schedule, so silence beyond the schedule becomes a reliable sign of failure rather than a quiet market.

How the interval works

• The server usually dictates the interval at login.
• The client must send at least that often; sending more often is safe, less often gets the session closed.
• In FIX-style protocols, a missing heartbeat prompts a test request; no answer within another interval closes the connection.
• CME's cancel-on-disconnect uses exactly that logic on order-entry sessions.

Worked example

A gateway asks for a heartbeat every 60 seconds and drops the session after roughly one missed interval. A client that sends at 60-second intervals has a margin of zero; one delayed by a busy moment can be kicked. A watchdog that raises a warning after 5 minutes without any frame corresponds to 300 / 60 = 5 missed intervals, far beyond any quiet-market explanation.

In Senzoukria

After a Rithmic login, the application starts a heartbeat task that sends the protocol's heartbeat request at the interval the gateway returned in its login response, rounding up to at least one second, because sending faster than asked is always safe and sending slower is what gets a session dropped. The task stops before the reader on disconnect. For the PnL and order plants, a separate watchdog logs a warning when no frame at all has arrived for five minutes while the reader still claims to be alive, at most once a minute.

Common mistakes

• Reading a missing heartbeat as a quiet market.
• Suspending the computer or network adapter during a session and expecting the connection to survive.
• Assuming a heartbeat proves data is flowing; it only proves the session is alive.