What we do in Brunet, which is the overlay used in SocialVPN, is completely distributed, and we did it that way from the beginning.
The approach is two fold: 1) Relay connection request messages through the overlay, which we assume is working correctly initially (bootstrapping is another issue). These connection requests include a list of protocol:IP:port tuples in order of most preferred to least preferred. The receiving node replies with the same kind of list. 2) At each connection (nodes have successfully found good remote endpoints for each other), each peer echoes the apparent IP endpoints to the other node. In this way, each node learns what other peers think its IP:port have been translated to. Each node accumulates a history of "peer-views" of its IP:port. From this, we have code that estimates the most likely values to use for the IP:port to get connected. Those are sent over the connection request messages through the overlay in step 1. This approach works very well for us as long as there are enough public nodes or nodes behind full-cone NATs, so that a new node can find some peer to contact initially. One downside of this approach is that the "NAT traversal" part of our code is fairly diffuse. It emerges from several properties that are spread about the code. For instance: the first message peers exchange includes the remote endpoints, the relaying a list of endpoints in the connection request messages, and the logic that looks at a history of remote end points to determine the type of nat and the likely future endpoints to use in the case of port prediction. On Sun, Jan 23, 2011 at 13:21, Julian Cain <jul...@junglecat.org> wrote: > > > Sent from my iPhone > > On Jan 23, 2011, at 1:13 PM, David Barrett <dbarr...@quinthar.com> wrote: > >> I'd say get it working with a centralized server before you even >> consider making it decentralized. I think you'll find even the "easy" >> centralized case is unimaginably difficult, as it relies on very precise >> timing and coordination. Use a central server to get it down, and then >> swap it out for a host of supernodes later. >> >> -david >> >> On 01/23/2011 09:51 AM, Valerio Schiavoni wrote: >>> Hello, >>> related to the recently discussed topic of nat traversal, there is the >>> topic of nat discovery: >>> being able to detect behind which kind of NAT a peer is sitting. >>> >>> Although some solutions exist, they all rely on the existence of >>> servers used for this sole purpose. >>> >>> What are the best practices in this regard ? >>> How are you currently detecting your NAT type ? >>> Can it be done in a purely decentralized fashion ? > > Of course, we do it in RELOAD(p2psip-base) and it works very well. > >>> >>> Thanks for any pointers, >>> Valeiro >>> _______________________________________________ >>> 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 > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@lists.zooko.com > http://lists.zooko.com/mailman/listinfo/p2p-hackers > -- P. Oscar Boykin http://boykin.acis.ufl.edu Assistant Professor, Department of Electrical and Computer Engineering University of Florida _______________________________________________ p2p-hackers mailing list p2p-hackers@lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers
