Re: [hybi] Proposed way forward for WebSockets

[Willy Tarreau <[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.
> 
> The only advantages of bundling such features is where it makes  
> little practical sense to have feature B available without feature A,  
> and for political/marketing reasons, to encourage deployment of a  
> package of features.
> 
> The latter can be addressed by defined profiles of features (rather  
> like "WiFi" is a package of IEEE 802.11 features, or XEP-0243  
> packages up XMPP featuresets).
> 
> 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 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. 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.

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

> These are two distinct cases, and although in general terms, TCP will  
> make both of them a two-way communication, a "real" ping can be used  
> for substantial diagnostics, whereas I suspect that the TCP ACK will  
> sneak under various thresholds.

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.

Regards,
Willy