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

[<[e-mail]>]

Hi,

How about this:

I think the websocket spec should define two special frames explicitly for keepalive purpose:
- Keepalive request frame; this is sent by the client
- Keepalive response frame; this is sent by the server as a response to the keepalive request
Depending on what the websocket protocol syntax allows, these frames could be actually just single bytes (frames starting between 0x80 and 0xFF seem to be reserved for something special, so we would use two of these code points).

The client would generate the keepalive requests as often as needed when there is no other traffic frequently enough. By the response from the server the client would know that the transport connection (TCP) is still up, the NAT and intermediary state is thus also up, and actually the server is also alive on the app layer.

How often the keepalives are sent is a tricky question, and may be beyond what is defined in the websocket protocol, as it depends so much in the environment (the middleboxes in the access networks, the web intermediaries and so on), and on the other hand sending too often consumes battery on wireless devices. The client can find out the optimal rate in its current environment by trial and error. What could be done is that the server might be able to hint the client on a suitable rate, although typically the server has no idea on e.g. NAT timeouts in the network the client is located (but in principle it could remember which values worked last time from that particular IP range). That would make the keepalive frames slightly more complicated but still within a few bytes. Yet another option is actually to standardize some kind of keepalive rate iteration algorithm.

Basically all other protocols that need to maintain long-lived TCP connections have done this: SIP and XMPP exchange 'CRLF's between client and server, for instance. HTTP based long-polling protocols send entire HTTP requests.

Markus


________________________________
From: [e-mail] [mailto:[e-mail]] On Behalf Of ext Vladimir Katardjiev
Sent: 19 April, 2010 17:29
To: Hybi
Subject: Re: [hybi] NAT reset recovery? Was: Extensibility mechanisms?


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