Along the lines of what David was mentioning: Establishing dozens of UDP "connections" (from one peer out to others) at the same time can cause some issues for certain NATs/Routers. There are much more "connection" failures (read: TCP-like UDP) when establishing many connections at once than establishing a single connection. Not sure whether this is a buffer issue on the NAT/router or something else, but Barrett might have more insight here.
T On Thu, Mar 26, 2009 at 10:45 AM, David Barrett <dbarr...@quinthar.com> wrote: > Taral wrote: >> On Thu, Mar 26, 2009 at 9:42 AM, David Barrett <dbarr...@quinthar.com> wrote: >>> However, X can change. So rather than doing this once and being done >>> with it, use this approach to "walk up" to a keepalive frequency that is >>> "too low", then walk back "down" to a frequency that is "unnecessarily >>> high", and then repeat. I've found X can change for a given router (or >>> collection of routers), perhaps under load? So this keeps the system on >>> its toes. >> >> Interesting idea. What happens if you're trying to maintain more >> connections than the NAT can handle? Your X will drop to zero? > > Presumably. I did most of my work in the range of 40 UDP peers, so we > weren't (to my knowledge) hitting any caps there. > > Then again, if you're talking with more peers than your NAT can handle, > aren't you screwed no matter what you do? It seems at that point you've > got a bigger problem than NAT binding timeouts. > > -david > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@lists.zooko.com > http://lists.zooko.com/mailman/listinfo/p2p-hackers > _______________________________________________ p2p-hackers mailing list p2p-hackers@lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers
