Detecting TCP server drop

[InfiniteNothing]

In a tcp server-client connection, for example like the TCP Communicator - Passive/Active examples, I'm noticing that if one of the server reboots, the client (active in the examples) never notices. The read function never returns an error 66, it goes about it's life with the normal time out error 56, and waits forever for a message from the server.

I wanted to get some suggestions on if there's a good way to detect this dropped connection.  Ideally, I'd want to do this with a client only fix.

One idea: Make the server send messages even if it has nothing to say. If the client sees the server go dark for too long, it disconnects. I don't particularly like this solution because it requires a watch dog of a sort on the client and that seems inelegant. It also requires a dummy process on the server to keep sending otherwise useless messages.

[Mark_Yedinak]

There is no direct way to detect a connection has been closed on an idle connection. You can either use a heartbeat message as you suggested or simply use an inactivity timer on the client. You don't necessarily need a heartbeat from the server. Set a timer on the client and reset it everytime it sees a message from the server. If no message is received for some set time then reset the connection. You can also detect the loss of the connection when a write from the client fails.

You didn't specify how often or which direction your traffic normally flows. Your solution will depend on which way your traffic normally flows and how frequently you have traffic.

[InfiniteNothing]

Data flows more often from server to client but neither are at regular intervals. It could be 30 minutes between updates from the server.