Re: [hybi] WS framing alternative

[Jamie Lokier <[e-mail]>]

Greg Wilkins wrote:
> > 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?
> 
> sticky load balancer with SSL offload that works with any ws app.

This is the key thing, I believe.

WebSockets forces all negotiation of extensions to be done by the
application.

This prevents automatic extensions being done below the application,
so "works with any WS app" is prevented by the current proposal.

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

In this respect, WS is like TCP where it's hard to modify
transparently.  This may be intentional: WS is meant to be a web
application compatible TCP after all.  But there is some value in
automatic extensions below the application, as we've seen in HTTP.

Given that the only thing blocking this is the client's inability to
signal the server that it supports an extension, and that is so easy
and natural to do by allowing clients to add headers to the initial
request, I think that should be at least seriously considered.  Not
dismissed summarily.

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

That's similar to the compression example above.

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

Orderly close is more important than people realise.

A major problem with HTTP pipelining is you can't use it for
non-idempotent requests because the server may close the connection
any time, without implying an error condition.  That's one of the many
reasons HTTP pipelining often cannot be used, and that makes HTTP in
general slower and less network efficient than it could be.

The same applies to other request-response based protocols, such as
many of those expected to run over WebSocket.

Another problem with closing is that thing not mentioned in the HTTP
RFCs, but essential: lingering half-closed sockets.  If a server sends
a response followed by closing the socket fully, some clients sometimes
don't receive the whole response because of the way TCP and pipelined
requests clash.

Both of these are why orderly close is important - more important than
it appears.  Because it makes it safe to do other things.

I expect "pipelining" in the meaning used by HTTP, that is sending
multiple messages before getting a response to each one, to be quite
prevalant with protocols running over WebSocket.

That makes orderly close important for WebSocket, to avoid fragile
applications.  Hopefully I've illustrated the kinds of problems to
expect.  Unfortunately it's all a bit arcane.

There's nothing wrong with doing it in the application.  But I don't
have high expectation of it being done correctly in those "we don't
need no steenkin' framework" 100 line Perl scripts by inexperienced
authors.

-- Jamie