I’ve seen signalR vs html5 websockets for asp.net MVC chat application but it doesn’t 100% answer my question as it’s based around HTML5 WebSockets, which Microsoft may have extended upon in .NET 4.5 with their WebSocket object.
I’m wondering if the WebSocket feature does actually do the same as SignalR and fall back to long polling when WebSockets aren’t available? Surely Microsoft would implement the same technology as SignalR in their approach to this technology?
Edit:
For anyone else wondering about this, I found this comment the most helpful to understand the scenario and why I’ll be using SignalR:
Well, they are not really. Up until now IIS and ASP.NET didn’t have
anything built in that supported WebSockets so SignalR project had to
build it themselves. Now that Microsoft is providing the plumbing
SignalR could easily switch to using Microsoft’s implementation,
either in addition to or instead of their own. SignalR is an
abstraction over implementation details, WebScockets class is the
implementation detail
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
I think SignalR is the way to go, and is going to be part of .NET itself anyway (and likely extend/merge/replace web-sockets support). It uses web sockets when it’s supported, and consistent client polling hack when it’s not, so, it’s the way to go.
Update:
Since this answer is still getting upvoted, it’s worth mentioning that SignalR is now officially part of ASP.NET.
Check http://asp.net/signalr
Update: .NET Core
SignalR is also being added to .NET Core as @yazanpro noted in comments.
It’s available in .NET Core 2.1, and has official documentation as well.
Method 2
-
I’m wondering if the WebSocket feature does actually do the same as SignalR and fall back to long polling when WebSockets aren’t available?
WebSockets is a new protocol independent of other communication techniques. From the RFC
The goal of this technology is to provide a mechanism for browser-based
applications that need two-way communication with servers that does
not rely on opening multiple HTTP connections (e.g., using
XMLHttpRequest or s and long polling). -
Surely Microsoft would implement the same technology as SignalR in their approach to this technology?
Not if they want to conform to the specification they won’t. There’s certainly nothing stopping Microsoft from developing a higher level API similar to SignalR that would abstract away communication detail and offer graceful fallback. However that hypothetical API would probably build on top of WebSocket class as opposed to replacing it.
Method 3
SignalR uses OWIN which will use WebSockets connection if the browser supports web sockets and long polling if the browser doesn’t support WebSockets.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0