I have two components that that communicate via TCP/IP. Component A acts as a server/listener and Component B is the client. The two should communicate as quickly as possi
The heart beat is a good way to tell the server that you are alive, whereby i mean that, if server is using DoS attack prevention systems, it (the server) may remove all the allocated resources for that particular connection, after the it detected in-activity for a specified period.
Their no mandate to implement any heartbeat mechanisms.
But its is good if you are designing an application, where the main criteria is responsiveness. You will not like to waste time on connection setups, DNS lookups, and path-discoveries. There just keep a connection up all the time, keep sending heartbeats, and the application knows connection is alive, and connection-setup is not required. Just simple send and receive.
A lot of protocols implement a heartbeat or a health status type of thing like Lloyd said. Just so you know the connection is still open and if you may have missed anything
If your using windows, be cautious about the TCP Keep-alive. By default, its disabled unless you either turn it on globally with the windows registry or via setsockopt.
The default keep-alive interval is 2 hours.
http://msdn.microsoft.com/en-us/library/ms819735.aspx
You might need to implement your own heart beat and disable TCP keep-alive on windows if the 2 hour keep-alive alive is not desirable.
Are heartbeats necessary to keep a TCP/IP connection alive?
They're useful for detecting when a connection has died.
If your components:
then you do not need to have a heartbeat.
If any of these assumptions are false (I am looking at you, GPRS!), a heartbeat becomes necessary rather quickly.
Heartbeat isn't a necessity for TCP protocols. It's implementation is there to detect whether the otherside has terminated the connection in the non standard way (i.e not gone through the tear down process).