What is the best way to implement a heartbeat in C++ to check for socket connectivity?

Hey gang. I have just written a client and server in C++ using sys/socket. I need to handle a situation where the client is still active but the server is down. One suggested way to do this is to use a heartbeat to periodically assert connectivity. And if there is none to try to reconnect every X seconds for Y period of time, and then to time out.

Is this "heartbeat" the best way to check for connectivity?

The socket I am using might have information on it, is there a way to check that there is a connection without messing with the buffer?

 

 

down vote accepted

If you're using TCP sockets over an IP network, you can use the TCP protocol's keepalive feature, which will periodically check the socket to make sure the other end is still there. (This also has the advantage of keeping the forwarding record for your socket valid in any NAT routers between your client and your server.) Here's a TCP keepalive overview which outlines some of the reasons you might want to use TCP keepalive; this Linux-specific HOWTO describes how to configure your socket to use TCP keepalive at runtime. It looks like you can enable TCP keepalive in Windows sockets by setting SIO_KEEPALIVE_VALS using the WSAIoctl() function. If you're using UDP sockets over IP you'll need to build your own heartbeat into your protocol. link | flag

If the other side has gone away (i.e. the process has died, the machine has gone down, etc.), attempting to receive data from the socket should result in an error. However if the other side is merely hung, the socket will remain open. In this case, having a heartbeat is useful. Make sure that whatever protocol you are using (on top of TCP) supports some kind of "do-nothing" request or packet - each side can use this to keep track of the last time they received something from the other side, and can then close the connection if too much time elapses between packets. Note that this is assuming you're using TCP/IP. If you're using UDP, then that's a whole other kettle of fish, since it's connectionless.

Ok, I don't know what your program does or anything, so maybe this isn't feasible, but I suggest that you avoid trying to always keep the socket open. It should only be open when you are using it, and should be closed when you are not.

If you are between reads and writes waiting on user input, close the socket. Design your client/server protocol (assuming you're doing this by hand and not using any standard protocols like http and/or SOAP) to handle this.

Sockets will error if the connection is dropped; write your program such that you don't lose any information in the case of such an error during a write to the socket and that you don't gain any information in the case of an error during a read from the socket. Transactionality and atomicity should be rolled into your client/server protocol (again, assuming you're designing it yourself).

 

What's the advantage of closing and re-opening the socket all the time? –  Graeme Perrow Jan 30 '09 at 15:56 You aren't dependent on or wasting external resources. Again, I don't know what the program does, but most programs spend more time waiting for user input than they do writing or reading to/from a network. There's no need for the socket to be open at those times. –  Randolpho Jan 30 '09 at 16:28 Meh. You're adding extra code and extra work to save yourself one socket. Web browsers used to work this way but it was too slow to keep dropping and re-creating connections. That's why keepalive was added in HTTP/1.1. –  Graeme Perrow Jan 30 '09 at 16:45 And does any modern browser keep the socket open between user requests? No, it does not. Keepalive was added because getting everything involved in a single web page really constitutes a single request and it's therefore better to keep using the same socket. –  Randolpho Jan 30 '09 at 17:18 Also, I think we disagree as to what "extra code and extra work" means. I personally think a program that tries to keep a socket open all the time no matter what is going pretty deep into the realm of "extra code and extra work". –  Randolpho Jan 30 '09 at 17:19 show 4 more comments