Re: [hybi] An alternative design for the web socket handshake

[Jamie Lokier <[e-mail]>]

Greg Wilkins wrote:
> On 17/05/10 02:16, Maciej Stachowiak wrote:
> > >
> > > On May 16, 2010, at 12:38 PM, Jamie Lokier wrote:
> > >
> >> >>
> >> >> WebSocket would be almost unique, as a TLS user, in seeming to use
> >> >> 10-50 connections per individual user by design (the current one,
> >> >> where browsers can't share connections between WebSocket objects).
> >> >> TLS itself isn't designed with that kind of usage in mind.
> > >
> > > People keep saying this, but do we have any evidence there would be 10-50 connections per user to the same server? For web apps using the "hanging get" approach, do you get
> 10-50 connections per user? If not, why would you expect it for WebSocket? None of the typical "hanging get" techniques have a built-in way to do connection sharing. Why do we
> expect things to be different with WebSocket?
> Maceij,
> 
> we have no hard evidence yet because websockets is not yet
> widely deployed.   But there is anecdotal evidenced based
> on experience and observation.

I agree.  We have current user behaviour and current HTTP messaging
styles to guide us, and a bit of vision about what might become viable
with an easier to use WebSocket object.  That's all we can do prior to
the first big rollout.

If there is data on hanging GET, that would be very helpful.

Data on rapid polling AJAX would also be helpful - because that is
often used today due to hanging GET having implementation difficulties
and also perceived complexity.  If WebSocket takes off, it's likely to
replace some of these rapid polling AJAX uses too.

> My experience is that even within simple web applications developed
> by the  same group, there are multiple independent concerns that
> require a feed of "push" events from the server or a messaging style
> interaction.

I also think this will increase considerably, as increasingly
sophisticated frameworks and server-side languages are able to
automate event-driven updates from simpler descriptions, and an
increasing trend to web developers being expected to provide "web app"
style delivery gain traction (along with tools to make it easier).

> It is also a frequent occurrence that a user will either inadvertently
> or deliberately open many tabs/windows to the same site, so any multiple
> of connections on 1 page can easily be multiplied 2 or 3 times more.

Yes, easily.

Also, having lots of open but "background" tabs/windows is quite
common, and it's not uncommon for those to be open 24 hours a day.
Those have little HTTP traffic when backgrounded, but their WebSockets
will continuously emit a level of keepalive traffic.

> These are already issues with hanging get frameworks, even though
> they encourage shared connections when used within the same frame.

It would be great to have some hard data on the current network/server
impact of hanging get frameworks - and rapid polling AJAX frameworks.

They are both relevant because WebSocket (assuming it works) is a
suitable replacement for both.

(I'm still amazed that there's a crowd who consider polling AJAX every
5 seconds or so to be *inherently* more scalable than hanging GET -
because that is true in common styles of server implementation.)

Do you have any such data?

> There a currently speed advantages in using multiple
> connections - for an example, see the slow start paper on the
> SPDY site.    Developers who realize this will deliberately open
> more connections than necessary in order to achieve real or
> even imaginary performance advantages.

Interesting, thanks.

(We could do with gathering the "hard numbers and data" together a
bit, I'm thinking.)

> Finally, there is the convenience aspect.  Sharing a connection
> is difficult and can complicate an application.  It is something
> ideally done in infrastructure.    Any developers working to
> the websocket API are highly unlikely to go to the effort of
> sharing a connection, when opening a new one is much easier.

More than difficult - it's technically impossible (or extremely
difficult) for Javascript apps to share connections between
tabs/windows in a single browser, between the browser and non-browser
apps (such as phonetop status applets), and between multiple users
behind a shared connection.

There are also client environments where concentrating users'
connections through a local proxy and fanning them out at upstream
proxy on the other side of a limited uplink - to reduce keepalive
costs and aggregate short messages into fewer packets - would be
useful.  I have no data on how common this is going to be with
WebSocket (but I have done it, with other protocols, and it makes
quite a difference.)

-- Jamie