Do I need to heartbeat to keep a TCP connection open?

Question

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

Answer 1

I would say that if you don't have a heartbeat, it doesn't matter if your TCP/IP connection is open or not.

Answer 2

You don't need to send heartbeats yourself. The TCP connection will remain open regardless of usage.

Note that TCP implements an optional keepalive mechanism, which can be used to identify a closed connection in a timely fashion, rather than requiring you to send data at some later date and only then discover the connection is closed.

Answer 3

TCP will keep the connection alive. The application heartbeats are for application level considerations like failover, load balancing, or alerting administrators to potential problems.

Answer 4

The connection should remain open regardless but yes it's often common to see protocols implement a heartbeat in order to help detect dead connections, IRC with the PING command for example.

Answer 5

TCP/IP as a protocol is specified as not being closed until you send a close packet. I have had sockets remain open even after having spotty wireless or internet connections.

However, this is all very dependent on implementations. Most likely there will be a "timeout" which means the maximum amount of time to wait for a response before considering the connection to be "dead". Sometimes this is based on the application itself, sometimes on NAT routers.

Therefore, I would highly recommend you keep a "heartbeat" to detect bad connections and keep them open.

Answer 6

Basically a TCP connection creates link states stored in switches along to route. In order to detect broken connections (like when one counterpart crashes (without sending a proper disconnect)), these states have to be evicted after a period of inactivity. And when this happens, your TCP connection has been closed. Although I cannot exactly tell how long these timeouts are, they seem to depend on the device-producers and/or on internet providers. I remember my idle SSH terminal sessions were rapidly (less than 15min of idle time) closed by my former 1&1 internet provider while they stayed open for several hours when using a Kabel-BW provided connection...

Finally, I conclude with my previous speakers: a heart-beat is a good way to tell if a connection is still alive and kicking...