Multiplexing and WebSockets
The C10k Problem, WhatsApp and more have over the years shown how web server application have improved to handle a high number of clients simultaneously. High Scalability offer further food for thought:
In 2011 WhatsApp achieved 1 million established tcp sessions on a single machine with memory and cpu to spare. In 2012 that was pushed to over 2 million tcp connections. In 2013 WhatsApp tweeted out: On Dec 31st we had a new record day: 7B msgs inbound, 11B msgs outbound = 18 billion total messages processed in one day!
Historically with last mile messaging (COMET/WebSocket/etc) connections, the browser application would only make a single connection back to the streaming web application servers, and leverage muliplexing of messages between a browsers application views using client side functionality. However, with advance on server side scalability as above, is this still the correct approach?
Interesting, SockJS over on RabbitMQ discusses this very point, but is impacted by a SockJS issue:
In theory you could open multiple WebSocket connections, one for every module. Although suboptimal (due to the need to handle multiple TCP/IP connections), this approach will work for native WebSockets. But, unfortunately it won’t for SockJS due to a technical limitation of HTTP: for some fallbacks transports it is not possible to open more than one connection at a time to a single server.
There is however another issue on the client side to force one down the multiplexing road – browser maximum connections. However, sub-domains could aid this