µC/TCP-IP, in accordance with RFC recommendations, is capable of sending probes, or keep-alive segments, over connections that have been idle for an extended period of time.
How long should a quiet TCP connection – meaning one over which no communication is taking place – remain open? The answer to this question, like many answers in the realm of TCP, depends on the network stack(s) being considered. In Micriµm's µC/TCP-IP, the maximum amount of idle time is a configurable property, and application developers can specify a unique limit for each of their connections.
If the idle-time threshold for a particular connection is reached, µC/TCP-IP is capable of probing the remote side of the connection by sending segments known as keep-alives. The idea of transmitting such segments is raised by RFC 1122, a "request for comment" that, along with many other RFCs, comprises the documentation for the Internet. 1122 states that developers of network stacks "MAY include 'keep-alives' in their TCP implementations." For stacks that provide this feature, the document specifies that application code must be allowed to turn keep-alives "on or off for each connection, and they MUST default to off."
Hewing to this description, µC/TCP-IP offers developers a number of functions to use in configuring keep-alives for each of an application's connections.
NetTCP_ConnCfgTxKeepAliveEn() provides a means of enabling the transmission of keep-alives, while
NetTCP_ConnCfgIdleTimeout() establishes the amount of idle time that must pass before a keep-alive is sent. In the event that no response is received for a keep-alive, additional segments can be transmitted, and the functions
NetTCP_ConnCfgTxKeepAliveRetryTimeout() establish, respectively, the maximum number of such retry attempts made by the stack and the time between attempts.
If the device on the remote side of a connection doesn't respond to any of the keep-alive messages sent by µC/TCP-IP, then the action taken by the stack is to close the connection. The stack is then free to reuse the connection's resources. Any subsequent attempts to send or receive data over the connection by application code would result in error codes from the stack's socket functions.
Just as most of the operations relating to the transmission of keep-alives happen automatically once application code has configured this aspect of the stack, the processing of incoming keep-alives also occurs with minimal application involvement. Given the configurability of µC/TCP-IP, it's certainly possible for a device running the stack to exceed the idle time specified at the remote end of one of its connections and, as a result, receive a keep-alive. In such a scenario, the stack will, without any application intervention, simply send an acknowledgement to the source of the keep-alive, thereby indicating that the connection should be maintained.
While, from a high-level, the concept of keep-alives is relatively simple to explain, the details of how such segments are processed in a TCP/IP stack are beyond the scope of this post. Fortunately, though, one of the benefits of using a stack like µC/TCP-IP is that it mostly makes these details irrelevant to application developers. You can write robust applications around µC/TCP-IP with just a basic understanding of network protocols, and a familiarity with the stack's API functions. For additional information on the latter, including the routines involved in configuring keep-alives, you can consult the stack's on-line documentation.
Matt Gordon is Micrium’s Director of Application Engineering.