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

[Greg Wilkins <[e-mail]>]

Ian Hickson wrote:


> At this stage my recommendation if you think multiplexing is important
> would be to propose an alternative protocol and get browser vendor buy-in
> for that protocol.

which is exactly what I'm trying to do with BWTP.

but I do wish to understand your view point and what has influenced
your design decisions with websocket.     So while I appear to
disagree with you on many things, I do appreciate you taking the
time to argue your point of view and explain your reasoning.

As a result or your comments and others, the BWTP proposal has
already been greatly improved and hugely simplified.


I am entirely convinced that either a reasonable simple extension
to websocket or something like a refined BWTP is possible as a reasonable
compromise between the different points of view.



>>> However, WebSocket connections are long lived by design,
>> I do not believe you can anticipate websocket usage over the long term.  
>> Just because you think now they will only be used for long lived 
>> connections, that may not always be the case.
> 
> Well using Web Socket for a short request-response burst would be pretty 
> stupid (given HTTP)... What other uses do you have in mind?


Which is why having a websocket be associated with 1 and only 1
server side resource is a problem.    A client may be interested
in many event sources from a server, but each might only exist
(or be of interest) for a short period of time.

Sure it is possible to create an aggregating resource to avoid
having to have multiple short lived connections to each real
resource as it comes and goes.... but only if all the resources
are from the same application/framework/development.

Making multiplexing a transport concern means that applications
and frameworks do not need to consider connection efficiency
when designing their event streams.



>> It is short sighted to build such limitations into a once-in-a-decade 
>> chance to upgrade the protocols we use on the web.
> 
> This is not a once-in-a-decade chance.

I hope you a right.  But still no reason to not try to get it
right as possible in the next iteration.

>>> and the cost of setting up a connection therefore is insignificant 
>>> compared to the cost of the protocol itself.
>> There is also a cost associated with maintaining and servicing a 
>> connection.
> 
> This would be the same cost associated with maintaining and servicing a 
> channel in a multiplexed connection.

Sorry but this is just wrong.

Both approaches need the application end point for the channel
and all its associated resources.

But only the multiple TCP/IP connection approach needs additional
kernel space buffers, file descriptors and larger select sets etc.

The key difference is that with multiple TCP/IP connections, the
server has to undertake to read a windows worth of data on each
of those connections.   With a multiplexed solution, only a single
window needs to be read before back pressure is asserted and
the flow of additional data slowed to match the rate of consumption.



>> Implementing connection policies is not something that should be left to 
>> the application developer. It is far far better that the browsers 
>> implement connection control policies.
> 
> I disagree. I think it's far better that the _server_ decide the 
> connection control policies. That's the model Web Sockets follows (as an 
> author you'll do whatever the server expects).

How can a server influence the connections that a client opens, other
than to refuse excess ones.   That is pretty course grained "control"



> 
> On Tue, 13 Oct 2009, Greg Wilkins wrote:
>> But multiplexing can be much much simpler.  At it simplest,
>> it just needs a channel id in each frame and the channel creation
>> can be automatic.
> 
> Multiplexing at the per-path level would be of extremely limited use, 
> IMHO. If there really are multiple widgets talking back to the same 
> _server_, they certainly won't be talking back to the same _path_.

If by path, you mean server side resource or URI, then I'm definitely
saying that we should be able to multiplex multiple paths over the
same TCP/IP connection.

HTTP is not limited to get the same URI over the same connection, so
why should websocket or similar?

> 
>> But even if the frameworks implemented to same wire protocol for 
>> multiplexing, they would not be able to:
>>
>>   + share connections between frameworks
> 
> Even with multiplexing we wouldn't be able to share connections between 
> server-side frameworks -- why would someone use two client-side frameworks 
> but the same server-side framework?

Because multiplexing should be built into the transport and will not
rely on a server side framework.

Currently HTTP requests get delivered to the appropriate server side
resource without the server-side framework or developer being at
all aware of what connection(s) were used.

why must routing of messages between client side components
and server side components be tied to a TCP/IP connection.  The
path is identified by a URL and neither the client nor server
should care if a dedicated or shared TCP/IP connection is used.


>>   + share connections with code written directly to the websocket API.
> 
> That's basically just another framework.

except that it is one that you into which cannot easily insert
additional layered protocols.    Let's say RFC66666 comes out which
is the universally agreed best way to multiplex messages on top
of your proposed websocket protocol. How are you going to get
an implementation of that inserted into every direct usage of
the websocket API?


>>   + share connections with other iframes, tabs and/or windows.
> 
> This seems far too infrequent an occurrance to really optimise for.

Hello????  Do you ever use a browser????   Are you telling me you
have never opened two tabs/windows to the same website either
accidentally or on purpose???

One of the keen users of this technology that I have encountered
is traders, who habitually have 3 huge screens on their desks with
umpteen windows to their trading applications, all with slightly
different view.


> 
>>   + implement a strong origin policy for security
> 
> I don't understand what situation would lead to multiple channels having 
> different origins but talking to the same server with the same 
> authentication cookies and the same path.

It is entirely plausible that a service might publish events, some
of which are only for code from the same origin and others are either
for code from any origin or from a specific set of origins.



regards