2
\$\begingroup\$

First off, I know there are other solutions and practices but I'm referring to MS proposed code from .NET documentation.

It goes like this:

client.Connect(anEndPoint);

bool blockingState = client.Blocking;
try
{
    byte [] tmp = new byte[1];

    client.Blocking = false;
    client.Send(tmp, 0, 0);
    Console.WriteLine("Connected!");
}
catch (SocketException e) 
{
    // 10035 == WSAEWOULDBLOCK 
    if (e.NativeErrorCode.Equals(10035))
        Console.WriteLine("Still Connected, but the Send would block");
    else
    {
        Console.WriteLine("Disconnected: error code {0}!", e.NativeErrorCode);
    }
}
finally
{
    client.Blocking = blockingState;
}

 Console.WriteLine("Connected: {0}", client.Connected);

I've tried using it in my TCP client to detect disconnection from server. My problems is that on some occasions it detects disconnect where server does not, so on server I have connection left hanging while client reconnects.

I'm asking anyone who tried using this method to share experiences and maybe help make it more robust.

\$\endgroup\$
2
\$\begingroup\$

First off, I'm not an expert about TCP and Sockets, though I have had some experiences in the past.

My problems is that on some occasions it detects disconnect where server does not, so on server I have connection left hanging while client reconnects.

If you have a client-server scenario, then one will never ever know about what is the state of the other without explicitly finding out!

Say you open the connection, client is idle for 10 seconds and now suddenly the client loses all power. The server doesn't know that the client lost it's power, the client didn't send a disconnect signal, the client was in an idle state so there is no sending/receiving that cut out midway or timed out. The only way for the server to know what is the state of the client on the 11-th second (for instance) is to query/ping the client. The term Keep-Alive applies here, although I can't think of good wording for it right now...

I'm asking anyone who tried using this method to share experiences and maybe help make it more robust

The state of the problem isn't currently very clear to me. In what specific scenario does the problem exist? When you remove the LAN cable? When you close the client application?

So what, if the connection on the server is left hanging? You have to account for such a very likely possibility. You will need to apply some sort of timeout or keep-alive methodology, inorder to keep the server from hanging on to the connection indefinently and thus consuming and running out of resources. Accounting for all possible scenarios - that is robustness!

As I said, I'm no expert, so I won't be able to tell you exactly which Socket class properties or methods to apply to your code to help you make it more robust. But I will say this, your code example is missing Disconnect() / Close() statements, most likely even using statements. I see no timeouts being applied, surely the Connect() and Send() methods have some sort timeout mechanism (maybe a property, eg client.SendTimeout)...

\$\endgroup\$
  • \$\begingroup\$ It is not 'the' TCP management code contained in this code example. I've actually cut out this part from MSDN documentation and I'm interested in it as 'first base' method to detect disconnects. \$\endgroup\$ – Bizniztime Aug 28 '13 at 8:22
  • \$\begingroup\$ @Bizniztime - Ok, that explains why your code example does not have Disconnect() or using elements. But my previous statements still stand. You cannot find out about the (dis-)connected state of the other party without explicit action - either via Keeo-Alive, timeouts, ping or other mechanism... \$\endgroup\$ – Marko Aug 28 '13 at 17:53
  • \$\begingroup\$ I agree with you completley. This code is supposed to be some sort of a ping method but from my experience it fails completley even in that one function. \$\endgroup\$ – Bizniztime Aug 30 '13 at 7:53
1
\$\begingroup\$

I ran into a similar problem on the client side using that code. Instead I switched from testing a non-blocking send to checking the number of bytes read from a receive request. If it returns zero bytes then the connection is closed. I found this to be far more reliable.

\$\endgroup\$
0
\$\begingroup\$

I've found Connected property that is used in this code to be highly unreliable. It should reflect last known state of connection based on success of package sent or retrieved but it is affected by some other underlying mechanics and it gives continuous false readings in some network arrangements.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.