Geek Answers Handbook

So ... ASP.NET MVC and WebSockets?

I have an application in MVC 3, and I want to add WebSockets to it (with a departure from Comet).

I did a little research, and I found out that part of the comet is quite simple, and I would rather do it myself. Just AsyncControllers and a fairly simple js bit is all that is required to handle these long-lived ajax requests.

Now, in the case of WebSocket, everything starts to get dirty. I looked at several libraries, but basically they seem to set up a web server (therefore need a different host or port) and listen for ws protocol requests there. For example, for SuperWebSocket , which at first seemed nice, but the problem with it was "I am the web server" (of course, this is normal, but I would prefer to avoid).

Then I looked at “PingIt” or something like that, I can’t find the link now. However, I have a source on another computer. This one works on the endpoint in mvc, but I didn’t really like the way it handles things, for example, it takes an IDisposable object and through the reflector creates a javascript element that is rendered on the client, which is very dirty with their library name, in which I really I was not interested, plus it felt that many of them were thrown against what I could wish for, which contradicts my opinion on how the page should be displayed (especially now that I am working on MVC, which pretty much means that I I can code acce clean, unobtrusive html-pages).

Basically, I want my endpoints to be something like:

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

but not

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

So: is it possible to get websocket connections (and do handshakes and all that needs to be done) at the endpoint in the asp.net ASP.NET application controller, instead of setting up tcplistener somewhere?

It will also help me keep the comet code a little closer to my websocket code.

I have to say that I am seriously new to all the work of the comet / websites, so I don’t know much (or any) protocol, I understand how to make the comet work, but not so much on websockets, although I read and understood the basics to understand the essence of this.

Also: please let me know if what I ask does not work.

+10
c # iis websocket asp.net-mvc-3 comet
source share
3 answers

As a guide for this topic in WebSockets - I want to note that at first glance WebSockets looks like an obvious choice. The API is designed to provide a bidirectional communication channel between a browser and a server through a single TCP socket. It was standardized by the IETF, and the latest browsers Chrome, Firefox, IE and Opera support WebSockets. It is designed to minimize bandwidth overhead by reducing the overhead of HTTP messages. So what don't you like?

Like any perceived silver bullet, things are not always what they seem. There are many problems:

Browser Support As of June 2012, only 47.64% of browsers currently in use actually support WebSockets http://caniuse.com/websockets. This means that no matter how good WebSockets are, you will still need a second “backup” solution to support most internet users. And since most backup solutions use Flash, you are still out of luck on iOS and other mobile devices.

Learn more about WebSockets in reality from this blog post: Are the gateway and HTML5 WebSockets server a panacea for real-time data transfer?

Browser support update : as of May 2019, 96.77% of currently used browsers actually support WebSockets http://caniuse.com/websockets

+3
source share

I did a little research, and I found out that part of the comet is quite simple, and I would rather do it myself. Just AsyncControllers and a fairly simple js bit is all that is required to handle these long-lived ajax requests.

Sorry, this is not so simple. Different browsers behave differently and work better using different methods - XMLHttpRequest, XDomainRequest, ActiveX objects, Multpart replace, Long-Polling, Streaming. Due to this and the fact that there is no specific specification for these solutions, Comet is just a hack . Events sent by the server (EventSource API) and WebSockets were designed from the ground up to offer the most efficient and standardized way to transfer data from the server to the client, and more importantly, WebSockets were designed for bi-directional communication between the client in real time and the server.

Now, in the case of WebSocket, everything starts to get dirty. I looked at several libraries, but basically they seem to set up a web server (therefore need a different host or port) and listen for ws protocol requests there. This applies, for example, to SuperWebSocket, which at first seemed nice, but the problem "I am a web server" (this, of course, is fine, but I would prefer to avoid).

Windows Server 8 will support WebSockets. Until then, you will need to use a separate "web server", such as XSockets or SuperWebSockets (which you already mentioned). There are also Alchemy WebSockets and Fleck .

But since Microsoft is leading SignalR forward, it is likely to get a full grip and even become part of the standard ASP.NET MVC stack (maybe this is already planned, I'm a little behind MS). SignalR supports WebSocket (or has a module) and will handle backups for transport mechanisms that support the user's browser.

For more information on standalone solutions (there are a few more .NET / IIS options), check out these self-hosted real-time services .

I am very interested to see how IIS scales to work with thousands of persistent connections - has it been rewritten for Windows Server 8? How soon do you need to introduce a load balancer and horizontally? If you are not worried about this, I would look at the hosted real-time service .

+1
source share

More articles:


All Articles