Quite high.

According to the Chord website:

At this point no official release for Chord is available, but you are welcome to check out the latest version from the CVS repository. This version is experimental, under active development, and may frequently be broken.

• Self-certifying File System (http://fs.net)
• autoconf, automake, etc.
• Berkeley DB 3.X

No support for network locality- does not take network latencies into account when building neighbor links.

Includes a Chord simulator.

According to Tapestry: A Resilient Global-scale Overlay for Service Deployment:

Tapestry is highly resilient under dynamic conditions, providing a near optimal success rate for requests under high churn rates, and quickly recovering from massive membership events in under a minute.

According to the Tapestry website:

Tapestry offers fault-resilient mechanisms for both object location and point to point message delivery. For object location, Tapestry generates a small number of deterministic and independent GUIDs for each object. An object server publishes an object's availability on all of its GUIDs, and a client issues Tapestry locate requests for all of the object GUIDs in parallel. This greatly increases availability under fault conditions, while improving general performance and reducing performance variability. For point to point message delivery, Tapestry provides pre-calculated backup routes at each overlay hop. UDP soft-state beacons measure up-to-date link conditions. Tapestry uses such information and simple fault-avoidance protocols to route messages around failures, providing successful delivery with high probability if a path between the endpoints exists.

• PKI is used while creating node identifiers (to prevent Sybil attacks)
• MACs are used to maintain integrity of overlay traffic (to maintain integrity of overlay traffic)
• Monitoring system for maintaining neighbor links (reduce packet loss/improve message delivery in the overlay)

Active.

Tapestry 1.0 (April 2002)

According to the Tapestry website:

   Tapestry Version 1.0 contains the following functionality:

   * Basic Tapestry Java code running on the SEDA stage-driven event model
   * Tapestry node insertion
         o Using a static configuration built from configuration files
         o Using the dynamic iterative insertion of single nodes to existing 
           Tapestry networks
   * Support for multiple backup links per route entry
   * Object location
         o Object publication with optional tags
         o Object location with optional tags
         o TapestryFailure messages returned upon the failure of a  
           TapestryLocateMsg
   * Message routing
         o Routing messages to an exact GUID match
         o Routing messages to the node closest in ID to a given GUID
   * An initial self-optimizing componentthat monitors link conditions to 
     decide when to use backup routes   
 
 
According to the Tapestry website, Tapestry Version 2.0 contains the 
following new functionality::

   * Algorithms for adapting to changing network conditions
         o API messages allowing the application to tell the local node 
           to enter or leave a Tapestry overlay
         o Recovery algorithms to large scale failures in the network
         o A resilient parallel insertion algorithm that supported large flash 
          crowds adding themselves to the overlay
   * Patchwork: a soft-state network monitoring component that uses 
     soft-state beacons to monitor link quality to a node's neighbors. 
     As link qualities change, nodes can be replaced by backups in the 
     routing table in order to reduce packet loss in overlay routing.
   * A distributed testing framework: nodes can set themselves to be 
     configured as FullTestMember nodes, and await explicit control 
     instructions from a central FullTestDriver node. Instructions are 
     sent via FullTestMsg messages, and include join, leave, publish, 
     routeToObject and routeToNode operations. The results and resulting 
     latencies are returned to the FullTestDriver.
   * Interweave: a simple file sharing application
   * Shuttle: a decentralized instant messaging protocol 

• The Cryptix JCE library (included with the 2.0 release)
• UNIX make program
• The Java interface libraries for the BerkeleyDB database (included with the 2.0 release)

Support for network locality when building neighbor links.

Why Oceanstore uses Tapestry ? See http://www.oceanstore.org/info/whytapestry.html

No simulation or test results published (not even in the original publication). In theory, however, the "free-choice" feature gives peers freedom to adapt different conditions. However, the author of SharkyPy says:

Kademlia has (in my taste, that's why I decided to drop it) a bad hole which makes it's use in remote querying for packets pretty useless: When you have key->value mappings, which have an equal key, in even in semi-large networks it gets very unprobable that you get all mappings, the more hosts there are, the less probable it is, and the more mappings there are, the less probable it is too. I've tried to remedy this in a later implementation, at the cost of lookup speed, but have never managed to get all entries when the network had over 100 nodes. (the later implementation is based on my own server-framework and uses no threads, btw.) This made it unusable for me, as basically I basically had to change the lookup-algorithm to query all nodes (back to gnutella, then...), to get all answers. And that's what is important in the network I designed it for.

According to the release notes of 1.2, "Security support does not exist in

this release. Therefore, the software should only be run in trusted environments. Future releases will include security."

Active

Current release is 1.3 (July 23, 2003)

Support for network locality - Pastry actively replicates the objects and places them at random locations in the network. Result: When locating nearby object it might require the client to route to a distant replica of the object.

According to the Pastry website:

Future releases will address efficiency, security, interoperability and will provide additional application components like a generic distributed hash table implementation, replica management, caching, etc.

Uses 10x more cache as Chord for routing table.

Includes a GISP simulator.

According to Info-Anarchy Wiki:

Problems are: The DHT implementation is vulnerable to denial of service attacks.

According to the authors:

Note that Khashmir currently isn't very attack resistant.

Not active

The current version is "3 - Alpha" (2002-09-02)

DHT (Kademlia algorithm)

(MLDonkey is compatible with Overnet (non-open source implementation of Kademlia developed by a company), and Overnet claims that it does Kademlia and multisource downloading).

Very active

The current version is 2.5-3 (May 26th 2003)

Supported P2P networks include eDonkey, Overnet, Bittorrent, Gnutella (Bearshare, Limewire,etc), Gnutella2 (Shareaza), Fasttrack (Kazaa, Imesh, Grobster), Soulseek (beta), Direct-Connect (alpha), and Opennap (alpha).

Networks can be enabled/disabled.

Widely deployed in real life.

Overnet is not a free specification ,i.e., change control is in the Overnet company's hands.

According to the MLDonkey CVS source server (check this too), MLDonkey uses MD4 hashes for Overnet/EDonkey2K IDs:

peer: an overnet peer in the following format:
md4: the peer md4
ip:  the peer ip
int16: the peer port 
int8: the peer kind/uptime/last seen ?

Original Overnet uses MD5 (and 2^128 space) for nodeIDs and data items (http://www.overnet.com/documentation/how.html, http://bitzi.com/help/locallinks)

According to the author:

"It is being used in real code located at Sprachenzentrum der Universität des Saarlandes (http://www.szsb.uni-saarland.de/tandem), and has been running for several months now. Stable."

The current version is 0.2b3 (16th February 2003)

According to the post to the python-list by the author (posted 04 Feb 2003):

SharkyPy 0.2
------------

SharkyPy is a library for creating a distributed hash table using
Python. It uses the Kademlia-Protocol (http://kademlia.scs.cs.nyu.edu/)
over XMLRPC.

In constrast to alternatives like khashmir it does not need twisted or
any other library, and can even run without a persistence backend (as
long as the daemon is kept running). Persistence backends currently only
exist for MySQL.

SharkyPy has been coded to only run with Python 2.3 at the moment, as it
uses some new features such as enumerate, etc. But it should only be a
matter of time to make it backwards compatible.

- easily integrated into any program.
- uses a standard protocol which should also be able to run over a
  HTTP-proxy (this is still being worked on).
- loosely based on the Kademlia Java reference implementation, taking
  features like concurrent node queries into account.
- completely implemented without external dependencies.

URL: http://www.heim-d.de/~heikowu/SharkyPy
License: LGPL (the source doesn't state this yet)
Categories: Networking

Heiko Wundram (heikowu@ceosg.de or heikowu@heim-d.de)

PS: Still looking for co-developers... :)

and here's an another message (posted 17 Feb 2003):

The third public beta of SharkyPy has just now been released. This beta
adds new functionality to SharkyPy in the following areas:

1) Refactoring/Cleaning of most classes, and introduction of
   Borg-patterns to reduce overhead.
2) Integration of (public-key) signatures into DHT-values, by using
   Andrew M. Kuchlings PyCrypto package.
3) Protocol specification is transmitted with every RPC-call, so that
   future protocols won't break the program.
4) Several other buxfixes/changes not listed here.

This version should be considered even more beta than the previous
versions, as most of the functionality has only been tested over a
limited timespan (half a day). It works for me(tm). And it works solely
when using a version of Python 2.3.

The feature consolidation process will start, when several other
amendments have been made to the source.

A stable version 0.2 will be released in about two weeks. Anybody who is
interested in trying out SharkyPy so far is encouraged to do so, and
should send any bugreports to me.

According to the author of SharkyPy:

This implementation is heavily based on threads, which makes it pretty resource-intensive on the computer it is running on. I never intended it to serve more than 30-40 clients, so this didn't matter to me. When you use it as a P2P network backend, things will certainly look different.