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

[Dave Cridland <[e-mail]>]

On Tue Apr 20 07:50:56 2010, [e-mail] wrote:
> I would not want to make the keepalives peer-to-peer in a sense  
> that also the server could send keepalives. I think the client  
> should be in charge. The reason is that as a client developer for a  
> mobile device I would like to be able to send keepalives as  
> infrequently as possible. We have had some bad experiences with  
> IMAP servers sending stuff frequently back to the client  
> (presumably because not all clients are clever enough to do any  
> keepalives themselves - this is a risk of course if we don't  
> specify this at all in websocket spec), and the client has no way  
> to affect their rate, which has been fixed.

I've seen this work in two different ways.

First, in IMAP, we've found that the client needs to be in control,  
as it often knows better - however, others (including Mark Crispin)  
found that having the server send keepalives when it'd otherwise be  
shutting down the session is useful. Note that in IMAP, there are  
technically no actual keepalives, but servers can send an ignorable  
"* OK", and in extreme cases, can fake a delivery to cause a client  
to do something. Clients have a NOOP command. I suspect a lot of the  
issues with IMAP relate to there being no simple way for the server  
to ping the client built-in to the protocol.

In XMPP, however, we've found that having the ability to ping the  
client from the server is very useful. In XMPP, there's two distinct  
protocol features which enable TCP-level keepalive. Firstly, either  
side may send a SP character between stanzas. Secondly, each side may  
actually ping the other. Having the server send a SP on an idle  
session is useful for defeating NAT timeouts, whereas the ping  
(XEP-0199) is extremely useful to definitively check reachability.

> If there really is a requirement for the server to see keepalives  
> at a certain minimum rate (for instance so that it can abandon  
> stale connections), I would then have that negotiated so that the  
> server can tell that back to the client who would still do the  
> sending. But I'm not sure if that's needed.

I think we need all cases possible, then some sensible advice to  
implementors. In the XSF, we've learned a lot about how to defeat NAT  
timeouts and get early failure detection, and the main thing we've  
learned is that things change - only a year or two back using  
long-lived TCP over mobile networks was really difficult, whereas now  
it's much better.

What's more interesting, to me, is what to do if the connection does  
break.

If each connection is granted an identifier, and - moreover - the  
client can request a specific identifer to be reattached during the  
HTTP Upgrade negotiation at a known sequence point, then in principle  
a WebSocket needn't be conceptually broken even if connectivity is  
entirely lost due to a NAT reboot.

Something very similar happens with XEP-0198, where XMPP clients can  
reacquire a running XMPP session after TCP is lost.

Dave.
-- 
Dave Cridland - mailto:[e-mail] - xmpp:[e-mail]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade