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
