[asio] Detecting tcp peer disconnection
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.
On Thu, Jan 28, 2010 at 8:30 AM, Igor R
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
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.
On Thu, Jan 28, 2010 at 9:26 AM, Igor R
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
participants (2)
-
Igor R -
Jonathan Franklin