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.

score 9 · Answer 1 · answered Mar 25 '13 at 09:24

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.

why can't windows phone 8 connect over Web sockets in SignalR ? — sacretruth, Dec 06 '13 at 23:58
@dfowler There's a socket api though, so that's hardly an excuse. — John, Dec 13 '13 at 14:11
Sure, seems nobody has written one nor did we write one. We do accept pull requests though — davidfowl, Dec 14 '13 at 22:01

score 1 · Answer 2 · answered Mar 25 '13 at 07:13

1

You could start with the ASP.NET Tutorial http://www.asp.net/signalr/overview/getting-started/tutorial-getting-started-with-signalr

After this tutorials you know all the basic thing you need to know about SignalR

answered Mar 25 '13 at 07:13

Ivo

3,406
4
33
56

Thanks Ivo, but I want to compare the two methods. SignalR & WebSockets in .NET 4.5. Whether WebSockets in .NET 4.5 also falls back to long polling if the environment do not support WebSockets or I have to handle it manually. – Amit Kumar Jain Mar 25 '13 at 07:23
There are a couple of open source websocket libraries fo .net (http://stackoverflow.com/questions/9537641/node-js-socket-io-vs-signalr-vs-c-sharp-websocket-server) see unmarked answer. As far as I know the do not fallback like signalr. SignalR got 3 or 4 fallbacks for older browsers. Also see http://stackoverflow.com/questions/9524591/net-4-5-websockets-vs-signalr – Ivo Mar 25 '13 at 07:29

score 1 · Answer 3 · answered Mar 27 '13 at 05:27

I can confirm that the fallback works automatically. If websockets transport can't be used, ServersentEvents transport would be used.. and so on.. the last transport protocol is longpolling.

Our SignalR server is a .NET 4.5 framework app, hosted in an ASP.NET MVC App using 4.5 dlls on a windows 2012 server. The application pool is ASP.NET 4.0.

A .NET 4.5 client on a Windows 8 or a windows 2012 server seems to use websockets.
The same .NET client on a Windows 7 machine (even with framework 4.5 installed) falls back to serversent events transport automatically.

With Signalr javascript clients on a browser, a similar thing happens:

Chrome/Safari/other browsers that support websockets seem to use websockets.
IE/other browsers that don't support websockets, but are relatively late versions seem to use serversentevents.

From experience, serversentevents is not very bad, therefore don't be put off if websockets isn't being used and certainly don't use that as the sole factor against using signalR as the benefits are many.

Hope this helps.

Websockets in .NET 4.5

3 Answers3