[p2p-hackers] Work on NAT-friendly DHTs?

Dani Eichhorn p2p-hackers at squix.ch
Fri Jan 27 10:44:23 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 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?

Dani

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
> peers
> 2) A peer exchanges search messages with possibly all peers in the  
> network.
> Search is done by interrogating a sequence of peers (determined by  
> analyzing
> peers answer) in order to reach the information desired (Kademlia)
>
> I said that the scheme 2) can not take advantage of natted nodes  
> for finding
> 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 one
> 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...
>
> Luca.
>
> 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
>>> algorithms?
>>> 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
>>   http://overlayweaver.sf.net/
>>
>>
>>   Kazuyuki Shudo	shudo at computer.org	http://www.shudo.net/
>>
>> _______________________________________________
>> p2p-hackers mailing list
>> p2p-hackers at zgp.org
>> http://zgp.org/mailman/listinfo/p2p-hackers
>> _______________________________________________
>> Here is a web page listing P2P Conferences:
>> http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences
>>
>>
> _______________________________________________
> p2p-hackers mailing list
> p2p-hackers at zgp.org
> http://zgp.org/mailman/listinfo/p2p-hackers
> _______________________________________________
> Here is a web page listing P2P Conferences:
> http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences
>




More information about the P2p-hackers mailing list