> -----Original Message----- > From: p2p-hackers-boun...@lists.zooko.com > [mailto:p2p-hackers-boun...@lists.zooko.com] On Behalf Of Alen Peacock > Sent: January 21, 2011 9:52 AM > To: theory and practice of decentralized computer networks > Subject: Re: [p2p-hackers] NAT traversal state of the art > > On Fri, Jan 21, 2011 at 12:51 AM, Alex Pankratov > <a...@swapped.cc> wrote: > > > >> What if you need super-high success rates for direct connectivity > >> (+95%)? > > > > In my experience one cannot achieve these rates with client-driven > > traversal, there's gotta be a coordinating third party. > > Not a problem, right? Even in a purely edge-based deployment, some > fraction of the nodes are going to be able to play the role of > coordinator.
Sure, but that's not the point. Clients need to act like *clients* respective to the coordinator and not use it as a simple relay and temporary data storage for their exchanges. I.e. the coordinator needs to be the one driving the whole process. > > I meant that providing > > reliability over UDP tunnels (or lossy behaviour over TCP ones) > > is a subject that is not directly related to the "NAT traversal > > state of the art". NAT traversal domain ends when you have two > > peers talking to each other in some form or fashion. Adapting > > this form to the needs of the application is a separate issue. > > Understood, these are separate issues. I brought them up together > because as far as I can tell from the literature and reported results, > TCP traversal success rates are much lower than for UDP, so if you > have a real requirement for reducing relaying as much as possible, you > are going to need to use UDP and deal with the consequences. I thought > it would be useful to discuss the two topics together. I don't know about others, but I used TCP traversal is a fallback option when UDP traversal failed. The success rate was not really high indeed, but that could've been because the nodes it was tried for was in an unfavourable configuration to begin with. Seeing simultaneous TCP open punch through two stateful firewalls was a very gratifying experience. That alone is why TCP traversal is worth doing :) One scenario where one ends up with a TCP tunnel is in the system where each peer maintains a control TCP connection towards shared backend and then uses this connection as a relay option for p2p. So TCP tunneling *is* quite relevant. Alex _______________________________________________ p2p-hackers mailing list p2p-hackers@lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers
