Websockets in .NET 4.5

Question

I want to develop a web application in which client calls a service on server to do some action which involves some processing. Server will do all the necessary processing and when the updated data is ready it will push that data to client. Currently I am considering two approaches: - 1. Using ASP.NET WEB API with SignalR 2. Using WebSockets with WCF in .NET 4.5.

My server will be on Windows Server 2012 but majority of my client will be IE 9 which I think do not support WebSockets.

As written in the SignalR documentation that it automatically falls to Long Polling if WebSockets support is not present without changing the application code. Whether this is also supported by WebSockets in .NET 4.5 or I have to do it manually. Means whether I have to implement both the Pull method and push method on the server.

Please guide me, which approach I will have follow.

In later use case I want to build this web application using PhoneGAP to create mobile app for iOS, Android & Windows Phone.

Answer 1

WebSockets does not fall back to longpolling (that doesn't really make sense). SignalR is a higher level abstraction over http transports and that's why it does the fallback and other things (like provide a nice programming model over a connection).

If you choose to use websockets on ASP.NET (not sure about WCF) you'll be programming against raw sockets (this means reading/writing array segments etc) and doing a good job at that is hard. SignalR does this for you and will fallback to several other transports (forever frame, server sent events, longpolling) if websockets isn't available on client or server.

Regarding clients, if you choose to use SignalR you'll need to use a SignalR client. We only have support for javascript and .NET (silverlight, windows phone 8, winrt, .NET 4 and .NET 4.5). Some people have written clients for other platforms including iOS and Android but we don't maintain them so I can't speak to how up to date they are.

I'd recommend you use SignalR so you can focus on your application logic instead of messing with the low level programming model of websockets.