Re: [hybi] NAT reset recovery? Was: Extensibility mechanisms?

[Vladimir Katardjiev <[e-mail]>]

On 19 apr 2010, at 16.04, Jamie Lokier wrote:

> Vladimir Katardjiev wrote:
>> - Our hypothetical amateur programmer, testing his websocket
>> connection against localhost, won't see the need for keepalives, but
>> the protocol requiring them will stop his application from failing
>> on the Wild Web. All he needs to do is echo back the bytes the
>> browser sent, and the expert browser programmer handles the rest.
> 
> Keepalives are great, but this isn't a nice way to implement them.
> 
> If they are required by the protocol, then the protocol should
> implement them itself.  (Besides, echo-reply isn't always bandwidth
> efficient, depending on keepalive the needs of client and server).

Yeah, it's not the best but it fulfils the design pattern that has been pre-eminent throughout the WebSocket spec -- that everything should be verifiable by the client, because that is the only "trusted" side. While I don't agree with the assumption that only the client should ever be trusted, it is a sufficient base case and only incurs trivial complexity increase by the server. Better an agreement on _a_ keepalive than no keepalive agreement?
> 
>> So I'd rather say I am having trouble seeing what applications would _not_ want keepalive functionality as part of the base offering of WebSockets.
> 
> Well, there may be disagreement over what type of keepalive, because
> the optimal choice is both application dependent _and_ network link
> dependent.

I'd love to have that discussion. It means there'd be an acceptance of keepalives as part of the WebSocket spec.
> 
> At the moment, it can be implemented by the WebSocket application
> (albeit suboptimally, and any network link dependency has to be known
> to the application as well).

Yeah... question is if this functionality isn't better handled by WebSockets for a majority of the applications, and the rest can opt out of it.

Vladimir