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 |
|
|
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; |
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 |