Earlier today I came across Kaazing's WebSocket API for HTML5.
Looks fantastic, but as I am only now researching WebSocket possibilities for real-time financial updating, I would like to hear some recommendations, and pitfalls to avoid when planning out this architecture.
I'm looking at ASP.Net MVC, and possibly some WPF/Silverlight MVVM.
Are there other WebSocket API's that are better (and why), and some good examples?
Also, what kind of traffic can WebSockets handle? I mean, if we have over a million users on a system updating real-time, how do hardware requirements change because the software architecture implements WebSockets?
A late answer. Here is a WebSocket Server (framework) that is based on .NET and has support for modelbinding / controller and validations etc. in a way that reminds of MVC. It is very easy to get started using it. Just create a new MVC3 Project and type:
Install-Package XSockets
Using the Package Manager Console in Visual Studio
More info on http://xsockets.net
And yes, it supports RFC6455 and Hibi00 and has a fallback for "older" browsers.
I figured I'd come back at this, now that I have a solution ready for production. I took a look at a few vendors that basically charge a lot of money for something you can essentially build yourself. They all have good products, and if your time to market is critical, those prefab options may be the best in the short run.
After poking around with Node.JS with Socket.IO, I shifted my attention to SignalR - an asynchronous signaling library for .NET to help build real-time, multi-user interactive web applications, and used the hub implementation.
It manages all the heavy lifting and connection building with just a few lines of JavaScript, and automatically selects the appropriate transport protocol for the connection.
For a load-balanced environment, implementation of a caching server such as Redis is required.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With