[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/06/23 07:24:14

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

Log message:
        more twids

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/storm/storm/doc/pegboard/available_overlays--hemppah/peg.rst.diff?tr1=1.13&tr2=1.14&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.13 
storm/doc/pegboard/available_overlays--hemppah/peg.rst:1.14
--- storm/doc/pegboard/available_overlays--hemppah/peg.rst:1.13 Mon Jun 23 
06:43:36 2003
+++ storm/doc/pegboard/available_overlays--hemppah/peg.rst      Mon Jun 23 
07:24:14 2003
@@ -5,8 +5,8 @@
 
 :Authors:  Hermanni Hyytiälä
 :Date-Created: 2003-06-18
-:Last-Modified: $Date: 2003/06/23 10:43:36 $
-:Revision: $Revision: 1.13 $
+:Last-Modified: $Date: 2003/06/23 11:24:14 $
+:Revision: $Revision: 1.14 $
 :Status:   Incomplete
 
 .. :Stakeholders:
@@ -33,7 +33,7 @@
 ======
 
 ISSUE: How "heavy" the current implementation of Tapestry is (~57000 lines of
-       Java code) ? And, does Tapestry consume too much memory ?  
+       Java code) ? And therefore, does Tapestry consume too much memory ?  
 
 
 Terms
@@ -47,33 +47,33 @@
 `Towards a Common API for Structured P2P Overlays`_ by Frank Dabek et al.
 
 
-DHT
-The DHT abstraction provides the same functionality as a 
-traditional hashtable, by storing the mapping between a
-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.
-
-DOLR
-The DOLR abstraction provides a decentralized direc-tory
-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
-their locations. A client message addressed with
-a particular objectID will be delivered to a nearby end-point
-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.
-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
-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.
+    DHT
+    The DHT abstraction provides the same functionality as a 
+    traditional hashtable, by storing the mapping between a
+    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.
+
+    DOLR
+    The DOLR abstraction provides a decentralized direc-tory
+    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
+    their locations. A client message addressed with
+    a particular objectID will be delivered to a nearby end-point
+    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.
+    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
+    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.
 
 Redundancy
 ----------
@@ -113,7 +113,6 @@
 
 Chord_
 -----
-http://www.pdos.lcs.mit.edu/chord/
 
 Abstraction
 '''''''''''
@@ -161,7 +160,7 @@
 Redundancy
 ''''''''''
 According to `Tapestry: A Resilient Global-scale Overlay for Service
-Deployment`_
+Deployment`_:
 "..Tapestry is highly resilient under dynamic conditions,
 providing a near optimal success rate for requests
 under high churn rates, and quicly recovering from
@@ -182,8 +181,8 @@
 
 Tapestry 1.0 (April 2002)
 
-"Tapestry 2.0 is coming soon, with support for 
-massively parallel insertions, voluntary deletions, 
+According to the Tapestry website, "Tapestry 2.0 is coming soon, with support 
+for massively parallel insertions, voluntary deletions, 
 and a distributed test framework."
 
 Developer
@@ -192,7 +191,9 @@
 
 Language
 ''''''''
-Java (Sun JDK 1.3 or a compatible Java Development and Runtime environment)
+Java (Sun JDK 1.3 or a compatible Java Development and Runtime environment).
+The Java interface libraries for the BerkeleyDB database (included with this
+release).
 
 License
 '''''''
@@ -200,12 +201,15 @@
 
 Other notes
 '''''''''''
-Support for network locality
+Support for network locality.
+
+According to the Tapestry website, "Tapestry is the networking substrate of 
+OceanStore_, a storage system aiming to provide global-scale persistent and 
+secure storage." 
 
 
 Kademlia_ 
 --------
-http://kademlia.scs.cs.nyu.edu/
 
 Abstraction
 '''''''''''
@@ -259,8 +263,8 @@
 '''''''''''''''''''''''
 Current release is 1.2 (January 28, 2003)
 
-"Future releases will address efficiency, security, 
-interoperability and will provide additional 
+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."
@@ -370,8 +374,8 @@
 
 Fault tolerance against hostile nodes
 '''''''''''''''''''''''''''''''''''''
-According to the authors:
-"Note that Khashmir currently isn't very attack resistant."
+According to the authors, "Note that Khashmir currently isn't very 
+attack resistant."
 
 Activity of development
 '''''''''''''''''''''''
@@ -400,8 +404,8 @@
 '''''''''''
 DHT (Kademlia algorithm)
 
-(MLDonkey is compatible with Overnet_, and Overnet says that it does Kademlia 
-and multisource downloading)
+(MLDonkey is compatible with Overnet_, and Overnet claims that it does 
+Kademlia and multisource downloading)
 
 Redundancy
 ''''''''''
@@ -465,3 +469,4 @@
 .. _Khashmir: http://khashmir.sourceforge.net/ 
 .. _MLDonkey: http://www.nongnu.org/mldonkey/ 
 .. _Overnet: http://www.overnet.com
+.. _Oceanstore: http://www.oceanstore.org