[p2p-hackers] Work on NAT-friendly DHTs?
piccarre at elet.polimi.it
Fri Jan 27 12:25:19 UTC 2006
> I know that a lot of you guys don't like one taking reference to the
> Skype network, because it is closed source. But according to the
> reverse engeneering done on it's protocol, the Skype guys happened to
> solve this problem. OK, they introduced a supernode level and natted
> peers have to be connected to them but still, they even pass through
> quiet hardcore firewalls by using common ports like the http port 80.
> That's what I'd like to have in a peer to peer framework: the user
> just doesn't have to worry about beeing natted or not. I guess there's
> not a single strategy to solve this issue, but quiet a bunch of it,
> like UDP AND TCP hole punching, UPnP device discovery and so on...
I think Skype does exactly what I said, a flat P2P network between non
and a relay/udp hole approach between natted peers.
I think that Skype really worries about having phone calls not relayed,
but I think
that natted peers do not contribute to users lookup (actually I think
that users lookup
is handled by Skype servers, and the whole P2P stuff is just a relay/udp
hole opener framework)
> I suppose that in the future the share of unnatted peers will even
> decrease, since during the transition from IPv4 to IPv6 will increase
> the need to NAT devices. And which p2p networks are going to run then,
> when you call natted peers a problem and don't have a solution for it?
... what about Skype then?
About my "no solution"... I'll stick with Kademlia, I'll follow
the same Skype approach, I'll try and keep the traffic so low that even
super nodes won't have much to complain, and I'll try and see what comes
Even with this very dumb approach natted peers will be able to store
be contacted, to search for data. They will use the DHT, they won't
contribute to it.
I see the DHT network as a graph. some nodes are connected, some nodes are
not. Some nodes can be connected through UDP holes, some nodes can not.
But opening a UDP hole it's worth it *only if the traffic that is going
to flow through
the UDP hole is much greater than the traffic required to open it*.
In the case of Kademlia searches, IMO, this last assertion simply
> Am 27.01.2006 um 11:26 schrieb Luca Piccarreta:
>> Forgive me, but I still don't have the picture clear.
>> One peer might need to contact another one:
>> 1) Because it wants to ask something only that peer knows
>> (e.g., get a file from that peer, or make a phone call)
>> 2) Because it wants to ask something that other peers may know
>> (e.g., routing informations)
>> I also made a distinction between routed network and non-routed network:
>> 1) A peer exchanges messages with a small subset of nodes in the
>> overlay network. This small subset will manage delivery to unknown
>> 2) A peer exchanges search messages with possibly all peers in the
>> Search is done by interrogating a sequence of peers (determined by
>> peers answer) in order to reach the information desired (Kademlia)
>> I said that the scheme 2) can not take advantage of natted nodes for
>> informations. Well, of course it can... but it's not worth it. The
>> UDP hole
>> opening traffic (or the relay traffic) requested to the non natted
>> peers might
>> be more than the search traffic offloaded to the natted peers.
>> Is anyone really thinking of using UDP hole punching for key searches in
>> Kademlia-style networks?
>> In this case, can a rapid sketch be made?
>> For the moment I stick in my position, that is a separation between
>> a low bw
>> traffic for searches, managed by non natted peers, and a perhaps high bw
>> traffic for more advanced services (like file storage or even
>> <key,value> storage)
>> I had to work with a NAT with a 5 seconds UDP hole timeout... how can
>> think of opening more than a dozen of UDP holes if you have to keep
>> them alive
>> so frequently? And what about NATs changing mapped ports whenever we
>> "forget" to keep alive to UDP hole?
>> I think that if effort is to be dedicated to the NAT issue, it is to
>> be dedicated to
>> "many NAT layers" network schemes, in which a peer might have perhaps
>> two or
>> three addresses...
>> shudo at computer.org ha scritto:
>>>> From: Philip Matthews <philip_matthews at magma.ca>
>>>> Date: Thu, 26 Jan 2006 10:09:10 -0500
>>>> I am wondering if anyone is aware of work on NAT-friendly DHT
>>>> In other words, a DHT algorithm that works with the peers are located
>>>> behind NATs.
>>> There will be 2 points of view. From the first standpoint, NAT
>>> traversal can be performed independently of a DHT algorithm. From
>>> another standpoint, an advanced DHT algorithm will be able to deal
>>> with such heterogeneity, in which even a NATted node can take a role
>>> on an overlay.
>>> As pointed out, it is common to introduce super-peers which host
>>> NATted peers. And an advanced algorithm, like HeterPastry, may adapt
>>> to such heterogeneous environemnt.
>>> UDP messaging service of Overlay Weaver implements UDP hole punching.
>>> The technique works with a lot of routers, but not all ones. The
>>> technique is not very reliable.
>>> Overlay Weaver: An Overlay Construction Toolkit
>>> Kazuyuki Shudo shudo at computer.org http://www.shudo.net/
>>> p2p-hackers mailing list
>>> p2p-hackers at zgp.org
>>> Here is a web page listing P2P Conferences:
>> p2p-hackers mailing list
>> p2p-hackers at zgp.org
>> Here is a web page listing P2P Conferences:
More information about the P2p-hackers