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. Kolibri/Aardworks-Gossip/DGV ------------------------------------------ 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. Confirmation? BitTorrent -------------- 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? DHT ------- 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), etc. Thanks! Josh |
Free forum by Nabble | Edit this page |