Thanks David, Yes it makes sense but the algorithm by doubling and halving the intervals may never get close to the actual timeout value.
You could slowly increase the interval and then rapidly decrease it upon a timeout. Like in the TCP congestion control algorithm. But I do see the benefit of using a test port and only allowing the live traffic port to use the last "safe"estimate discovered. Does anyone know of any any studies on how NAT timeouts tend to change? There is a very interesting study by Cornell (below) which discusses the distribution of NAT timeouts for TCP but not how they evolve over time. http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat.pdf I'm currently doing some research on keepalives in a P2P setting, and adapting to NAT timeouts hasn't really been addressed as far as I know. Thanks again, Richard. David Barrett wrote: > Hi Richard, sorry for the slow response. It works like this: > > I use two UDP ports: one for testing, one for live traffic. > > With the test port I send a single UDP packet to a central server, > containing a timeout value. I think the message was something like: > > PING > Delay: 1000 > > The server just holds onto this message as long as requested, and then > sends it back to the apparent host from which the packet was sent. If > the delay is less than the NAT timeout, then it'll get through and the > client will know "ok, 1000ms is fine", at which time it doubles the > timeout and tries again. If the client doesn't get the response on > time, it concludes that the delay is longer than the NAT timeout, and > then halves the delay and tries again. This continues indefinitely, > which is important because NAT timeouts have a nasty habit of changing > spontaneously (such as with NAT load). > > The whole purpose of this test port is to estimate the NAT timeout by > gradually ramping up a "safe" estimate until it is no longer safe. > > With that in hand, you can use this safe estimate for setting your > keepalive period with peers: just make sure you send and receive a > response (either natural through real traffic, or artificial through a > PING) within that safe window and you're good to go. To be extra > safe, I actually have both sides perform this calculation, which is > perhaps a bit wasteful, but works well enough. > > Does that make sense? What are you using this for? > > Good luck! > > -david > Follow me at http://twitter.com/quinthar > > Richard Price wrote: >> Hello David >> >> I'm interested in the adaptive algorithm you used to determine >> keep-alive frequency in iGlide. Unfortunately, I couldn't find any >> documentation directly about it. >> >> Here's a little snip-it you posted on the P2P hackers mailing-list a >> while back which caught my eye. If you've any further information I'd >> be really interested to read it. >> >> Kind regards, >> >> Richard Price. >>> But another entirely separate (and more valuable?) use of keepalives >>> is to >>> keep NAT mappings alive in a hole-punching scenario. With iGlance >>> (which is >>> being presented at CodeCon on Saturday) I use an adaptive approach >>> where I >>> look for the slowest keepalive frequency that works. Adaptiveness is >>> critical, as I've seen some NATs that start with 5-second windows, >>> but grow >>> up to 256-second windows over time. >> > _______________________________________________ p2p-hackers mailing list p2p-hackers@lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers
