How to check the availability of a net.tcp WCF service

Question

My WCF server needs to go up and down on a regular basis, the client sometimes uses the server, but if it is down the client just ignore it. So each time I need to use the server services I check the connection state and if it's not open I open it. The problem is that if I attempt to open while the server is down there is a delay which hits performance. My question is, is there a way to do some kind of myClient.CanOpen()? so I'd know if there is any point to open the connection to the server.

Answer 1

There is an implementation of WS-Discovery that would allow you to listen for up/down announcements for your service. This is also a very convenient form of service address resolution because it utilizes UDP multicast messages to find the service, rather than configuring one set address on the client. WS-Discovery for WCF

There's also an implementation done by a Microsoft employee: WS-Discovery Sample Implementation

.NET 4.0 will include this natively. You can read about .NET 4.0's implementation on Jesus Rodriguez's blog. It has a great chart that details the ad-hoc communication that goes on in WS-Disco Using WS-Discovery in WCF 4.0

Another thing you might consider, especially if your messages are largely one-way, is a protocol that works natively disconnected, like MSMQ. I don't know what your design for your application looks like, but MSMQ would allow a client to send a message regardless of the state of the service and the service will get it when it comes back up. This way your client doesn't have to block quite so much trying to get confirmation that a service is up before communicating... it'll just fire and forget.

Hope this helps.

Answer 2

If you are doing a synchronous call expecting a server timeout in an application with a user interface, you should be doing it in another thread. I doubt that the performance hit is due to exception overhead. Is your performance penalty in CPU load, gui availability or wall clock time?

You could investigate to see if you can create a custom binding on TCP, but with faster timeout.

I assume you know that "IsOneWay=true" is faster than request->response in your case because you wouldn't be expecting a response anyway, but then you are not getting confirmation or return values. You could also implement a two-way communication that is not request->response.