Guardian and Guard Server listen for each other's heartbeat. If a component (Guardian or Guard Server) misses a heartbeat but continues to receive data from the other component, it ignores the missed heartbeat. However, if the application receives no data or heartbeats for a complete heartbeat cycle (approximately seven seconds), it continues to listen but starts a “disconnect countdown.”
- If the application misses four consecutive heartbeats (approximately 28 seconds) and does not receive any data from the peer application, it considers the connection terminated.
- If the application receives new data or heartbeats before it misses four consecutive heartbeats, the disconnect countdown stops.
If machines in your TT system repeatedly disconnect from the Guard Server for no apparent reason, refer to Logging Heartbeats. For further information on what happens during a failure, refer to the appropriate section below, Guardian Disconnect or Guard Server Disconnect.
For further resiliency, TT applications produce heartbeats when an instance of Guardian or a Guard Server fails. These heartbeats function as Guardian and Guard Server heartbeats respectively in maintaining connectivity:
- Guardian failure: When Guardian fails, the Client APIs (Fill, Price, and Order) send their own heartbeats instead
- Guard Server failure: When Guard Server fails, the other TT Gateway server components send heartbeats (one for each component).
After a disconnect countdown completes, Guardian disconnects from that TT Gateway. However, Guardian remembers its connection and, for as long as Guardian is open, continues to listen for the heartbeat from Guard Server. If Guardian receives a heartbeat from a TT Gateway with the same exchange name, it automatically attempts to reconnect. If Guardian successfully reconnects, the client application (e.g., X_TRADER®) immediately downloads all fills and orders from the TT Gateway.