The proximity handling in Bamboo would most certainly stabilize proxy selection for NAT traversal between endpoints. No need for STUN there, it would greatly simplify the client as the client would learn all it needs about itself from the DHT, as learned by others. The DHT would tell the endpoint how best to punch holes, as the client would have multiple observers. This also solves the multiple walled garden problem.
All that is needed is a global bootstrap server, one that starts it going. Am I close, Lemon? ;) On 9/5/07, Lemon Obrien <[EMAIL PROTECTED]> wrote: > you want to do something really cool adam? > > i went bamboo for real. > > lemon > > > Adam Fisk <[EMAIL PROTECTED]> wrote: > > No ICE numbers yet, sorry. We're completing our ICE implementation now, and > we've put the skeleton in for both UDP and TCP. > I will say this, though. ICE is not so different from many RFC in the sense > that it's fairly straightforward once you really take the time to get > familiar with the algorithm. I see no reason it won't work in a good > percentage of cases, but it doesn't get sneaky too with "symmetric" NAT > traversal. It can handle some symmetric NATs, but it doesn't get into port > prediction. > > It will be awhile before we have anything useful because I don't expect to > have more than a few hundred users for a bit. > > -Adam > > > > On 9/1/07, David Barrett <[EMAIL PROTECTED]> wrote: > > > > > > > > There was recently (July '07) a big discussion on this topic on the BEHAVE > mailing list. I posted some of my results here: > > > > > http://www1.ietf.org/mail-archive/web/behave/current/msg02496.html > > > > Basically, I can get about direct 90% peer connectivity using UDP. Rumor > is Alex can get something like 99% (Alex – care to share any detailed > numbers?). The IETF is pushing a protocol named ICE, but nobody knows how > well it works (Adam – have you come up with any numbers yet?). > > > > Overall, it's much harder than it looks, even in the "simple" cases. The > basic algorithm is: > > > > 1) Figure out the IP address of each node's NAT > > 2) Share each node's pair of (LAN,NAT) IPs with the other node via some > central server > > 3) Try to connect over both the LAN and NAT addresses. > > 4) Apply a lot of voodoo tricks > > 5) Oftentimes it works > > > > Everybody seems to use a variation on this algorithm, though Alex recently > made some suspicious comments suggesting otherwise… > > > > -david > > > > > > > > ________________________________ > > > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > On Behalf Of Carlos Kamienski > > Sent: Saturday, September 01, 2007 9:43 AM > > To: [email protected] > > Subject: [p2p-hackers] Effective TCP and UDP NAT Traversal (no relaying) > > > > > > Dear all, > > > > I'd like to know what type of experiences you have about the rate of > succesfull direct communications (without relaying) of peers behind NAT, > both for TCP and UDP and for different scenarios, like home and corporate > users. > > There are some results reported like the one for STUNT > (http://nutss.net/pub/imc05-tcpnat.pdf), > which says that "TCP NAT Traversal can work 85%-90% of the time" ( > http://www1.ietf.org/mail-archive/web/midcom/current/msg03848.html). > > However, other reports don't seem to be so encouraging, like > http://www.paradial.com/storage/Elements/CallCompletion.pdf > . > > > > What are the best approaches for TCP and UDP? STUN, STUNT, ICE,....? > > > > The thing is that we need peers to establish direct communication (no > realying) for both TCP and UDPand I like to know the best approaches to do > that and the best existing solutions for that. > > > > Thanks > > > > Carlos > > > > -- > > "There's no sense in being precise when you don't even know what you're > talking about." > > John von Neumann > > _______________________________________________ > > p2p-hackers mailing list > > [email protected] > > > http://lists.zooko.com/mailman/listinfo/p2p-hackers > > > > > > _______________________________________________ > p2p-hackers mailing list > [email protected] > http://lists.zooko.com/mailman/listinfo/p2p-hackers > > > > You don't get no juice unless you squeeze > Lemon Obrien, the Third. > > http://www.tamago.us > _______________________________________________ > p2p-hackers mailing list > [email protected] > http://lists.zooko.com/mailman/listinfo/p2p-hackers > > -- Michael Slavitch Ottawa Ontario Canada _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
