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 wh
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.
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.
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!
One point that nobody has raised so far:
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.
Below are my observations from experiences:
SignalR pros:
SignalR cons:
Duplex pros:
Duplex cons:
By the way, there are APIs exist for JavaScript, Desktop and Silverlight projects to consume SignalR services.