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

[<[e-mail]>]

Hi,

Dave Cridland wrote:
>
>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.
>

Yes, this "* OK" is what I have seen. I agree that the lack of an explicit in-built mechanism is an issue and we should learn from that for WebSocket.

>Having the server send a SP on an idle session is 
>useful for defeating NAT timeouts, 

Here I'd really prefer the client to do it, as it should know better. And the host can potentially optimize between different connections etc.

>whereas the ping
>(XEP-0199) is extremely useful to definitively check reachability.
>

Is that being used today by servers? 

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

Yes, things have improved. For instance, despite the looming IPv4 runout, many mobile operators have actually gotten rid of NATs and are giving out public addresses. There's however still a firewall with typically 10-60 minute timeout for TCP.

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

This is definitely something to consider.

Markus