| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
TCP Connection Management and Problem Handling, the Connection Reset Function, and TCP "Keepalives" (Page 3 of 3) Idle Connection Management and "Keepalive" Messages One final connection management issue in TCP is how to handle an idle connection; that is, a TCP session that is active but that has no data being transmitted by either device for a prolonged period of time. The TCP standard specifies that the appropriate action to take in this situation is nothing. The reason is that, strictly speaking, there is no need to do anything to maintain an idle connection in TCP. The protocol is perfectly happy to allow both devices to stop transmitting for a very long period of time, and then simply resume transmissions of data and acknowledgment segments when either has data to send. However, just as many people become antsy when they are on a telephone call and they dont hear anything for a long while, there was concern on the part of some TCP implementors that a TCP connection that was idle for a very long while might mean that the connection had been broken. Thus, TCP software often includes an unofficial feature that allows a device with a TCP link to periodically send a null segment containing no data to its peer on the connection. If the connection is still valid, the other device responds with a segment containing an acknowledgment; if it is not, the other device will reply with a connection reset segment as described above. These segments sometimes called TCP keepalive messages, or just keepalives. They are analogous to BGP Keepalive messages. The use of these messages is quite controversial, and therefore, not universal. Those who are opposed to them argue that they are not really necessary, and that sending them represents a waste of internetwork bandwidth and a possible additional cost on metered links (those that charge for each datagram sent.) Their key point is that if the connection is not presently being used, it doesnt matter if it is still valid or not; as soon as the connection is used again, if it has broken in the mean time, TCP can handle that using the reset function mentioned above. Worse, sending a keepalive can in theory cause a good TCP session to be unnecessarily broken. This may happen if the keepalive is sent during a time when there is an intermittent failure between the client and server, a failure that might otherwise have corrected itself by the time the next piece of real data must be sent. In addition, some TCP implementations may not properly deal with the receipt of these segments. Those in favor of using keepalives point out that each TCP connection consumes a certain amount of resources, and this can be an issue especially for busy servers. If many clients connect to such a server and dont terminate the TCP connection properly, the server may sit for a long time with an idle connection, using system memory and other resources that could be applied elsewhere. Since there is no wide acceptance on the use of this feature, devices implementing it include a way to disable it if necessary. Devices are also programmed so they will not terminate a connection simply as a result of not receiving a response to a single keepalive. They may do so if they do not receive a reply after several such messages have been sent over a period of time.
Home - Table Of Contents - Contact Us The TCP/IP Guide (http://www.TCPIPGuide.com) Version 3.0 - Version Date: September 20, 2005 © Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved. Not responsible for any loss resulting from the use of this site. |