gzz-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gzz-commits] manuscripts/pointers article.rst


From: Benja Fallenstein
Subject: [Gzz-commits] manuscripts/pointers article.rst
Date: Sat, 01 Nov 2003 21:21:16 -0500

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Branch:         
Changes by:     Benja Fallenstein <address@hidden>      03/11/01 21:21:16

Modified files:
        pointers       : article.rst 

Log message:
        more intro

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/pointers/article.rst.diff?tr1=1.64&tr2=1.65&r1=text&r2=text

Patches:
Index: manuscripts/pointers/article.rst
diff -u manuscripts/pointers/article.rst:1.64 
manuscripts/pointers/article.rst:1.65
--- manuscripts/pointers/article.rst:1.64       Sat Nov  1 20:51:41 2003
+++ manuscripts/pointers/article.rst    Sat Nov  1 21:21:16 2003
@@ -103,7 +103,22 @@
 is signed with the appropriate key, and contains a timestamp
 newer than that of the current version.
 
-*Oceanstore* [XXXref] XXX
+In *Oceanstore* [XXXref], every document has a
+*primary replica*, a small set of servers that
+maintain the current version of the document.
+To make the connection between document and version,
+the primary replia signs *heartbeats*, tuples
+containing a document id, the hash of a version,
+a timestamp and a serial version number.
+To obtain the most current version, one sends a request
+to the primary replica. Many applications, however,
+are believed to be able to cope with loser consistency
+semantics; the NFS client for CFS only requests
+new heartbeats less than 30 seconds old.
+Oceanstore is unique among the versioned P2P systems
+in that it implements non-destructive updates,
+allowing previous versions of documents to be accessed
+(by using their old heartbeats).
 
 *Freenet* [XXXref] was originally planned to have an
 update mechanism where the network would remember
@@ -127,14 +142,30 @@
 
 Finally, a simplistic approach to P2P versioning
 is to have a centralized server keep track of the current version
-of a document, such as in the Content-Addressable Web 
+of a document, such as in the *Content-Addressable Web* 
 proposal [XXXref -> google it], in which clients download 
 a file's hash through HTTP (using an HTTP URI),
 then download the file through, e.g., a file-sharing network.
 This provides some of the efficiency advantages of a P2P Web.
-However, there is still a single point of failure;
+However, there is still a single point of failure, and
 links still break when pages move to a different directory
-or Web server; and when the original publisher loses interest
+or Web server.
+
+In a file-sharing system, a file remains accessible
+as long as there is a copy on any of the participating hosts.
+None of the above versioning systems have this property.
+In CFS, version information is stored in the DHT, and only
+as long as the publisher regularly requests it to be kept.
+In OceanStore, requesting a document's current version
+depends on querying its primary replica; when the primary
+replica ceases to function, the current version cannot be
+determined any longer (for some applications, this only happens
+30 seconds after the primary replica disappears).
+<<XXX what to say about freenet?>>
+In the Content-Addressable Web proposal, the situation
+is the same as on the current Web.
+
+Thus, in these systems, when the original publisher loses interest
 and stops publishing a page, it disappears, even if
 someone else would have kept a copy.
 
@@ -145,7 +176,7 @@
 
 .. Standing on the shoulders of giants: Example of Web links rotting away
 
-These are important concerns.
+This is an important concern.
 In 1997, NASA launched the Cassini-Huygens spacecraft
 on a mission to Saturn. Before the launch, the mission
 was widely criticized for its use of radioisotope




reply via email to

[Prev in Thread] Current Thread [Next in Thread]