9

What is the easiest way to check if a socket was closed on the remote side of the connection? socket::is_open() returns true even if it is closed on the remote side (I'm using boost::asio::ip::tcp::socket).

I could try to read from the stream and see if it succeeds, but I'd have to change the logic of my program to make it work this way (I do not want data to be extracted from the stream at the point of the check).

Hali
  • 745
  • 1
  • 5
  • 15
  • Why do you need to know if the remote connection has closed? – outis May 04 '09 at 03:39
  • Also, are you using an application protocol of your own design or a standard protocol? – outis May 05 '09 at 01:55
  • I'm writing a basic chat program, and I need to notify the user that the other person closed the app. I have my own protocol, and I've already added a "Quit" message. The only drawback is that it isn't sent if the app is killed/crashes/etc. – Hali May 05 '09 at 21:59
  • Your question is ill-formed. What you're asking for is a way to detect if the *connection* was closed by the peer. – user207421 Feb 21 '17 at 08:48
  • Maybe you can perform an asynchronous or synchronous read with a boost::asio::null_buffers instance as buffer argument? – Florian Aug 03 '17 at 07:43

6 Answers6

13

Just check for boost::asio::error::eof error in your async_receive handler. It means the connection has been closed. That's the only proper way to do this.

dongle26
  • 826
  • 1
  • 10
  • 18
8

Is there a boost peek function available? Most socket implementations have a way to read data without removing it from the queue, so you can read it again later. This would seem to satisfy your requirements.

After quickly glancing through the asio docs, I wasn't able to find exactly what I was expecting, but that doesn't mean its not there.

I'd suggest this for starters.

teeks99
  • 3,585
  • 2
  • 30
  • 38
  • Yes, you're right. You can pass a flag to the "receive" method that tells it not remove the data. I was using the "read_some" method, which doesn't have this flag argument. Thanks for pointing it out! – Hali May 05 '09 at 22:09
  • suppose you have setup the socket and response then you can setup a stream e.g. std::istream myhttpstream(&presponse); and then you can use the std::istream::peek() function . –  Jan 29 '12 at 22:56
  • I do this: received = socket().receive(boost::asio::buffer(buf), tcp::socket::message_peek); – Chuck D Nov 17 '17 at 22:54
7

If the connection has been cleanly closed by the peer you should get an EOF while reading. Otherwise I generally ping in order to figure out if the connection is really alive.

Nova
  • 2,039
  • 2
  • 21
  • 16
  • 2
    ...and I need to read to get the EOF. I guess there's no way around then. Thanks! – Hali May 04 '09 at 10:12
2

I think that in general once you open a socket, you should start reading it inmediately and never stop doing so. This way you can make your server or client to support both synchronous and asynchronous protocols. The moment the client closes the connection, the moment the read will tell you this.

chila
  • 2,372
  • 1
  • 16
  • 33
  • I can't see there is any relation between "start reading it inmediately and never stop doing so" and "making your server or client to support both synchronous and asynchronous protocols". Could you please explain that in more detail for me? – John Sep 08 '21 at 06:39
0
boost::asio::socket_base::keep_alive keepAlive(true);
peerSocket->set_option(keepAlive);

Enable keep alive for the peer socket. Use the native socket to adjust the keepalive interval so that as soon as the connection is closed the async_receive handler will get EOF while reading.

Configuring TCP keep_alive with boost::asio

Thinkal VB
  • 189
  • 3
  • 12
0

Using error_code is able to check the condition whether the client is connected or not. If the connection is success, the error_code error.value() will return 0, else return other value. You can also check the message() from the error_code.

Allen
  • 443
  • 2
  • 10
  • 20