Push data to client using SignalR vs WCF?

Question

I have one WPF client-server application. Now I have scenario like client will connect to server and server will push data to client periodically. I am bit confused about what technology and way should I choose for notification to clients.

SignalR is best for web application I think and I have desktop application. With WCF service, we can implement push notification through Duplex channel and callback. So can you please guide me what are the merits and demerits in using SignalR or WCF service ?

Thanks

Answer 1

I think you already got lots of data points about each of them. But selection of SignalR will provide you added advantage over development efforts which is in most of cases major decision block while selecting a technology.

You don't need to worry about API development / testing etc. and can have focus on your own implementation of the project.

Hope it helps!

Answer 2

SignalR is not just about web. SignalR server side code does not care about the technology of its clients, you just need to have implementors at the client side.

If we isolate pusing data to the client, I would strongly recommend SignalR as it's much simpler than WCF in this aspect, I had my share of problems with WCF and I guess you had some yourself. I found a simple console/web application sample here.

In general, Duplex WCF and using Callback like here seems very messy to me, there is a lot of configuration server side and this is why I think SignalR is simpler.

In addition, you can't use duplex (AFAIK) with javascript and objective-c.

Answer 3

One point that nobody has raised so far:

• SignalR 1.0.1 requires .NET 4 on the server and client. Depending on the version of your client and server that you are targeting that might be an important factor to consider.

If you just want to update periodically for new data, you might be better to just use WCF and a polling mechanism from the client side rather than using either duplex WCF or signalr.

Answer 4

Below are my observations from experiences:

SignalR pros:

• Easy to startup, lower learning curve. You can easily run an example found from web
• Exception handling (e.g. connection drops, timeouts) is embedded inside the API

SignalR cons:

• Only supporting HTTP protocol

Duplex pros:

• Supports TCP in addition to HTTP. This may be a serious performance gain if you know your client types and your system is working in a closed network. Also, working over TCP adds more connection stability than HTTP

Duplex cons:

• Higher learning curve - harder to startup and have a stable solution. Want to verify it? Download a duplex and a SignalR sample from the web and see how much time you will spend to successfully run each other.
• You need to handle all the exceptional cases (connection drops, timeouts, etc.)
• I know I am not the only one who faced serious timeout problems when you want to use the duplex service for a long time. We need to make service calls periodically to keep client connections alive.

By the way, there are APIs exist for JavaScript, Desktop and Silverlight projects to consume SignalR services.

Answer 5

SignalR can easily be used now with multiple clients from javascript, .NET both WinForms and WPF, and can even be used with a C++ client; Using a self hosted .NET signalr server (OWIN) is really nice way to have a standalone server that pushes / receives / broadcasts to multiple clients. The only thing that may be easier is ZeroMQ using its publish subscribe methodology.