/[gzz]/manuscripts/pointers/article.rst
ViewVC logotype

Diff of /manuscripts/pointers/article.rst

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.177 by tjl, Sun Nov 9 18:55:46 2003 UTC revision 1.178 by tjl, Sun Nov 9 19:01:31 2003 UTC
# Line 111  no central point of failure for a web pa Line 111  no central point of failure for a web pa
111  from any host with a copy. This would save bandwidth  from any host with a copy. This would save bandwidth
112  and increase availability; pages would stay online as long as  and increase availability; pages would stay online as long as
113  any user keeps a copy of them on their local harddisk.  any user keeps a copy of them on their local harddisk.
114  Files could be  Pages can be
115  linked using  permanent URIs  linked using  permanent URIs
 [freenet-ieee-andalso-edonkey2kurl]_  
116  based on the files' cryptographic  based on the files' cryptographic
117  hashes.  hashes, as in
118    [freenet-ieee-andalso-edonkey2kurl]_.
119  However, in such a scheme,  However, in such a scheme,
120  web pages could not be updated:  web pages cannot be updated:
121  a new version of a web page would have a different hash,  a new version of a web page would have a different hash,
122  and thus a different URI. [#update]_  and thus a different URI. [#update]_
123    
# Line 148  provides all the benefits of a fileshari Line 148  provides all the benefits of a fileshari
148     of Freenet, where pages disappear when they have not been     of Freenet, where pages disappear when they have not been
149     requested for a period of time).     requested for a period of time).
150    
 *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.  
151    
152  In conclusion, in a filesharing system, a file remains accessible  In conclusion, in a filesharing system, a file remains accessible
153  as long as there is a copy on any of the participating hosts;  as long as there is a copy on any of the participating hosts;
# Line 312  In Section 4 we discuss some application Line 236  In Section 4 we discuss some application
236  of our contributions, and Section 5 gives an overview of our  of our contributions, and Section 5 gives an overview of our
237  implementation. Section 6 concludes.  implementation. Section 6 concludes.
238    
239    Related work
240    ============
241    
242    In this section, we shall briefly discuss the existing approaches
243    to document updates in P2P systems.
244    
245    *CFS* [dabek01widearea]_
246    is a file system based on Chord [stoica01chord]_, storing
247    data in a distributed hashtable (DHT). CFS identifies
248    different users' directory trees by the users' cryptographic keys;
249    in its DHT, it stores mappings from these keys to the
250    the current version of the user's tree. A node participating
251    in the DHT will destructively update a mapping if the update message
252    is signed with the appropriate key, and contains a timestamp
253    newer than that of the current version.
254    In CFS, version information is stored only
255    as long as the publisher regularly requests it to be kept;
256    information about past versions is not stored at all.
257    
258    In *OceanStore* [kubiatowicz00oceanstore]_,
259    an Internet-scale distributed data store based
260    on the Tapestry [zhao01tapestry]_ overlay that
261    allows users to access their files
262    from different locations, every document has a
263    *primary replica*, a small set of servers that
264    maintain the current version of the document.
265    To make the connection between a document and a version,
266    the primary replica signs *heartbeats*, tuples
267    containing a document id, the hash of a version,
268    a timestamp and a serial number.
269    The most current heartbeat is obtained by sending a request
270    to the primary replica [#consistencytime]_.
271    OceanStore is unique among the versioned P2P systems
272    in that it implements non-destructive updates,
273    allowing previous versions of documents to be accessed
274    (by finding their old heartbeats through Tapestry).
275    However, heartbeats are network-internal objects
276    that do not exist at the file system interface
277    presented to the user. Therefore, even in OceanStore,
278    a user cannot simply download a version of a file
279    and an associated heartbeat and store them on their
280    harddisk to keep the version "alive."
281    
282    .. [#consistencytime] Many applications
283       are believed to be able to cope with looser consistency
284       semantics; for example, the NFS client for OceanStore only requests
285       new heartbeats less than 30 seconds old.
286    
287    *Freenet*, a P2P network for anonymous publication [freenet-ieee]_,
288    was originally planned to have an
289    update mechanism where the network would remember
290    the current version of a document, and update this information
291    when receiving a message signed by the appropriate key,
292    rather like in OceanStore. However, in practice,
293    Freenet has a rather peculiar combination
294    of two workarounds [freenetfaq]_.
295    In date-based updating, the URI for the current version
296    is formed by concatenating a document's id with the current date;
297    this requires publishers to insert versions of their document
298    every day, otherwise they will not be accessible.
299    In edition-based updating, a version's URI is the document's id
300    concatenated with a version number. Version ``n`` then links to
301    version ``n+1`` using an ``<img>`` link. The image will not show until
302    version ``n+1`` is actually inserted into the system; thus,
303    when the image does show up, the user knows that they should click
304    on it to get to a newer version of the document.
305    In Freenet, files only stay online as long as they are
306    requested regularly; keeping a copy on your harddisk
307    does not keep a page alive.
308    
309    Finally, a simplistic approach to P2P versioning
310    is to have a centralized server keep track of the current version
311    of a document, such as in the *Content-Addressable Web*
312    proposal [content-addressable-web]_, in which clients download
313    a file's hash through HTTP (using an HTTP URI),
314    then download the file through, e.g., a filesharing network.
315    This provides some of the efficiency advantages of a P2P Web.
316    However, there is still a single point of failure, and
317    links still break when pages move to a different directory
318    or Web server.
319    In the Content-Addressable Web proposal, the situation
320    regarding versioning is the same as on the current Web.
321    
322    
323  Pointer records  Pointer records

Legend:
Removed from v.1.177  
changed lines
  Added in v.1.178

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26