Checking TCP Connections

Submitted by isabel on Mon, 03/11/2019 - 09:24

The following three configurations are related to detecting issues on the TCP connections. Although they seem similar, they enable different features with subtle differences.

Connection Liveliness

When the Connection Liveliness feature is enabled, RTI TCP Transport Liveliness Request and Response packets will be exchanged in order to check if the control TCP connection is not alive. This traffic allows for the detection of a control connection that is not alive anymore and proceeds to close it. This feature is a client-side feature, so the client will be the one sending the requests and expecting the responses from the server.

Since it is only applicable to the control TCP connection, Connection Liveliness will only detect issues that affect the TCP control connection (for example, when the cable is unplugged, bringing down the control connection). If a TCP connection that is not the control one fails, Connection Liveliness will not detect it.

You can find more information in the section “Connection Liveliness” in the RTI Connext DDS Core Libraries User’s Manual.

KEEP_ALIVE

KEEP_ALIVE is a feature supported by the OS. When KEEP_ALIVE is enabled, a packet will be sent to the remote peer through TCP and if a given time passes (the keep-alive time) without data being sent or received (the connection is idle, which triggers the keepalive timer) it will detect if the connection is healthy or not. This feature is implemented only on some architectures that support the TCP keep-alive feature. This feature is supported in both the client and server, but it is OS-dependent.

You will find more information about enabling KEEP_ALIVE in the “Properties for NDDS_Transport_TCPv4_Property_t” table in the RTI Connext DDS Core Libraries User’s Manual.

TCP user timeout

Starting in 5.2.0, a new feature called TCP User timeout (UTO, https://tools.ietf.org/html/rfc5482) was made available in some Linux architectures (Linux 2.6.37 and higher platforms). When using this property, Connext DDS sets the maximum timeout it will wait for a socket to deliver the pending bytes to send. If the socket connection does not progress sending bytes before the expiration of that time, the connection will be closed, allowing the server to communicate with another client.

The above three features are complementary. They can be enabled at the same time and provide different benefits:

  • KEEP_ALIVE and UTO occur at the TCP level. They are OS-dependent, while Connection Liveliness occurs at the RTI-TCP transport level and is supported in every architecture.

  • KEEP_ALIVE and UTO are supported in both client and server. Connection Liveliness is supported only in the client.

  • KEEP_ALIVE and UTO work for all TCP connections, whereas Connection liveliness detects issues only with the TCP control connection.

  • KEEP_ALIVE applies only to connections that are idle. Connection Liveliness applies to any connection state (for example, when the connection is ESTABLISHED and it has bytes in the sending queue, so the retransmission timer is “on" and the keepalive timer is disabled). UTO applies to connections that have pending bytes to send.

In summary:

  • UTO is focused on detecting a connection that is not progressing sending bytes.

  • KEEP_ALIVE is focused on detecting that a connection is not alive, so available resources can be released.

  • Connection Liveliness is able to detect connection issues for both connections with pending bytes to send and connections without pending bytes to send/receive (idle), but it is only supported in the client and only for the control TCP connection.

Product:
Keywords: