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

On Wed, May 22, 2013 at 1:32 PM, John A. Tamplin <jat@jaet.org> wrote:

> On Wed, May 22, 2013 at 1:39 PM, Tobias Oberstein <
> tobias.oberstein@tavendo.de> 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
>

Is that still true today? Recent server implementations all boast they can
handle tons of connections.

> (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
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>
>