Re: [hybi] Multiplexing in WebSocket (Was: HyBi Design Space)

["Infinity Linden (Meadhbh Hamrick)" <[e-mail]>]

the problem i have with doing addressing for multiplexing channels on
a single connection in the application layer is that it effectively
disallows intermediaries from reasoning about distinct messages on
distinct channels. i do agree that doing multiplexing in the
application layer is much more flexible and for many deployments "this
is a good thing." does it make sense to have a multiplexing option in
the protocol that can be used by people who want their intermediaries
to understand this sort of thing, but not make it mandatory? that way
i could hire someone to hack squid to recognize and cache multiplexed
reverse responses and people who want to do something more flexible at
the app layer can still do it.

fwiw. i'm coming at this from a "http as a substrate" perspective,
where (i suspect) we're going to have more client -> server responses
with large payloads than might be typical in a browser app. and since
client -> server communication is slower in may broadband models, for
the few protocol transactions where we're responding to the server
with large, cacheable payloads, i would be nice if we could have a
standard protocol understandable by intermediaries.

-cheers
-meadhbh

On Fri, Oct 9, 2009 at 14:47, Ian Hickson <[e-mail]> wrote:
> On Fri, 9 Oct 2009, Salvatore Loreto wrote:
>>
>> again the multipexing is something important for both server developers,
>> but as far I understood following the discussion in whatwg ml, also
>> browser developers or at least w3c people agree that WebSocket protocol
>> as proposed could be improved, also with the help of HyBi, to support
>> other features and "in-protocol multiplexing sounds like one of the most
>> valuable additional features"
>
> FWIW, so far I've concluded (based on long discussions with a number of
> developers and implementors) that multiplexing would actually not be that
> great. It could probably only be used for multiplexing to a single
> websocket path, without making the handshake highly asymmetric or breaking
> the HTTP compatibility. If it's intended for per-client multiplexing, it
> can easily be implemented at the application layer, where a much better
> job can be done that could be done at the protocol layer. If it's intended
> for multiclient multiplexing, then it's only helping server load, not
> client performance, and server load isn't especially an issue here.
>
> It's not analogous to keepalive and pipelining in HTTP. In HTTP, the cost
> is in setting up the connection, which happens a lot. Multiple resources
> on one origin incur multiple TCP round trips just to get the connections
> set up, and this can severely impact performance. However, WebSocket
> connections are long lived by design, and the cost of setting up a
> connection therefore is insignificant compared to the cost of the protocol
> itself. There's also something to be said for relying on TCP's built in
> congestion control -- if you were to open two connections to a server,
> one sending vast amounts of data, and one sending just the occasional
> critically important notification, it would be best if the latter could
> avoid getting throttled along with the first.
>
> As with anything, though, there's always the option of changing this if
> strong arguments one way or the other are put forward. We can also
> introduce multiplexing as a new version of the protocol in a future
> version.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>