[Gzz-commits] storm/doc/pegboard/available_overlays--hemppah ...

[Hermanni Hyytiälä]

CVSROOT:        /cvsroot/storm
Module name:    storm
Branch:         
Changes by:     Hermanni Hyytiälä <address@hidden>      03/08/01 05:00:51

Modified files:
        doc/pegboard/available_overlays--hemppah: peg.rst 

Log message:
        benja's comments

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/storm/storm/doc/pegboard/available_overlays--hemppah/peg.rst.diff?tr1=1.39&tr2=1.40&r1=text&r2=text

Patches:
Index: storm/doc/pegboard/available_overlays--hemppah/peg.rst
diff -u storm/doc/pegboard/available_overlays--hemppah/peg.rst:1.39 
storm/doc/pegboard/available_overlays--hemppah/peg.rst:1.40
--- storm/doc/pegboard/available_overlays--hemppah/peg.rst:1.39 Thu Jul 31 
08:56:11 2003
+++ storm/doc/pegboard/available_overlays--hemppah/peg.rst      Fri Aug  1 
05:00:50 2003
@@ -4,21 +4,19 @@
 
 :Authors:  Hermanni Hyytiälä
 :Date-Created: 2003-06-18
-:Last-Modified: $Date: 2003/07/31 12:56:11 $
-:Revision: $Revision: 1.39 $
+:Last-Modified: $Date: 2003/08/01 09:00:50 $
+:Revision: $Revision: 1.40 $
 :Status:   Current
 :Scope:    Major
-:Type:     Architecture
+:Type:     Implementation
 :Stakeholders: tjl, benja
-.. Affect-PEGs:
 
-The purpose of this PEG document is to give a short overview of existing 
structured
-P2P overlays which have an open source implementation. 
 
-The reason for creating this PEG document is that the current implementation 
-of GISP [5]_ seems to have (too) many obvious security exploits. Therefore we 
need 
-to examine other available structured overlays which have an open source 
-implementation in hope for finding a more mature P2P platform. 
+The current implementation of GISP seems to have (too) many obvious security 
+exploits. Therefore we need to examine other available structured overlays 
which 
+have an open source implementation in the hope to find a more mature P2P 
platform. 
+After reviewing available open source overlays we propose that we shall use 
Tapestry 
+as a P2P platform with Storm/Fenfire. 
 
 The list of implemented overlays is as of July 2003.
 
@@ -44,35 +42,36 @@
         key and a value. This interface implements a simple store
         and retrieve functionality, where the value is always stored
         at the live overlay node(s) to which the key is mapped by
-        the KBR layer. Values can be objects of any type. For ex-ample, the 
DHT 
-        implemented as part of the DHash inter-face in CFS stores 
-        and retrieves single disk blocks by their content-hashed keys.
+        the KBR layer. Values can be objects of any type. For example, the DHT 
+        implemented as part of the DHash interface in CFS stores 
+        and retrieves single disk blocks by their content hashed keys.
 
 .. _DOLR:
 
     DOLR
-        The DOLR abstraction provides a decentralized direc-tory
+        The DOLR abstraction provides a decentralized directory
         service. Each object replica (or endpoint) has an
         objectID and may be placed anywhere within the system.
-        Applications announce the presence of endpoints by pub-lishing
+        Applications announce the presence of endpoints by publishing
         their locations. A client message addressed with
-        a particular objectID will be delivered to a nearby end-point
+        a particular objectID will be delivered to a nearby endpoint
         with this name. Note that the underlying distributed
-        directory can be implemented by annotating trees associ-ated
-        with each objectID; other implementations are pos-sible.
+        directory can be implemented by annotating trees associated
+        with each objectID; other implementations are possible.
         One might ask why DOLR is not implemented on
         top of a DHT, with data pointers stored as values; this is
-        not possible because a DOLR routes messages to the near-est
+        not possible because a DOLR routes messages to the nearest
         available endpoint providing a locality property not
         supported by DHTs. An integral part of this process is the
         maintenance of the distributed directory during changes
         to the underlying nodes or links.
+       
+       
+Note that DHT and DOLR can be seen as "equal" abstractions, i.e., either 
+one doesn't rely on other: DHT can be implemented without relying DOLR and 
vice 
+versa.
 
-Redundancy
-    What techniques are used for redundancy     
-
-Fault tolerance against hostile nodes
-    What techniques are used against hostile nodes    
+    
 
 Activity of development
     How actively a software is being developed.
@@ -89,17 +88,29 @@
 
 Other notes
     Other miscellaneous notes.
+    
+    
+Additionally, we will mention the community that is developing a software 
under a
+"Developer" section. THe two choices are:
+
+1) "software engineering community", i.e., a regular free software project.
+
+2) "research community, i.e., a research group that consist one or more 
researcher 
+   who developes a software
 
 Implemented overlays
 ====================
 
 In this section we list the structured P2P overlays which have an open source
-implementation. Please notice that features described for each implementation 
-are deliberately kept as short as possible. For more depth information about 
the 
+implementation. Please note that the description of each implementation's 
features 
+is deliberately kept as short as possible. For more in-depth information about 
the 
 overlays we suggest reading the original publications.
 
-Chord [1]_
-----------
+Chord
+-----
+
+Homepage
+http://www.pdos.lcs.mit.edu/chord/
 
 Abstraction
     DHT_/DOLR_
@@ -108,12 +119,18 @@
     Replication, backup links.
 
 Fault tolerance against hostile nodes
-    (undefined)
+    Not known.
+    
+License
+    BSD-like
+    
+Language
+    C++ (GCC 2.95, not 2.96, although 3.x should work)
 
 Activity of development
     Quite high.
 
-    According to the Chord [1]_ website:
+    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 
@@ -123,26 +140,25 @@
 Developer
     MIT (research community)
 
-Language
-    C++ (GCC 2.95, not 2.96, although 3.x should work)
-
 Additional requirements
     * Self-certifying File System (http://fs.net)
     * autoconf, automake, etc.
     * Berkeley DB 3.X 
 
-License
-    BSD-like
-
 Other notes
-    No support for network locality- do not take network latencies into account
+    No support for network locality- does not take network latencies into 
account
     when building neighbor links.
 
-    Includes a Chord [1]_ simulator.
+    Includes a Chord simulator.
+    
+    
     
 
-Tapestry [2]_
---------------
+Tapestry
+--------
+
+Homepage
+http://www.cs.berkeley.edu/~ravenben/tapestry/
 
 Abstraction
     DOLR_
@@ -153,10 +169,10 @@
 
         Tapestry is highly resilient under dynamic conditions,
         providing a near optimal success rate for requests
-        under high churn rates, and quicly recovering from
+        under high churn rates, and quickly recovering from
         massive membership events in under a minute.
     
-    According to the Tapestry [2]_ website:
+    According to the Tapestry website:
 
         Tapestry offers fault-resilient mechanisms for both object 
         location and point to point message delivery.  For object location, 
@@ -174,16 +190,25 @@
 
     
 Fault tolerance against hostile nodes
-    * PKI is used while creating node identifiers
-    * MACs are used to maintain integrity of overlay traffic
-    * Monitoring system for maintaining neighbor links
+    * 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)
+   
+License
+    BSD-like
 
+Language
+    Java (Sun JDK 1.3 or a compatible Java Development and Runtime 
environment).
+    The Java interface libraries for the BerkeleyDB database
+    
 Activity of development
     Active.
 
     Tapestry  1.0 (April 2002)
 
-    According to the Tapestry [2]_ website::
+    According to the Tapestry website::
 
         Tapestry Version 1.0 contains the following functionality:
 
@@ -205,7 +230,7 @@
           decide when to use backup routes   
       
       
-     According to the Tapestry [2]_ website, Tapestry Version 2.0 contains the 
+     According to the Tapestry website, Tapestry Version 2.0 contains the 
      following new functionality::
 
         * Algorithms for adapting to changing network conditions
@@ -230,33 +255,29 @@
 Developer
     University of Berkeley (research community)
 
-Language
-    Java (Sun JDK 1.3 or a compatible Java Development and Runtime 
environment).
-    The Java interface libraries for the BerkeleyDB database 
-
 Additional requirements
     * 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) 
-    
-License
-    BSD-like
 
 Other notes
     Support for network locality when building neighbor links.
 
-    Why Oceanstore_ uses Tapestry [2]_? 
+    Why Oceanstore_ uses Tapestry ? 
     See http://www.oceanstore.org/info/whytapestry.html 
 
-Kademlia [3]_
--------------
+Kademlia
+--------
+
+Homepage
+http://kademlia.scs.cs.nyu.edu
 
 Abstraction
     DHT_
-
+    
 Redundancy
-    No simulation or test results published (not even in the original 
publication)
+    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:
@@ -277,7 +298,13 @@
 
 
 Fault tolerance against hostile nodes
-    Nothing said, expect the "free-choice" feature. 
+    Nothing said, expect the "free-choice" feature.
+    
+License
+    GPL (Java), "Free for non-commercial use" (C++)
+    
+Language
+    Java (Sun JDK 1.3 or a compatible Java Development and Runtime environment 
(?))
 
 Activity of development
     Java development discontinued, C++ version
@@ -286,21 +313,18 @@
 Developer
     New York University (research community).
 
-Language
-    Java (Sun JDK 1.3 or a compatible Java Development and Runtime environment 
(?))
-
-License
-    GPL (Java), "Free for non-commercial use" (C++)
-
 Other notes
     The implementation of the Java version is discontinued. 
 
-Pastry [4]_
------------
+Pastry
+------
+
+Homepage
+http://research.microsoft.com/~antr/Pastry/
 
 Abstraction
     DHT_
-
+    
 Redundancy
    Backup links.
 
@@ -309,6 +333,12 @@
     this release. Therefore, the  software should only be run in trusted 
     environments. Future releases will include security."
 
+License
+    BSD-like license (Java), MSR-EULA (C#)
+    
+Language
+    Java (requires a Java runtime version 1.4), C# (not known)
+
 Activity of development
     Active
     
@@ -317,19 +347,13 @@
 Developer
     Microsoft Research and Rice University (research community)
 
-Language
-    Java (requires a Java runtime version 1.4), C# (not known)
-
-License
-    BSD-like license (Java), MSR-EULA (C#)
-
 Other notes
-    Support for network locality - Pastry [4]_ actively replicates the objects 
and 
+    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 [4]_ website:
+    According to the Pastry website:
 
         Future releases will address efficiency, 
         security, interoperability and will provide additional 
@@ -337,38 +361,44 @@
         hash table implementation, replica management, 
         caching, etc.
 
-GISP [5]_
----------
+GISP
+----
+
+Homepage
+http://gisp.jxta.org/
 
 Abstraction
     DHT_/DOLR_
 
 Redundancy
-    Chord [1]_-like (since GISP uses similar routing tables as Chord)
+    Chord-like (since GISP uses similar routing tables as Chord)
 
 Fault tolerance against hostile nodes
     Based on our own initial experiments: the fault tolerance
     is relatively weak - no specific techiques used.
 
+License
+    Sun Project JXTA License Version 1.1
+    
+Language
+    Java (requires a Java runtime version 1.4)
+
 Activity of development
     Quite active.
 
 Developer
     Daishi Kato (software engineering community)
 
-Language
-    Java (requires a Java runtime version 1.4)
-
-License
-    Sun Project JXTA License Version 1.1
-
 Other notes
-    Uses 10x more cache as Chord [1]_ for routing table.
+    Uses 10x more cache as Chord for routing table.
+
+    Includes a GISP simulator.
 
-    Includes a GISP [5]_ simulator.
+Circle
+------
 
-Circle [6]_
------------
+Homepage
+http://thecircle.org.au/
 
 Abstraction
     DHT_
@@ -380,32 +410,35 @@
     According to Info-Anarchy Wiki:
 
         Problems are: The DHT implementation is 
-        vulnerable to denial of service attacks.    
+        vulnerable to denial of service attacks.
+
+License
+    GPL
+
+Language
+    Python (version 2.0 or higher, 2.2 preferred, GTK+-2 and PyGTK)
 
 Activity of development
     Active, the current version is 0.35 (30 May 2003)
 
 Developer
     Paul Harrison (software engineering community)
-
-Language
-    Python (version 2.0 or higher, 2.2 preferred, GTK+-2 and PyGTK) 
-
-License
-    GPL
-
+ 
 Other notes
     Uses MD5 hashes for generating IDs.
     
 
-Khashmir [7]_
--------------
+Khashmir
+--------
+
+Homepage
+http://khashmir.sourceforge.net/
 
 Abstraction
-    DHT_ (Kademlia [3]_ algorithm)
+    DHT_ (Kademlia algorithm)
 
 Redundancy
-    Not known
+    Not known.
 
 Fault tolerance against hostile nodes
     According to the authors:
@@ -413,6 +446,12 @@
         Note that Khashmir currently isn't very 
         attack resistant.
 
+License
+    MIT License
+    
+Language
+    Python
+    
 Activity of development
     Not active
     
@@ -421,32 +460,36 @@
 Developer
     Four developers (software engineering community)
 
-Language
-    Python
-
-License
-    MIT License
-
 Other notes
     (none)
 
-MLDonkey [8]_
--------------
+MLDonkey
+--------
+
+Homepage
+http://www.nongnu.org/mldonkey/
 
 Abstraction
-    DHT_ (Kademlia [3]_ algorithm)
+    DHT_ (Kademlia algorithm)
 
-    (MLDonkey [8]_ is compatible with Overnet_, and Overnet claims that it 
does 
-    Kademlia [3]_ and multisource downloading)
+    (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).
 
 Redundancy
     Not known (we can imagine that redundancy is relatively high since MLDonkey
     is widely deplyed)
 
 Fault tolerance against hostile nodes
-    Not known (we can imagine that fault tolerance is relatively high since 
MLDonkey
-    is widely deplyed)
-
+    Not "officially" known (we can imagine that fault tolerance is relatively 
+    high since MLDonkey is widely deplyed).
+ 
+License
+    GPL
+    
+Language
+    Objective-Caml (a language that compiler compiling)
+    
 Activity of development
     Very active
 
@@ -456,12 +499,6 @@
     12 developers (according to Savannah's project page, software engineering 
     community)
 
-Language
-    Objective-Caml (a compiler, not a interpreter)
-
-License
-    GPL
-
 Other notes
     Supported P2P networks include eDonkey, Overnet, Bittorrent,
     Gnutella (Bearshare, Limewire,etc),  Gnutella2  (Shareaza),  
@@ -475,7 +512,7 @@
     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 
[8]_ 
+    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:
@@ -488,11 +525,14 @@
     (http://www.overnet.com/documentation/how.html, 
     http://bitzi.com/help/locallinks)
 
-SharkyPy [9]_
--------------
+SharkyPy
+--------
+
+Homepage
+http://www.heim-d.uni-sb.de/~heikowu/SharkyPy/
 
 Abstraction
-    DHT_ (Kademlia [3]_ algorithm)
+    DHT_ (Kademlia algorithm)
 
 Redundancy
     According to the author:
@@ -504,6 +544,12 @@
 Fault tolerance against hostile nodes
     No specific techniques used: "it should work as is"
 
+Language
+    Python
+
+License
+    LGPL
+    
 Activity of development
     The current version is 0.2b3 (16th February 2003)
 
@@ -568,12 +614,6 @@
 Developer
     Sprachenzentrum der Universität des Saarlandes / Heiko Wundram (research 
community)
 
-Language
-    Python
-
-License
-    LGPL
-
 Other notes
     According to the author of SharkyPy:
     
@@ -597,27 +637,19 @@
 - The activity of development
 - The implementation language
 
-As a result, we recommend using Tapestry's open source implementation with 
Storm.
-For detailed changes and information about using Tapestry with Storm, please
-see the `storm_with_tapestry--hemppah` PEG document.
+As a result, we recommend using Tapestry's open source implementation for use 
in
+Storm. For a detailed list of changes necessary to use Tapestry in Storm, see 
+the ``storm_with_tapestry--hemppah`` (a pending PEG) PEG document.
  
 
-.. [1] http://www.pdos.lcs.mit.edu/chord/
-.. [2] http://www.cs.berkeley.edu/~ravenben/tapestry/
-.. [3] http://kademlia.scs.cs.nyu.edu
-.. [4] http://research.microsoft.com/~antr/Pastry/
-.. [5] http://gisp.jxta.org/
-.. [6] http://thecircle.org.au/
-.. [7] http://khashmir.sourceforge.net/ 
-.. [8] http://www.nongnu.org/mldonkey/ 
-.. [9] http://www.heim-d.uni-sb.de/~heikowu/SharkyPy/
 
-.. _`Towards a Common API for Structured P2P Overlays`: 
http://www.cs.berkeley.edu/~ravenben/publications/pdf/apis.pdf
+.. _Towards a Common API for Structured P2P Overlays: 
http://www.cs.berkeley.edu/~ravenben/publications/pdf/apis.pdf
 .. _`Tapestry: A Resilient Global-scale Overlay for Service Deployment`: 
http://www.cs.berkeley.edu/~ravenben/publications/pdf/tapestry_jsac.pdf
 .. _Overnet: http://www.overnet.com
 .. _Oceanstore: http://www.oceanstore.org
-.. _`MLDonkey CVS source server`: 
http://savannah.nongnu.org/cgi-bin/viewcvs/mldonkey/mldonkey/docs/overnet.txt?rev=1.1&content-type=text/vnd.viewcvs-markup
+.. _MLDonkey CVS source server: 
http://savannah.nongnu.org/cgi-bin/viewcvs/mldonkey/mldonkey/docs/overnet.txt?rev=1.1&content-type=text/vnd.viewcvs-markup
 .. _this: 
http://savannah.nongnu.org/cgi-bin/viewcvs/mldonkey/mldonkey/src/networks/donkey/donkeyOvernet.ml?rev=1.4&content-type=text/vnd.viewcvs-markup
 .. _post: 
http://mail.python.org/pipermail/python-list/2003-February/143876.html
-.. _`python-list`: http://mail.python.org/mailman/listinfo/python-list
+.. _python-list: http://mail.python.org/mailman/listinfo/python-list
 .. _message: 
http://mail.python.org/pipermail/python-list/2003-February/148394.html
+.. _Sybil attacks: http://www.cs.rice.edu/Conferences/IPTPS02/101.pdf