[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/18 07:43:22

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

Log message:
        abstractions

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/storm/storm/doc/pegboard/available_overlays--hemppah/peg.rst.diff?tr1=1.1&tr2=1.2&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.1 
storm/doc/pegboard/available_overlays--hemppah/peg.rst:1.2
--- storm/doc/pegboard/available_overlays--hemppah/peg.rst:1.1  Wed Jun 18 
07:18:32 2003
+++ storm/doc/pegboard/available_overlays--hemppah/peg.rst      Wed Jun 18 
07:43:22 2003
@@ -5,8 +5,8 @@
 
 :Authors:  Hermanni Hyytiälä
 :Date-Created: 2003-06-18
-:Last-Modified: $Date: 2003/06/18 11:18:32 $
-:Revision: $Revision: 1.1 $
+:Last-Modified: $Date: 2003/06/18 11:43:22 $
+:Revision: $Revision: 1.2 $
 :Status:   Incomplete
 
 .. :Stakeholders:
@@ -30,6 +30,44 @@
 .. Yet, no issues.
 
 
+Abstractions
+============
+
+The following text for the abstraction definitions is taken from 
+'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 [4] 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.
+
+
 Overlays
 ========
 
@@ -179,6 +217,12 @@
 =======
 
 - (possible) reject gisp, choose new overlay
-- (possible) develop a abstraction (p2p-plugin) which allows Storm
-  to change lookup layer easily
+- (possible) develop a abstraction (i.e., p2p-plugin system) which allows 
+  Storm to change lookup layer easily
 
+.. _GISP: http://gisp.jxta.org
+.. _Kademlia: http://kademlia.scs.cs.nyu.edu
+.. _Chord: http://www.pdos.lcs.mit.edu/chord/
+.. _Tapestry: http://www.cs.berkeley.edu/~ravenben/tapestry/
+.. _Pastry: http://www.research.microsoft.com/~antr/pastry/
+.. _'Towards a Common API for Structured P2P Overlays'_: 
http://www.cs.berkeley.edu/~ravenben/publications/pdf/apis.pdf