[Boost-users] [asio] Detecting tcp peer disconnection

[Igor R]

Hello,

This issue has previously been discussed in details, and IIRC, the
conclusion was that the reliable method to detect peer disconnection
is to try reading from the socket.
Now I encountered strange situation: I connect tcp socket to some
proprietry server, then pull out the ethernet cable from the server
side. If async_read_some was in progress - nothing happens, no handler
is called. If I start an additional async_read_some - nothing happens.
I tried to set SO_KEEPALIVE option and waited - nothing happened.
My machine runs WinXPSP3, so async_read_some is delegated to WSARecv().

I'd appreciate any idea on the subj.

Thanks.
_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Jonathan Franklin]

On Thu, Jan 28, 2010 at 8:30 AM, Igor R <boost...@gmail.com> wrote:
> This issue has previously been discussed in details, and IIRC, the
> conclusion was that the reliable method to detect peer disconnection
> is to try reading from the socket.

Not quite. IIRC, the conclusion was that you are hosed in this exact scenario.

Basically, if you absolutely must detect this, and aren't otherwise
sending data, then you need to be able to build a "heartbeat" into
your protocol. You essentially must periodically send a packet (e.g.
a heartbeat message). The write call will always succeed until you
fill up your socket send buffer (which won't happen w/ heartbeat
messages). However, the failure to write will ultimately trigger a
timeout, and it will be the read call that fails.

See the previous thread for the details as to what is happening at the
TCP level.

Jon

[Igor R]

> Basically, if you absolutely must detect this, and aren't otherwise
> sending data, then you need to be able to build a "heartbeat" into your protocol.

Well, that's what I do right now.
I was under impression that it's achievable in some more simple way...

Thanks for the clarifcation.

[Jonathan Franklin]

On Thu, Jan 28, 2010 at 9:26 AM, Igor R <boost...@gmail.com> wrote:
> I was under impression that it's achievable in some more simple way...

It's basically the silent "drop-off" caused by the cut cable that is hosing you.

Unfortunately, as per the RFC (1122?), keep-alive is an optional
feature, and is off by default. TCP was basically designed to allow
indefinite operation in the absence of message traffic, which saves
both bandwidth and CPU. Two commodities which were much more precious
when TCP was invented. Though, even today, heartbeat-based systems
tend not to scale well.

> Thanks for the clarifcation.

You bet.

And if you come up w/ a scheme using TCP that doesn't require some
form of keep-alive or heartbeat message, then I'm definitely
interested in hearing about it.

Jon