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

[Jason Duell <[e-mail]>]

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