So… ASP.NET MVC and WebSockets?

问题:

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 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.

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).

Then I looked at "PingIt" or something like that, I can't find the link now.., I do have the source on another computer though. This one DOES run on an endpoint in mvc, but I didn't quite like the way in which it handles things, like it takes an IDisposable object and through reflector it creates a javascript piece that gets rendered in the client, which is very polluted with their library's name, which I've really no interest in, plus it felt like a lot of it was being thrown in against what I might wish, which kind of goes against my view on how a page should be rendered like (specially now that I'm working on MVC which pretty much means I can code clean, unobtrusive html pages).

Basically what I want is my endpoints to be something like:

domain.com/rt/comet
domain.com/rt/socket

rather than

domain.com/rt/comet
domain.com:81/

So: is it possible to receive websocket connections (and do handshaking and whatever needs to be done) on an endpoint within an asp.net MVC application's controller, rather than setting up a tcplistener somewhere?

This would also help me keep my comet code a little closer to my websocket code

I should say I'm seriously new to the whole comet/websockets thing, so I don't really know much (or any) of the protocol, I do understand how to make comet work, but not so much in websockets, though I've read and understood the basics to get the gist of it.

Also: please let me know if what I'm asking is way off

回答1:

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!]

回答2:

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 July 2017, 93.85% of browsers currently in use actually support WebSockets http://caniuse.com/websockets

回答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.