[Gzz-commits] manuscripts/pointers article.rst

[Tuomas J. Lukka]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Branch:         
Changes by:     Tuomas J. Lukka <address@hidden>        03/11/09 14:01:31

Modified files:
        pointers       : article.rst 

Log message:
        Move the other systems to their own section, to clean up intro structure

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

Patches:
Index: manuscripts/pointers/article.rst
diff -u manuscripts/pointers/article.rst:1.177 
manuscripts/pointers/article.rst:1.178
--- manuscripts/pointers/article.rst:1.177      Sun Nov  9 13:55:46 2003
+++ manuscripts/pointers/article.rst    Sun Nov  9 14:01:31 2003
@@ -111,13 +111,13 @@
 from any host with a copy. This would save bandwidth
 and increase availability; pages would stay online as long as
 any user keeps a copy of them on their local harddisk.
-Files could be
+Pages can be
 linked using  permanent URIs 
-[freenet-ieee-andalso-edonkey2kurl]_
 based on the files' cryptographic 
-hashes.
+hashes, as in 
+[freenet-ieee-andalso-edonkey2kurl]_.
 However, in such a scheme,
-web pages could not be updated:
+web pages cannot be updated:
 a new version of a web page would have a different hash,
 and thus a different URI. [#update]_
 
@@ -148,82 +148,6 @@
    of Freenet, where pages disappear when they have not been
    requested for a period of time).
 
-*CFS* [dabek01widearea]_
-is a file system based on Chord [stoica01chord]_, storing
-data in a distributed hashtable (DHT). CFS identifies
-different users' directory trees by the users' cryptographic keys;
-in its DHT, it stores mappings from these keys to the
-the current version of the user's tree. A node participating
-in the DHT will destructively update a mapping if the update message
-is signed with the appropriate key, and contains a timestamp
-newer than that of the current version.
-In CFS, version information is stored only
-as long as the publisher regularly requests it to be kept;
-information about past versions is not stored at all.
-
-In *OceanStore* [kubiatowicz00oceanstore]_, 
-an Internet-scale distributed data store based
-on the Tapestry [zhao01tapestry]_ overlay that 
-allows users to access their files 
-from different locations, every document has a 
-*primary replica*, a small set of servers that
-maintain the current version of the document.
-To make the connection between a document and a version,
-the primary replica signs *heartbeats*, tuples
-containing a document id, the hash of a version,
-a timestamp and a serial number.
-The most current heartbeat is obtained by sending a request
-to the primary replica [#consistencytime]_. 
-OceanStore is unique among the versioned P2P systems
-in that it implements non-destructive updates,
-allowing previous versions of documents to be accessed
-(by finding their old heartbeats through Tapestry).
-However, heartbeats are network-internal objects
-that do not exist at the file system interface
-presented to the user. Therefore, even in OceanStore,
-a user cannot simply download a version of a file 
-and an associated heartbeat and store them on their
-harddisk to keep the version "alive."
-
-.. [#consistencytime] Many applications
-   are believed to be able to cope with looser consistency
-   semantics; for example, the NFS client for OceanStore only requests
-   new heartbeats less than 30 seconds old.
-
-*Freenet*, a P2P network for anonymous publication [freenet-ieee]_,
-was originally planned to have an
-update mechanism where the network would remember
-the current version of a document, and update this information
-when receiving a message signed by the appropriate key,
-rather like in OceanStore. However, in practice,
-Freenet has a rather peculiar combination 
-of two workarounds [freenetfaq]_.
-In date-based updating, the URI for the current version
-is formed by concatenating a document's id with the current date;
-this requires publishers to insert versions of their document
-every day, otherwise they will not be accessible.
-In edition-based updating, a version's URI is the document's id
-concatenated with a version number. Version ``n`` then links to 
-version ``n+1`` using an ``<img>`` link. The image will not show until
-version ``n+1`` is actually inserted into the system; thus,
-when the image does show up, the user knows that they should click
-on it to get to a newer version of the document.
-In Freenet, files only stay online as long as they are
-requested regularly; keeping a copy on your harddisk
-does not keep a page alive.
-
-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* 
-proposal [content-addressable-web]_, in which clients download 
-a file's hash through HTTP (using an HTTP URI),
-then download the file through, e.g., a filesharing network.
-This provides some of the efficiency advantages of a P2P Web.
-However, there is still a single point of failure, and
-links still break when pages move to a different directory
-or Web server.
-In the Content-Addressable Web proposal, the situation
-regarding versioning is the same as on the current Web.
 
 In conclusion, in a filesharing system, a file remains accessible
 as long as there is a copy on any of the participating hosts;
@@ -312,6 +236,88 @@
 of our contributions, and Section 5 gives an overview of our
 implementation. Section 6 concludes.
 
+Related work
+============
+
+In this section, we shall briefly discuss the existing approaches
+to document updates in P2P systems.
+
+*CFS* [dabek01widearea]_
+is a file system based on Chord [stoica01chord]_, storing
+data in a distributed hashtable (DHT). CFS identifies
+different users' directory trees by the users' cryptographic keys;
+in its DHT, it stores mappings from these keys to the
+the current version of the user's tree. A node participating
+in the DHT will destructively update a mapping if the update message
+is signed with the appropriate key, and contains a timestamp
+newer than that of the current version.
+In CFS, version information is stored only
+as long as the publisher regularly requests it to be kept;
+information about past versions is not stored at all.
+
+In *OceanStore* [kubiatowicz00oceanstore]_, 
+an Internet-scale distributed data store based
+on the Tapestry [zhao01tapestry]_ overlay that 
+allows users to access their files 
+from different locations, every document has a 
+*primary replica*, a small set of servers that
+maintain the current version of the document.
+To make the connection between a document and a version,
+the primary replica signs *heartbeats*, tuples
+containing a document id, the hash of a version,
+a timestamp and a serial number.
+The most current heartbeat is obtained by sending a request
+to the primary replica [#consistencytime]_. 
+OceanStore is unique among the versioned P2P systems
+in that it implements non-destructive updates,
+allowing previous versions of documents to be accessed
+(by finding their old heartbeats through Tapestry).
+However, heartbeats are network-internal objects
+that do not exist at the file system interface
+presented to the user. Therefore, even in OceanStore,
+a user cannot simply download a version of a file 
+and an associated heartbeat and store them on their
+harddisk to keep the version "alive."
+
+.. [#consistencytime] Many applications
+   are believed to be able to cope with looser consistency
+   semantics; for example, the NFS client for OceanStore only requests
+   new heartbeats less than 30 seconds old.
+
+*Freenet*, a P2P network for anonymous publication [freenet-ieee]_,
+was originally planned to have an
+update mechanism where the network would remember
+the current version of a document, and update this information
+when receiving a message signed by the appropriate key,
+rather like in OceanStore. However, in practice,
+Freenet has a rather peculiar combination 
+of two workarounds [freenetfaq]_.
+In date-based updating, the URI for the current version
+is formed by concatenating a document's id with the current date;
+this requires publishers to insert versions of their document
+every day, otherwise they will not be accessible.
+In edition-based updating, a version's URI is the document's id
+concatenated with a version number. Version ``n`` then links to 
+version ``n+1`` using an ``<img>`` link. The image will not show until
+version ``n+1`` is actually inserted into the system; thus,
+when the image does show up, the user knows that they should click
+on it to get to a newer version of the document.
+In Freenet, files only stay online as long as they are
+requested regularly; keeping a copy on your harddisk
+does not keep a page alive.
+
+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* 
+proposal [content-addressable-web]_, in which clients download 
+a file's hash through HTTP (using an HTTP URI),
+then download the file through, e.g., a filesharing network.
+This provides some of the efficiency advantages of a P2P Web.
+However, there is still a single point of failure, and
+links still break when pages move to a different directory
+or Web server.
+In the Content-Addressable Web proposal, the situation
+regarding versioning is the same as on the current Web.
 
 
 Pointer records