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

Solution 1

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.

Solution 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.

Solution 3

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!

Solution 4

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.

Solution 5

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.

View more solutions

Comments

[Upendra Chaudhari]

Can you please give more details about why SignalR simpler than WCF ?

[Mithir]

I've edited the answer, but in essence I find WCF configuration very messy and SignalR a very elegant solution, but maybe it's just a matter of taste. I am pretty sure though that SignalR will give you more flexibility in the future if you wish to add web client or any other.

[Upendra Chaudhari]

I want to check performance also, only for coding purpose we can't choose SignalR. I have desktop application and there will not be any web application in future. Also SignalR run only on Http protocol I think, is SignalR support Net TCP ?

[Mithir]

SignalR's main point of interest is its lightness and the ability to connect to many different clients. it seems like you don't have this requirement, and WCF may make winform/wpf development easier for you.

[Upendra Chaudhari]

Thanks for reply. I am already aware about WCF duplex communication as I have done in one of my previous project. So development point of view, it's not hard for me. I just want to know performance wise. Will WCF create any problem when application have large data to push in fraction of time or any timeout issue when it is idle for long time ?

[Hasan]

I don't make any performance test on my duplex services yet. But for the timeout question, as i mentioned in my response, we've faced with some non-deterministic timeout problems during development. Since we couldn't find a documented solution and fully working sample on this, we've decided to make periodical heartbeat requests manually to our duplex service to keep it alive (=to prevent from connection timeouts).

[Upendra Chaudhari]

If we go for polling mechanism then even no required WCF service too. But in polling there will be delay to get data if polling time is larger and we can't set smaller polling time and update UI at client side. Also for polling, we need to maintain track for updated data, can't load all data at every polling.

[Aron]

SignalR supports WebSockets (for IIS 8), which for most cases is actually better than plain TCP, since its better at going through firewalls.

[Hasan]

One additional note on Aron's comment: You need to be careful about your client profile. Not all the browsers are supporting websockets yet.

[user2137186]

@Hasan signalR still doesnot support TCP?

[Hasan]

@user2137186 No plain TCP support. You can get the supported transport options from here or as summary from here. To sum up: if WebSockets then Cool, if !WebSockets then Server Sent Events, if !Server Sent Events then Forever Frame, if !Forever Frame then Long Polling

[Ethan Reesor]

@Hasan, I'm new to WCF, so I'm not sure, but the transport layer may be dropping the connections due to idleness. SignalR has a built in heartbeat to counteract this.

[OldSchool]

@UpendraChaudhari I am also facing similar sort of issues. I think we can use WebSockets with SignalR for some performance gain in terms of header size and all. I think then the performance can come closer to WCF with Net TCP. What's your thoughts?

[OldSchool]

@Mithir Any points regarding the performance of WebSocket vs Net TCP in WCF? please see my above comment also.

[Mithir]

@YakRangi I don't know about WebSocket vs Net TCP in WCF performance. but I would refrain from using WCF.