Problem about checking a WCF connection is opened

Question

I have a problem about checking a WCF connection is opened. My WCF Connection is bi-directional. I use State property to check the connection's state at client. My function:

private bool ConnectionIsOpen()
{
    if (m_Service != null && (m_Service.State | CommunicationState.Opened) == CommunicationState.Opened)
    {
        return true;
    }
    return false;
}

I create a service which is a thread running every 10 seconds to check the connection's state. I use the method ConnectionIsOpen() for checking. Everything is well on running on Windows XP. However there is a problem when running on Windows 7.

When I unplug the network cable to create to disconnect, If running application on Windows XP, checking connection's State is Faulted but if running on Windows 7, checking connection' State is still Opened.

Anyone can help me how to check a connection is openned or not in this case. Thanks.

your if statement looks funny... why not just: if(m_Service != null && m_Service.State == CommunicationState.Opened) — c0deNinja, Aug 03 '11 at 04:30
If you're not sure what the if statement is doing, you might want to train in a different dojo. (haha I kid i kid) The "State" variable can have different communication states applied to it. The only one that Lu Lu is concerned with is if it is "Opened" (it could also be Created) — feathj, Aug 03 '11 at 04:47
`ConnectionIsOpen()` is always return true if `m_Service != null`, may be the problem in creating m_Service instant not in connection state — Damith, Aug 03 '11 at 04:51
Use log4net to write connection's state, although I unplug the network cable but m_Service.State is always Opened. This problem only happens on Windows 7. — Leo Vo, Aug 03 '11 at 07:50

score 5 · Answer 1 · answered Aug 03 '11 at 15:22

5

This will always be true:

(m_Service.State | CommunicationState.Opened) == CommunicationState.Opened

Example, m_Service.State = 0:

0 | CommuncationState.Opened == CommuncationState.Opened

You want to use & (AND) instead.

answered Aug 03 '11 at 15:22

Kieren Johnstone

41,277
16
94
144

score 3 · Answer 2 · answered Aug 03 '11 at 15:19

We ran into a similar problem in our own system; disconnecting the network cable or placing either the client machine or the server in sleep mode does not generate a channel fault.

From what I can tell, it seems that the connection state only indicates the state of the connection after the last call and not the current connection state. The only way to know the current state is to actually call the service.

If your client doesn’t need to call the service that often but must react if the connection is lost one solution is to implement a dummy call on the client side which periodically polls the service. If the connection is unavailable when the dummy call is made you’ll get a channel fault that you can then deal with.

The catch is you can’t simply use the dummy call to guarantee that the next call to the service will work:

public void SomeMethode()
{
    if (ConnectionIsOpen())
    {
        m_Service.Dummy();
        // Connection is lost here
        m_Service.SomeMethode();
    }
}

To get around this problem, we implemented a system that automatically re-executes any failed service calls which generate a channel fault after the connection has been restored.

score 2 · Answer 3 · edited May 23 '17 at 12:13

The best and asured way to confirm the Communication state is Open or not is to call the Faulted event like below :

 proxyInstance.InnerChannel.Faulted -= new EventHandler(ProxyChannelFaulted);

But this works only with those bindings that support ReliableMessaging like WsHttpBinding.

For detail refer the link : WCF Proxy Client taking time to create, any cache or singleton solution for it

Thanks, Jai Kumar

score 0 · Answer 4 · answered Aug 03 '11 at 04:19

The fact that you are getting completely different results on windows 7 is not surprising. Microsoft completely re-engineered the TCP stack with windows vista, so the functionality is quite different from xp in the core networking functionality.

The first thing that I would do is use wireshark to see what is actually going across the wire. See if your TCP connection actually terminates when you pull the plug. Windows might be doing some kind of connection persistence / buffering in case the connection comes back quickly.

Problem about checking a WCF connection is opened

4 Answers4