Re: [hybi] Call for interest: multiplexing dedicated for WebSocket

["John A. Tamplin" <[e-mail]>]

On Wed, May 22, 2013 at 1:39 PM, Tobias Oberstein <
[e-mail]> wrote:

> Regarding implementing flow control above TCP (and below app), I found
> this:
>
> "Multiplexing on top of TCP in overall fails to deliver the advantages it
> is assumed to provide."
>
> Source: http://www.250bpm.com/**multiplexing<http://www.250bpm.com/multiplexing>
>
> Do you have an opinion on that?
>

One thing he doesn't address are resources used to keep lots of connections
open, both at the OS level and in intermediate network nodes (such as load
balancers -- try running tons of long-lived connections through an F5 for
example).  Also, he doesn't address the interaction of TCP slow start with
lots of new connections.  I also don't believe the equivalent of a full TCP
handshake is required to allocate buffer space.


> More important: what problem exactly does multiplexing solve? The current
> mux RFC mentions "scalability", but doesn't go into detail ..
>

Here is a use-case I envision:  Imagine GMail, G+ sandbar, etc all use
WebSockets heavily.  Many users may have multiple copies of such apps
running in tabs or windows in the browser, and some of these are going to
be separate (such as GMail and the G+ sandbar probably are separate apps
running on the same page and maintain their own connections to their
backends).  Currently, that would mean you have a ton of TCP connections
open to the server.  Servers don't handle tons of long-lived connections
very well (or intermediate load balancers), so you would greatly prefer to
have one connection per browser.  WS MUX lets you do that, by having the
browser aggregate connections to the same backend.  You could do some of it
at the app level, but it is going to be complicated and in many cases these
apps won't all be from the same vendor (for example, some widget on the
page that uses the GData API) and will have separate deploy schedules.

-- 
John A. Tamplin