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

edccfw

　　Hey gang.  I have just written a client and server inC++ using sys/socket.  I need to handle a situation where the client isstill active but the server is down.  One suggested way to do this is to use a heartbeat to periodically assert connectivity.  And if there isnone to try to reconnect every X seconds for Y period of time, and thento 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 tocheck that there is a connection without messing with the buffer?
　　
　　
down voteaccepted　　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 foryour socket valid in any NAT routers between your client and your server.)
　　Here's a TCP keepalive overviewwhich outlines some of the reasons you might want to use TCP keepalive; this Linux-specific HOWTOdescribes 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_VALSusing 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.), attemptingto 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 youare using (on top of TCP) supports some kind of "do-nothing" request orpacket - 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 andatomicity 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 PerrowJan 30 '09 at 15:56You aren't dependent on or wastingexternal resources. Again, I don't know what the program does, but mostprograms spend more time waiting for user input than they do writing orreading to/from a network. There's no need for the socket to be open atthose times.  – RandolphoJan 30 '09 at 16:28Meh. You're adding extra code and extra work to save yourself one socket. Web browsers usedto 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 PerrowJan 30 '09 at 16:45And 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 thesame socket. – RandolphoJan 30 '09 at 17:18Also, 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". – RandolphoJan 30 '09 at 17:19show 4more comments