Re: [hybi] Multiplexing in WebSocket

[Ian Hickson <[e-mail]>]

On Thu, 22 Oct 2009, Greg Wilkins wrote:
> Ian Hickson wrote:
> > Having a simple protocol doesn't preclude this.
> > 
> > Having a complex protocol requires it.
> 
> I think this is a straw man.  Any protocol that is not websocket is not 
> by definition complex.

I didn't mean to imply that, my apologies.


> Something like BWTP could also be written over a weekend in perl or 
> similar.  It could also run in the many little server mode that you 
> think is best.
> 
> The hard part of "monolithic" servers is not implementing the protocol.  
> It is implementing as scalable protocol, an application environment, all 
> the goop specified by JEE specs (if you are in java), the security 
> sandbox, etc
> 
> If you don't want all that, then even HTTP can be built in a day or two 
> - I've done so several times.

I am skeptical that a _fully conforming_ HTTP server can be implemented in 
a weekend by most Web devs.


> > On Sat, 17 Oct 2009, Greg Wilkins wrote:
> >> 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.
> > 
> > I don't buy that these widgets will all be communicating with the same 
> > backend.
> 
> Why not?  if they are all on a portal page put together by www.bigCompany.com
> then they all might be accessing the services of bigCompany.com

Then they could just use a common JS library that multiplexed for them. 
Why would www.bigCompany.com open multiple connections to itself, if it 
wanted to save on the number of TCP connections to its servers?


> Currently companies put static content onto common CDN services, and 
> maybe in future there will be dynamic services on common services.
> 
> I've already seen social networking services, advertising services and 
> analytic services having common components on many many websites, so it 
> is increasingly likely that multiple unrelated pages from different 
> sites will access common services on common hosts.

Sure; but then they would almost certainly also want common resources 
locally, and could therefore just use a common shared worker with a single 
TCP connection.


> > If the widgets are from third parties, then they wouldn't all talk 
> > back to the same server.
> 
> Not if the widgets are all different ways of presenting the data/events 
> from the same server.

I do not believe this is the 80% case, and thus do not think it is worth 
addressing in the first version.


> > I disagree with your pessimism here. I think there is ample evidence 
> > that people are happy to use JS libraries to talk to services. 
> > Consider Google's GData API. Do you know anyone who uses this API 
> > without using the GData JS library?
> 
> If there was a performance advantage to be gained, then I'm sure they 
> would.  But with XHR based APIs, coding to the GData API or to XHR gives 
> you the same access to the underlying network resources.
> 
> If there was an API in the browser that gave me a dedicated HTTP 
> connection, I would certainly use it now for long polling - even though 
> I know that rationally that is not the best thing to do.

I think authors are lazier than that, personally.


> > The IETF is welcome to do whatever it likes. The only reason Web 
> > Sockets is here is that the IETF wanted it here.
> 
> And since you have accepted the IETFs invitation to submit a draft, you 
> should do so in good faith and not expect the IETF to rubber stamp what 
> you've done simply because you have no intention of changing it.

I've made lots of changes to the WebSocket protocol -- heck, I've made so 
many changes based on feedback here and elsewhere that people have started 
complaining that I've made too many!

There is a difference between not making any changes, and not making the 
changes you want me to make. I do not believe that multiplexing is a good 
idea in this protocol.


> Remember, it is not just the browser vendors that websocket must win 
> over.  In order for it to be a success, then all kinds of web 
> infrastructure needs to be updated to support it - firewalls, proxies, 
> web caches, corporate policies etc. etc.

Actually, as designed, WebSocket does an end-run around most of these. The 
only case I'm aware of where WebSocket would need help is in environments 
that do not even allow port 443 traffic to pass through unmolested.


> You can open a real socket from a web browser now with commonly
> installed plugins - but it is not that useful because the network
> community does not allow arbitrary sockets to traverse the network.

Actually commonly installed plugins have security models to prevent 
arbitrary port connections, just like WebSockets. Personally I think the 
WebSocket security model is better than, say, Flash's, but at the end of 
the day it has much the same effect and provides much the same feature. 
The difference between Flash and WebSocket is the same as between Flash 
and HTML5 <video>: one is proprietary, the other is vendor-neutral.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'