247 |
In this section, we shall briefly discuss the existing approaches |
In this section, we shall briefly discuss the existing approaches |
248 |
to document updates in P2P systems. |
to document updates in P2P systems. |
249 |
|
|
250 |
|
A trivial approach to P2P versioning |
251 |
|
is to have a centralized server keep track of the current version |
252 |
|
of a document, such as in the *Content-Addressable Web* |
253 |
|
proposal [content-addressable-web]_, in which clients download |
254 |
|
a file's hash through HTTP (using an HTTP URI), |
255 |
|
then download the file through, e.g., a filesharing network. |
256 |
|
This provides some of the efficiency advantages of a P2P Web. |
257 |
|
However, there is still a single point of failure, and |
258 |
|
links still break when pages move to a different directory |
259 |
|
or Web server. |
260 |
|
In the Content-Addressable Web proposal, the situation |
261 |
|
regarding versioning is the same as on the current Web. |
262 |
|
|
263 |
|
*Freenet*, a P2P network for anonymous publication [freenet-ieee]_, |
264 |
|
was originally planned to have an |
265 |
|
update mechanism where the network would remember |
266 |
|
the current version of a document, and update this information |
267 |
|
when receiving a message signed by the appropriate key, |
268 |
|
rather like in OceanStore. However, in practice, |
269 |
|
Freenet has a rather peculiar combination |
270 |
|
of two workarounds [freenetfaq]_. |
271 |
|
In date-based updating, the URI for the current version |
272 |
|
is formed by concatenating a document's id with the current date; |
273 |
|
this requires publishers to insert versions of their document |
274 |
|
every day, otherwise they will not be accessible. |
275 |
|
In edition-based updating, a version's URI is the document's id |
276 |
|
concatenated with a version number. Version ``n`` then links to |
277 |
|
version ``n+1`` using an ``<img>`` link. The image will not show until |
278 |
|
version ``n+1`` is actually inserted into the system; thus, |
279 |
|
when the image does show up, the user knows that they should click |
280 |
|
on it to get to a newer version of the document. |
281 |
|
In Freenet, files only stay online as long as they are |
282 |
|
requested regularly; keeping a copy on your harddisk |
283 |
|
does not keep a page alive. |
284 |
|
|
285 |
*CFS* [dabek01widearea]_ |
*CFS* [dabek01widearea]_ |
286 |
is a file system based on Chord [stoica01chord]_, storing |
is a file system based on Chord [stoica01chord]_, storing |
287 |
data in a distributed hashtable (DHT). CFS identifies |
data in a distributed hashtable (DHT). CFS identifies |
325 |
semantics; for example, the NFS client for OceanStore only requests |
semantics; for example, the NFS client for OceanStore only requests |
326 |
new heartbeats less than 30 seconds old. |
new heartbeats less than 30 seconds old. |
327 |
|
|
|
*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. |
|
|
|
|
328 |
|
|
329 |
Pointer records |
Pointer records |
330 |
=============== |
=============== |