That's interesting, How do you conclude that a node has left the network?
I can imagine that clients can assume the server should be up most of the time and happily reduce the size of the interval until a suitable value is found. With UDP there is also little or no overhead when (re-)establishing a connection. But a server connected to multiple clients may not be able to make that assumption. Perhaps after the interval has been reduced a certain number of times? Richard. David Barrett wrote: > Agreed, those would be good ways of getting a more accurate read. > > As for how they change, I saw that mappings would increase their > timeout with age. I distinctly remember at least one mapping that > would start at just a couple seconds, but then gradually ramp up to > 256 seconds (I stuck with powers of two). I also recall some mappings > that would stay constant for a long time and then suddenly decrease, > but I had no indication as to what triggered the change. > > -david > > Richard Price wrote: >> 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
