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

[Greg Wilkins <[e-mail]>]

Jason Duell wrote:
> 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?

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



>> 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?

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.



>> 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)?)

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.





> <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.

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.



> 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.

regards