Re: [hybi] Proposed way forward for WebSockets

[Jamie Lokier <[e-mail]>]

> On Tue, Jul 27, 2010 at 09:06:29AM +0100, Dave Cridland wrote:
> > FWIW, I think current thinking has swerved away from versions - if  
> > you need to actually change version incompatibly, then you may as  
> > well define a new protocol. If you need to incrementally add  
> > features, then proper feature negotiation works fine.

Fwiw, I agree.

> > I'm not against versions, mind, I just think they're generally a last  
> > resort, and a simple "I support these optional features" statement  
> > from one or both sides works much more effectively in most cases.

I agree with that too.  It's good to *have* versions and
identification strings available as a last resort, but it's important
to make sure there's a better way for the other end to detect features.

Willy Tarreau wrote:
> I understand your point but I'm not convinced at all. A version is
> a short way to advertise a feature set. Once you have to send all
> of your requests with "WS-supported-feature: XXX, YYY, ZZZ", then
> you'll find it a lot cheaper to define a new version which sets the
> most commonly used sets by default so that we don't have to enumerate
> them all.

It's not great: The new implementation then doesn't use those features
with older implementations that support the features perfectly well.

> For instance, in HTTP, since version 1.1 we don't advertise
> support for keep-alive nor do we advertise support for transfer-encoding,
> those are covered by default by the version.

HTTP is an example of it not working very well :-)

Most HTTP/1.1 clients still send a HTTP/1.0 keep-alive extension
header, because saying HTTP/1.1 doesn't help the 1.0 servers.

Moreover, most HTTP/1.1 clients don't use transfer-encoding for the
request, even though it's standard, for a variety of reasons.  They
don't use chunked, and compressed transfer-encoding is rare in a
request.

HTTP/1.1 pipelining is avoided in many cases where it might have been
usable - even with servers that confirm they support HTTP/1.1 in an
earlier response.

All that is primarily because HTTP clients have no way to negotiate
with the server, so they have to stick with a common subset that works
with all servers.

In other words, HTTP negotiation either by feature tokens in headers
or by version number, is quite bad for the client-to-server direction.

It is an open question whether "HTTP/1.2" could ever be deployed or if
it would break.

> > There's keepalive frames - ie, I send you data, and you throw it on  
> > the floor - and pings - ie, I send you data, and you send something  
> > back.
> 
> yes you're perfectly right, I tend to merge them but they're distinct.

There's a third type: status-keepalive frames which confirm that state
previously sent is still valid for a given time interval.  That's
application layer, but it benefits from aggregation just like other
keepalive types.

> And also the application will not be aware of the TCP ACK, it's only
> the system. The application only knows it could successfully push the
> data to the system's buffers and that the connection was not yet
> detected as being broken.

Anyway TCP ACK is a false positive if there's a transparent intermediary.
It is not useful.

-- Jamie