Please see my comment to the question.
First of all, some background. Let's understand that we have "inverted" problem: the problem of
server push is a problem for Web application and not such a big problems if you deal with custom network application. This is because the Web was designed for much simpler application than those being developed these days. The Web was focused on pure
client-server model supporting only
pull technology, but not
push technology. Please see:
http://en.wikipedia.org/wiki/Client-server_model[
^],
http://en.wikipedia.org/wiki/Push_technology[
^],
http://en.wikipedia.org/wiki/Pull_technology[
^].
The problem is rather social and historical. When networking was about to make its way to the wide public markets, even the client-server technology was perceived as revolutionary by many naive users and engineers, despite its draconian limitations which I, for example, was able to see immediately. More advanced models like published-subscriber, along with such a basic technology as multithreading (these days :-)), was ofter considered overly complex and sophisticated (but I would never understand why):
http://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern[
^].
As a result, server push is difficult for the Web, and SignalR is only one of possible workarounds. Actually, the problem of creation of the decent chat application, so usual these days, reveal those draconian limitations of the client-server model.
But you are moving out of the Web, and this is technically much more easier, because you are not tied that badly by those Web standards. The only problem is: the most programming efforts are focused on the Web these days, by some reasons (again, social, but most serious reason is the platform independence of Web technologies, another one is the firewall hassles, another absurdity of modern technology), so the ready-to-use frameworks for custom networking are less popular and hence harder to find. That explains you difficulties in finding some ready-to-use solution. What to do: search wider?
I actually remembered one more idea: you can move to techniques based on
XMPP protocol (formerly
Jabber). Please see:
http://en.wikipedia.org/wiki/XMPP[
^],
http://en.wikipedia.org/wiki/Jabber.org[
^],
http://xmpp.org/[
^],
http://archive.jabber.org/userguide/[
^].
The benefits are: this is a well-establish technology, which supports
near real-time (
http://en.wikipedia.org/wiki/Near_real-time[
^]), published-subscriber, instant messaging and other important features. It has a whole open-source "Jabber community", and you can find both server and client implementations for different platforms.
Please see, for example, this CodeProject article:
Google Chat Desktop Application using Jabber.Net[
^].
—SA
Submit an article or tip