CODEWITHSUNDEEP
c#wcfnet.tcp
Pablo Retyk
Pablo Retyk

Reputation: 5758

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

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.

Upvotes: 16

Views: 40862

Answers (5)

Kostas Konstantinidis
Kostas Konstantinidis

Reputation: 13727

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 WCF: Availability of the WCF services if you are interested in a read.

Upvotes: 1

Anderson Imes
Anderson Imes

Reputation: 25650

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.

Upvotes: 24

Dave_B
Dave_B

Reputation: 29

Here's what I'm using and it works like a charm. And btw, the ServiceController class lives in namespace 'System.ServiceProcess'.

try
{
    ServiceController sc = new ServiceController("Service Name", "Computer's IP Address");
    Console.WriteLine("The service status is currently set to {0}",
        sc.Status.ToString());

    if ((sc.Status.Equals(ServiceControllerStatus.Stopped)) ||
        (sc.Status.Equals(ServiceControllerStatus.StopPending)))
    {
        Console.WriteLine("Service is Stopped, Ending the application...");
        Console.Read();
        EndApplication();
    }
    else
    {
        Console.WriteLine("Service is Started...");
    }
}
catch (Exception)
{
    Console.WriteLine("Error Occurred trying to access the Server service...");
    Console.Read();
    EndApplication();
}

Upvotes: 1

Jon
Jon

Reputation: 15200

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.

Upvotes: 1

Tormod
Tormod

Reputation: 4583

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.

Upvotes: 3

Related Questions