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

i don't think it's possible doing a server side call to your Client to inform him that you the service has been started.... Best method i can see is having a client method figuring out where or not the service is open and in good condition. Unless i am missing some functionality of WCF...

there is a good blogpost here if you are interested in a read

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.

Answer 3

If you were in a local network it might be possible to broadcast a signal to say that a new server is up. The client would need to listen for the broadcast signal and respond accordingly.

Answer 4

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 location because it utilizes UDP multicast messages to find the service, rather than configuring one set address on the client. http://www.codeproject.com/KB/WCF/ws-discovery.aspx

There's also an implementation done by a Microsoft employee: http://blogs.msdn.com/vipulmodi/archive/2006/12/21/ws-discovery-sample-implementation.aspx

.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: http://weblogs.asp.net/gsusx/archive/2009/02/13/using-ws-discovery-in-wcf-4-0.aspx

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.