P2P and DHT

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

P2P and DHT

Joshua Gargus-2
Over the last year, there has been a lot of good work on peer-to-peer  
and related tech, and I want to fill in the gaps in my picture of the  
current situation.

I installed Kolibri a while ago... very nice!  It looks very  
polished.  Unfortunately, my Dutch is non-existent, and it's not one  
of those languages that an Anglophone can guess word meanings in :-)

I also just installed the Tric-P2P chat.  However, I noticed that it  
relies on quite an old version of Aardworks-Gossip.  I'd like to play  
around with an app built on a later version, but I can't figure out  
how to install something.  I found a mail message where Cees says  
that he switched to MonticelloConfigurations instead of using  
dependencies, but I don't know where to find the appropriate  
configurations (or maybe I don't know how to use MCC properly?).  A  
hint about how to install a more recent version of DGV would be great.

The website says that use of UDP makes it easy to traverse NAT  
firewalls.  However, it's my understanding (eg: from http://
www.brynosaurus.com/pub/net/p2pnat/) that NAT traversal doesn't  
happen for free with UDP; you still need a middle-man to introduce a  
pair of nodes behind NATs.  I see that AWGPeerListEntry contains both  
'claimed' and 'observed' addresses/ports, which suggests that hole-
punching support is at least planned if not already working.  

Cees expressed some interest in porting BT to Squeak.  Has anyone  
else experimented with this?  I'm curious about how Cees feels that  
BT compares with Aardworks-Gossip (i.e. why BT is desirable when he's  
already implemented a P2P solution).  Clearly, it would be nice to  
directly load torrents into Squeak, but beyond standard file-sharing,  
what kind of unique Squeak services is BT better suited for than A-G?

I suppose that they're not directly comparable.  For instance, I read  
that A-G reliably supports datagrams up to ~6000bytes; in order to  
share large objects, an additional layer would be required to chop  
the object into chunks.  I also read that the default BT chunk size  
is 250kB.  Is BT inefficient (eg: high latency) for objects of this  
size or smaller?  What are some other tradeoffs?

Recently, Masashi Umezawa posted an OpenDHT client.  DHTs are nice  
for resource discovery, and OpenDHT has the benefit that it's already  
running on PlanetLab.  On the down side, 1000 bytes is the biggest  
object that can be stored in OpenDHT, so it's not suitable by itself  
for distributing large objects.  However, OpenDHT could be used to  
discover a "swarm" to download an object from.

My interest
I've recently finished a framework to allow large media objects (such  
as meshes or mo-cap libraries) to be shared between Croquet worlds.  
The design of this mechanism is such that the strict synchronization  
required by the simplified TeaTime model (see docs on  
opencroquet.org) can be relaxed, and therefore a more efficient  
transport strategy can be used.

Currently, I have implemented a very simple "global" cache with the  
intention of replacing it with a truly distributed solution.  I'm  
very interested in discussing how to best leverage the work that has  
already been done, and also whether it is worthwhile to pursue other  
options such as BitTorrent, SplitStream (for live A/V conferencing),