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
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.
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),
|Free forum by Nabble||Edit this page|