tags:

views:

284

answers:

3

Test-cases:

  1. Before connection starts it should return false
  2. Connection is closed by other end return false
  3. Connection is closed by the client return false
  4. Connection exists even if no data is avaliable return true

    class MyConnection
    { 
        //Assume I have all initialization for _socket 
        public bool IsConnected()
        {
            return !(_socket.Poll(1, SelectMode.SelectRead)
                                        && _socket.Available == 0);
        }
        private Socket _socket;
    

    }

    class Test
    {
       static void Main(string[] args)
       { 
            MyConnection my = new  MyConnection()
            if(my.IsConnected())
               /*always return true even when I am not connected*/;    
       }
    }
    

Any ideas how to prevent that?


So far, none of the answers were satisfactory....

The following can be done:

   public bool IsConnected()
        {

            bool bConnected = false;
            bool bState = _socket.Poll(1, SelectMode.SelectRead);
            try
            {
                if (bState && (_socket.Available == 0))
                    bConnected = false;
                else
                    bConnected = true;
            }
            catch (SocketException)
            {
                //_socket.Available can throw an exception
                bConnected = false;
            }

            return bConnected;
        }
+1  A: 

I'm not sure exactly what you're trying to achieve, but assuming you're trying to tell if the connection has been broken, this post may be helpful:

http://stackoverflow.com/questions/681866/how-can-i-tell-if-the-connection-has-been-broken-in-my-sockets-based-client

Edit: A troubleshooting step would be to determine which of the two boolean expressions are returning false, or if they are both returning false.

J c
That was my post! solution for which is incomplete :)
lol! Fair enough, I guess there was a reason it was similar - I should have checked the author.
J c
+2  A: 

I think your _socket.Poll() call is backwards. If the poll fails, that will help the method evaluate as true rather than false. Try this:

public bool IsConnected()
{
    return !(!_socket.Poll(1, SelectMode.SelectRead)
                                && _socket.Available == 0);

}

I'm also not sure it's a good idea to make _socket.Available part of this check. According to the documentation, a return value of 0 just means that "no data is queued in the network buffer." That could very easily be true even of a connected socket.

Joel Coehoorn
Are you sure this will determine if socket is connected in this two scenarios:1) Before connected started2) After connection is broken
It won't: see my notes about _socket.Available. But it is an improvement over your current code. For condition #1 I'd just keep a private member in your class to check. For #2, either the .Poll is adequate or it isn't.
Joel Coehoorn
Joel, I don't need an improvement, I would prefer a fully working solution. Thanks for an effort though....
meh- I answered the question you asked: why does it always return "true".
Joel Coehoorn
almost: You said _socket.Poll(1, SelectMode.SelectRead) all is backwards. it is NOT -- it returns true if connection is broken as well as when data is available...
A: 

It looks to me like you may not get the functionality you are expecting from the Socket class. My understanding is that the Socket class is only aware of the connection state as of the last socket operation.

Note that the Poll method has some limitations:

This method cannot detect certain kinds of connection problems, such as a broken network cable, or that the remote host was shut down ungracefully. You must attempt to send or receive data to detect these kinds of errors.

This would imply that in the event of an ungraceful disconnect, it would be normal for a socket to continue to report true until a subsequent socket operation times out (which may explain the several minute delay you experienced in your previous post on this).

This means that if you want to detect ungraceful disconnects, you will likely need to implement an application level heartbeat/ping, as suggested in a previous answer. You may need to play with the interval between the pings, otherwise you lose a degree of fault tolerance and a lag spike may cause unwanted reports of a disconnect.

J c