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

github offer a SockJS multiplexerWebSocket-multiplex

~ by mdavey on March 4, 2014.

3 Responses to “Multiplexing and WebSockets”

  1. I don’t see why you *wouldn’t* multiplex. Even if you’ve done all the tweaking and tuning and hardware-buying to get millions of TCP connections, via multiplexing you’d be getting millions * (number of multiplexed streams) streams.

    Non-multiplexing approaches seem unnecessarily resource-heavy, at least over TCP. They force you to confront scaling problems much sooner than you would otherwise need to, and thus make all the associated tradeoffs and technical investments. One connection per client is definitely the way to go.

    Relatedly, I was recently at an Ember meetup where one of their engineers talked about how they structure their analytics dashboard, which is based on Rx observables on both client and server side. Again, they multiplexed these observables across a single web socket connection per client.

  2. I just read REST is for Sleeping, MQTT is for Mobile which provides an interesting alternative. Especially

    IBM has open sourced all of its MQTT source code via Eclipse.org including the new HTML5 MQTT over WebSocket JavaScript which enables MQTT in any HTML5 container including mobile browsers, desktop browsers, vehicle infotainment, consumer electronics. I’m doing 13,000 messages a second on my iPad with a pure HTML5 app developed in Worklight. I don’t think you could do that with HTTP.

  3. I discovered your website site online and appearance some of your early posts. Maintain the really good operate. I simply additional the Feed to my MSN News Reader. Looking for toward reading more from you at a later time!…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: