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

[Greg Wilkins <[e-mail]>]

Ian Hickson wrote:


> Then the author really should just combine the event sources into one (or 
> use the EventSource feature

But there might not be 1 author!   Mash-ups and portals and such things
will combine the work of many authors unknowingly onto the same page.
We want to encourage reuse of components and not require every webapp
to be rewritten from scratch with a shared messaging infrastructure.


> Could you describe the scenario in which you imagine an application 
> needing multiple two-way communication channels one after the other, each 
> for short periods of time, each with a different server-side development 
> team? I'm not really seeing the use case here.


Consider the google home page.  This can be customized with lots
of widgets from third parties.

Imagine the same sort of site, but fronting an organization with
lots of real time data. A stock trading site for example.

They may allow a user to populate their pages with widgets supplied
by third parties that may perform all sorts of trading analysis,
monitoring and trading.   I widget may establish "connections" to:

    + receive live price information
    + monitor the state of orders placed
    + interact with others in a process to create a
      complex instrument, swap etc.

These "connections" may be short or long lived (who
knows how long an order might take to complete).

For scalability of the service, you don't want every
widget to be given it's own TCP/IP connection.  Even
if you can handle the load, it is an unfair allocation
of server resources to give more to those with more
widgets on their desktops

These widgets should all multiplex onto the same
TCP/IP connection per user.


Of course the organization could provide a js framework that
did that multiplexing - but widget developers would be highly
unlikely to use it.

If they use websocket directly, then the code they write can
access the service both in the portal site and from other sites
that don't have the framework. Plus if they don't use the framework,
they get their own dedicated TCP/IP connection and they will get
some latency/performance benefits of other widgets that are sharing
a connection.  Of course this creates an arms race as it only
works if everbody else is sharing. Soon all widgets will be
using their own dedicated connection, then each widget would
start opening multiple dedicated connections (eg 1 per share),
trying to get more and more resources allocated.

Developers and resources are like 3 years olds and toys!
There is no such thing as optional sharing!



> You are assuming monolithic servers like Apache, with multiple frameworks 
> plugged into those servers. I'm imagining 100-line perl scripts. While we 
> have such differing goals, 
> ...
> In this world, there is no server
> to handle the multiplexing across multiple frameworks.


I really do not think you should be using your influence over the
websocket protocol to drive some agenda to revolutionize
server side development.

We cannot design a protocol that is only suitable for some
imagined future scenario.

Trying to enforce this future by making future protocols badly
support monolithic servers strikes me as some Orwellian mind
control exercise!



> If the channels are multiplexed, then we're assuming that the server-side 
> is an "aggregating resource" as you put it. If it's possible to use an 
> aggregating resource with a multiplexed connection, then why would it not 
> be possible to do it with a Web Socket connection? I don't understand.

Because in the real world, we have one set of developers writing
servers and user-agents and another set of developers writing
applications that run on them.

The infrastructure developers impose all sorts of restrictions on
the application developers:

  + sharing CPU and memory with other users/processes.
  + sharing connection and network infrastructure
  + enforcing origin policies, security sand boxes etc.
  etc. etc.


In your brave new world,  there are no infrastructure developers,
only application developers.

In this world, the application developers will throw off the
infrastructure shackles imposed on them, because indeed a
dedicated TCP/IP connections is better than a shared one.
Cross domain development is so much easier without security
models etc. Better let them run as root as well, because
then they can open any port and up their priority to
stop sharing CPU.

There are really really good reasons why infrastructure
is developed for application developers.    Infrastructure
is not only to enable applications, but it is to constrain
them and to force them to share resources fairly and to
respect security models.

But there is absolutely no way that any responsible organisation
is going to deploy a system where sockets opened by applications
programmers are exposed directly to the internet and run
with ad-hoc protocol implementations.


> Servers already have to deal with multiple connections per user, for HTTP. 
> I do not see how WebSocket makes things worse.

Multiple connections are allowed for HTTP as a necessary evil to get
around the intrinsic latency of the request/response protocol that
does not support message fragmentation or out of order responses.

Even then HTTP is meant to restricted to 2 connections.
Stupidly Recent user-agents have engaged in exactly the sort of
arms race I have describe above... lets have 8 connections and we
are faster than the other guys... doh! they have 8 too, ok lets
have 16.... doh! 32!  ... doh!


> If your OS' kernel is badly optimised such that multiple connections are 
> expensive, then instead of changing the protocol, fix the kernel. 

it's not bad optimization.   If you have 1 connection, you need 1 set
of buffers and when it is full you give back pressure on that
TCP connection.

If you have 10 connections, you need 10 sets of buffers and you have to
wait until you have received 10x the data from one user before you
apply back pressure.

The optimization you are looking for is to make that user share 1
connection instead of using 10!   There is no other way to optimize
away the buffer requirements!




> I assume it is a given that you would want a protocol to have the property 
> that connecting with path A, then opening a channel for path B, should 
> result in a connection with the same internal state as connecting with 
> path B, then opening a channel for path A.
> 
> Given the HTTP Upgrade mechanism whereby an HTTP server can have a 
> WebSocket script assigned to each path, you can end up in a situation 
> where connecting to A and connecting to B establish connections with 
> different server-side scripts.

How so.

I'm advocating abstracting developers away from connections.
Handler A will send/receive messages for path A
Handler B will send/receive messages for path B

Neither handler has any need to know if a shared connection was
used or not.


> The entire purpose of Web Socket is to provide a TCP connection to 
> JavaScript. That's the goal.

Really?  If it was, then why not just expose the real socket API?

Surely the aim is to establish bidirectional communication with the
server.  Whose to say that TCP/IP will be the favoured transport for
the entire life span of the applications using the websocket API?


In any case,  if the IETF is to endorse a new web protocol, I believe
that their charter is to consider more than just the needs of
javascript developers.


regards