I want to verify the connection status before realize my operations (read/write).
Is there a way to make an isConnect() method?
I saw this, but it seems "ugly".
I tested is_open() function also, but doesn't have the expected behavior.
Thanks
A:
you can send a dummy byte on a socket and see if it will return an error.
vehomzzz
2009-10-02 18:37:17
But what happens to the other end when it receives this dummy byte if you are connected. That's not a good solution.
jmucchiello
2009-10-02 18:52:15
Usually this sort of application have concept of heartbeat send periodically. Moreover, on windows (win32) doesn't have a way to check the connection reliably, and boost::asio::ip::tcp::socket would be implemented on top of it. @jmucchiello -- if you have ever worked on a distributed systems, you would have known that connection is always checked via a heartbeat, which is typically a byte. Hope this helps the OP.
vehomzzz
2009-10-02 19:25:31
There is one problem, i don't know the behavior on the server side.The solution that i found, is call connect before operations and check error condition.
coelhudo
2009-10-02 19:45:16
You need to know the server's protocol (look in the documentation or ask a vendor); Trying to connect can be very expensive.
vehomzzz
2009-10-02 20:00:09
Andrei: His socket could be the client side of a HTTP/1.1 Keep Alive connection. Does that protocol have a "send a byte" heartbeat? I've only been working with distributed systems for 20+ years and not all of them have heartbeats. Some of them, like HTTP/1.1, use a "reconnect on error" method. Your answer says "send a dummy byte" without including any of the caveats found in your comments. It is not the correct answer. Your comment says "you need to know the protocol". Please make this your actual answer as the current one is flawed.
jmucchiello
2009-10-02 21:33:17
A:
TCP promises to watch for dropped packets -- retrying as appropriate -- to give you a reliable connection, for some definition of reliable. Of course TCP can't handle cases where the server crashes, or your Ethernet cable falls out or something similar occurs. Additionally, knowing that your TCP connection is up doesn't necessarily mean that a protocol that will go over the TCP connection is ready (eg., your HTTP webserver or your FTP server may be in some broken state).
If you know the protocol being sent over TCP then there is probably a way in that protocol to tell you if things are in good shape (for HTTP it would be a HEAD request)
Max Lybbert
2009-10-02 21:21:24
+2
A:
Just always keep an outstanding async_read, when the connection is severed it will error.
And since like Max mentioned, TCP is meant to be robust in the face of a harsh network, it will only detect a severed connection when the remote end sends a FIN packet to close the connection. To work around this problem take a look at using asio::tcp::socket::keep_alive to enable TCP keep-alive. You can also implement a keep-alive at the application layer like discussed in Andrei's answer.
If you don't want to use async_reads then when you enable keep-alives on the socket is_open() should more accurately detect a severed connection.
joshperry
2009-10-03 02:23:22
There is one problem with keep-alive aproach: I don't have access to the servers where the application will run, therefore I can't change the keep-alive timeout (7200 seconds here). But I like this response, so if I need this again I will enable TCP keel-alive. Thanks
coelhudo
2009-10-05 21:46:18
I forgot to say what I did, I just try to read/write, check the error and make a decision based on this error.
coelhudo
2009-10-05 21:47:44