[p2p-hackers] Questions about Overnet

[Paul Harrison]

On Mon, 22 Mar 2004, Enzo Michelangeli wrote:

> ----- Original Message -----
> From: "Paul Harrison" <Paul.Harrison at infotech.monash.edu.au>
> To: "Peer-to-peer development." <p2p-hackers at zgp.org>
> Sent: Sunday, March 21, 2004 1:07 PM
>
> [...]
> > Overnet is based on Kademlia, a Distributed Hash-Table. So, assuming
> > it's a robust implementation, searches will be exhaustive and content
> > will be visible as soon as it is published.
>
> Right, but how soon is "soon"? 5 seconds, 5 minutes, half hour... And what
> happens when the node(s) handling the section of DHT that stores that
> piece of information go(es) offline? I'd like to pick the brain of some
> Overnet, eMule or mldonkey developer (or at least "power user" :-) ), as
> the protocol itself is very poorly documented - also because it was
> originally closed source / closed specs, and the "Kad" part of eMule 0.4x
> and the mldonkey implementation where based on reverse-engineering.
>
> BTW, what is the answer to my "publishing latency and persistence"
> questions in Circle's case? And how would you compare Chord to Kademlia?
>

In Circle, publishing is fairly fast, i expect usually well under five
seconds. It persists until the publishing node logs off the network (the
publishing node gets pinged every so often to see if it's still up).

There's always the possibility of a slow node making publishing slow, or
an unreliable node not handing over published keys when it drops out. The
way to avoid this would be to publish to multiple points on the hashtable
simultaneously (Circle does this for things that need to be high
reliability).

afaik, there's not much theoretical difference in performance or
reliability between Chord and Kadmelia. I personally prefer Chord because
it's easier to visualize.


> > It's certainly possible to build presence services and directories on
> > top of a DHT. For example, Circle (thecircle.org.au) has an instant
> > messaging system built on top of a DHT (including the ability to
> > search by name or cryptographic id, and to publish a request to be
> > notified when a particular person comes online... basically
> > everything a normal IM system does).
>
> I had found about Circle thanks to the infoanarchy.org wiki, and I like
> its architecture (including the separation between daemon and GUI, which
> would represent a must for my intended use, and the addition of audio and
> video communications through GnomeMeeting); but I've got the impression
> that it's still in a quite experimental phase, with specs subject to
> change, and efficiency temporarily sacrificed to rapid prototyping (BTW,
> to speed up the crypto part while preserving multiplatform capability you
> might consider using the OpenSSL Python wrappers at
> http://www.freenet.org.nz/python/SSLCrypto/ ).
>

Yeah...

I'm no longer working on Circle, i'm not sure what the current developers
are doing. It was an experimental project when i was working on it, but
the design i was aiming at dotted all the i's and crossed all the t's, as
it were, for a directory service such as you describe.


> Another reason why I'd like to start with Overnet is its very large users
> base (which includes also eMule and mldonkey users). Besides, Overnet
> supports a "firewalled mode" (not yet implemented in eMule) for leaf nodes
> that can't directly participate in the Kamdelia exchange of UDP packets
> but, from what I understand, can still use "non-firewalled" nodes as a
> sort of proxy, using only outbound TCP connections. This might be ideal
> for mobile nodes based on GPRS or UMTS, even if not firewalled: per-packet
> billing and the blizzard of UDP packets exchanged by full-fledged Overnet
> nodes make a dangerous combination...
>

Ok. I put forward Circle as a proof that it's possible, not necessarily as
the thing you should actually use. :-)


Something that occurs to me: Overnet and Circle are designed for large
numbers of low reliability keys (several per file, many files per node).
It's possible to use a simpler and more reliable design if you don't have
large numbers of keys: use a DHT without the hashtable :-). Have each node
id represent a published key (each client would maintain several nodes). A
node can achieve as high a reliability level as it wants by informing as
many neighbours as it wants of its existence.


cheers,
Paul

pfh at logarithmic.net | http://www.logarithmic.net/pfh

                                      end apartheid