Subject: Re: [hybi] hybi Digest, Vol 8, Issue 41

From: Jason Duell <[email-masked]>
Date: Fri, 30 Oct 2009 14:58:30 -0700

Greetings, all.  I'm one of the developers on the Mozilla networking
stack.   We have a rather obvious interest in the discussion here, so
I'll be keeping at least roughly abreast of the conversations here and
chiming in when it seems useful.

> > Could I ask you to more concretely describe your problem so that I could
> > more concretely (maybe with actual code examples) describe the alternative
> > solution that I am describing?

>From my reading of the last few days' posts, it does seem like
focusing on use cases might be the best way to move the conversation
forward.  The more concrete the use cases, the better.

> > sticky load balancer with SSL offload that works with any ws app.

Is there any particular reason one couldn't do sticky load-balancing
just by remembering the TCP IP/port four-tuple for a given web socket?

> Here's an example: Just like HTTP, there could be value in an
> extension which compresses some frames.  If it worked well, that'd be
> a good thing to do _transparently_ in the browser+server, without
> awareness by the WS application.
>
> But you can't provide a transparent compression extension, because the
> browser has no way to signal to the server "I handle this extension".

This strikes me as a good example for why we might want meta-data, if
we can easily get it into the spec (by which I *really* mean easily
get it into the almost-ready implementations of the current ws
protocol/API drafts we already have in Mozilla and other browsers).
But more use cases would be nice, beyond compression.

> multiplexing protocol implemented in browser/server (not in application).

What's the use case here?  If a browser has two pages open that each
want to connect to the same server?  How likely is that?

> orderly closing a ws connection implemented in an application
> independent way.

I'm quite sympathetic to providing guarantees about closing (or
really, about delivery, which is what one really cares about usually).
 But I'm not clear on what the proposal is here.  Yes, HTTP allows
servers to arbitrarily close sockets, and thus we can't shove POSTS or
other non-idempotent requests into a pipeline.  But I don't see
anything in the ws spec that is equivalent.  So I'd like to see more
detail here.  What's the solution here (and to what problem(s)?)

<brief rant>It's notable the in the current Internet, the main
obstacle to things like pipelining are the existence of badly written
proxies and intermediaries.  These are the beasties that are still
preventing us from turning on HTTP pipelining by default (even for
GETs), all these years after HTTP 1.1 was specified.  So a cynical
part of me is tempted to believe that the easiest way to provide more
predictable close semantics for ws applications is to ram the protocol
past proxies via port 443/TSL, so that they can't muck up the works
with their "extended" behaviors... </brief rant>.

I feel better now.

Anyway, I look forward to more conversation on all of this.  I hope we
can find a good balancing point between the need to keep things
simple, implementable, and quickly deliverable on the one hand, and as
fully-featured as is useful/practical on the other.

Jason Duell
Mozilla

---

From: Ted Goddard <[email-masked]>
Date: Fri, 30 Oct 2009 16:42:07 -0600

Without multiplexing, I expect we will see each Ajax component
in each page opening its own socket, and multiple pages open
to the same server is very common (users often forget that
they already have a window open in their browser) so a hundred
connections to a single server would not be unexpected.

It's easy to ignore this at the moment because we are so accustomed
to the multiplexing in HTTP 1.1 (think back to the network overhead
of HTTP 1.0).

Regards,
Ted.

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 31 Oct 2009 10:46:25 +1100

> just by remembering the TCP IP/port four-tuple for a given web socket?

IP stickiness is a reasonable solution when cookies are not available,
but it is far from perfect.  Every user from AOL will look to be
coming from just a few IP addresses - which can and do frequently
change for any given user.

Cookie based sticky load balancing is well established and understood
and surely is a good basis to start with.

Note also that load balancers also communicate meta data to the server
they are balancing for:
  + SSL session IDs and client certificates.
  + X-Forwarded-For headers

> want to connect to the same server?  How likely is that?

it's not just two pages, but multiple widgets, iframes and tabs.

This is one of the biggest pain points that I currently have
deploying reliable comet/push applications at the moment.

While I  think multiplexing should be supported in the base
protocol,  I'm currently not advocating that we support it
in the ws protocol.

All I'm currently asking is that ws allows the easy transport
of meta-data so that multiplexing can be transparently implemented
without explicit support from the application code and without
breaking non multiplexing interoperability.

> detail here.  What's the solution here (and to what problem(s)?)

The primary problem that I would like to see addressed is
the issue of idle shutdown of connections.   Currently the client,
server or intermediary may decide a connection is idle too long
and close it.   But there are no common timeouts, no way to
discover these timeouts and not way to negotiate these timeouts.

Thus clients will often select and idle connection and try to use
it only to discover that it has been closed.   Lack of orderly
shutdown means that the client has no idea if the messages sent
have been delivered or not.

Websocket will make this a server problem as well, because
servers can now try to use a connection that has been idle
closed by an intermediary or client.

Having an orderly close will allow implementations to distinguish
between a failure (for which there is nothing much that can be done
short of a reliable protocol on top) and a routine idle shutdown,
which would now be able to be handled without any message loss.

> with their "extended" behaviors... </brief rant>.

Trying to do an end run around the intermediary vendors and their
particular concerns (and business interests in providing value add)
is hardly going to encourage better future compliance to internet
standards.

Perhaps by considering their concerns and involving them in the
process, a widely implemented solution can be achieved.

> fully-featured as is useful/practical on the other.

regards

---

From: Jamie Lokier <[email-masked]>
Date: Sat, 31 Oct 2009 02:23:32 +0000

> connections to a single server would not be unexpected.

Yes, this is exactly what I expect to happen.

(I'll add that deliberately opening multiple tabs to the same server
is quite common too.  Like, when you want to read 10 different
articles from the same news/blog site, many people open 10 tabs by
right-clicking from the headline page, let the pages load in the
background, and work their way through them)

Sharing WebSockets between components on different pages is difficult
for the simple reason that browser tabs are quite independent.  (But I
haven't seen anyone advocate that they should use separate HTTP
connections...)

On a single page, Ajax component authors _could_ cooperate so their
components share connections, but how likely is that?

Even with good intentions, it's technically *quite hard* to share
connections between independent components on a single page.

That's because one component sending a large message can block
progress of all other components on the page, if they share.  And one
component taking a long time to accept messages can block all the
others even if it's a short message.

But if they all have separate connections, they do not block each
other, so there's a strong motivation to do that.  It is, after all,
easier to program as well.

That is why I advocate a slightly more advanced multiplexing, akin to
interleaved HTTP chunks, where no component can block the progress of
any others, and chunks can be interleaved in a fair, orderly and
network-efficient manner.  I'm pretty sure that would improve the
browser experience unequivocally for almost everyone.

-- Jamie