So… ASP.NET MVC and WebSockets?

Question

I have an application in MVC 3 and I\'m looking to add WebSockets (with fallback to Comet) to it.

I\'ve researched a bit and I found out the Comet part is pretty straigh

Answer 1

As a point of reference for this thread on WebSockets - I want you to note that at first glance, WebSockets looks like the obvious choice. The API is designed to provide a bi-directional communication channel between browser and server over a single TCP socket. It's been standardized by the IETF, and the latest Chrome, Firefox, IE, and Opera browsers support WebSockets. It's designed to minimize bandwidth overhead by reducing HTTP message overhead. So, what's not to like?

Like any perceived silver bullet, things are not always what they seem. Lots of problems exist:

Browser Support: As of June 2012, only 47.64% of browsers currently in use actually support WebSockets http://caniuse.com/websockets - That means, no matter how good WebSockets appears, you still need a second "fallback" solution to support the majority of Internet users. And since most "fallback" solutions involve Flash, you’re still out of luck on iOS and other mobile devices.

Read more about WebSockets in reality from this blog post: Are HTML5 WebSockets Gateway and Server the Panacea for Real-Time Data Push

Browser Support Update: As of May 2019, 96.77% of browsers currently in use actually support WebSockets http://caniuse.com/websockets

Answer 2

Just going to agree with the comments and provide a few links. SignalR is the way to go.

The site: http://signalr.net/ and http://www.asp.net/signalr

The code: https://github.com/SignalR/SignalR

Nuget: Install-Package Microsoft.AspNet.SignalR -pre

Good starting points:

• Free E-Book http://www.eduardopires.net.br/Repositorio/SignalR_eBook.pdf

• http://weblogs.asp.net/davidfowler/archive/2012/11/11/microsoft-asp-net-signalr.aspx

• http://www.dotnetcurry.com/ShowArticle.aspx?ID=780

• http://www.hanselman.com/blog/AsynchronousScalableWebApplicationsWithRealtimePersistentLongrunningConnectionsWithSignalR.aspx

Video from one of the creators: http://vimeo.com/43659069 <--[Loads of information!]

Answer 3

I've researched a bit and I found out the Comet part is pretty straightforward and I'd much rather do it myself. Just AsyncControllers and a pretty plain bit of js is all that's required to handle those long-lived ajax requests.

Sorry, it's not that easy. Different browsers behave in different ways and perform better using different techniques - XMLHttpRequest, XDomainRequest, ActiveX objects, Multpart replace, Long-Polling, Streaming. Because of this, and the fact there's no defined spec for these solutions, Comet is just a hack. Server Sent Events (EventSource API) and WebSockets have been designed from the ground up to offer the most efficient and standardised way of pushing data from server to the client, and much more importantly WebSockets have been designed for realtime bi-directional communication between a client and a server.

Now, in the case of WebSocket, things start to get dirty. I've looked at a few libraries, but they mostly seem to set up a web server (therefore needing another host, or port) of their own, and listen to ws protocol requests there. This is the case for instance for SuperWebSocket, which seemed nice at first, but had this "I'm a web server" issue (which is perfectly fine of course, but I'd rather avoid).

Windows Server 8 will natively support WebSockets. Until then you'll need to use a separate 'web server' such as XSockets or SuperWebSockets (which you've already referenced). There's also Alchemy WebSockets and Fleck.

But because Microsoft are driving SignalR forward it is most likely to get full traction and even become part of the standard ASP.NET MVC stack (it may already be planned, I'm a little behind the times with MS stuff). SignalR has WebSocket support (or has a module) and will handle fallbacks to transport mechanisms which support the user's browser.

For more information on self hosted solutions (there are a few more .NET/IIS options) check out these self hosted realtime services.

I'm very much interested in seeing how IIS scales when dealing with thousands of persistent connections - has it been re-written for Windows Server 8? How soon until you need to introduce a load balancer and horizontally scale? If that's not something you are interested in worrying about then I'd look at a hosted realtime service.