I'm not sure what that means, but best of luck.
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 > >
_______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
