60 |
Dangling links and keeping track of alternative versions. |
Dangling links and keeping track of alternative versions. |
61 |
Resolvable location independent identifiers |
Resolvable location independent identifiers |
62 |
make these issues much easier to deal with, since data |
make these issues much easier to deal with, since data |
63 |
can be recognized whereever it is moved. |
can be recognized whereever it is moved [#]_. |
64 |
|
|
65 |
|
.. [#] It might be more appropriate to speak about *resources* |
66 |
|
and *references* instead of *documents* and *links*, but |
67 |
|
in the spirit of [ref kappe95scalable], we stick with |
68 |
|
the latter terms for explanation purposes. |
69 |
|
|
70 |
*Dangling links* are an issue when documents are moved |
*Dangling links* are an issue when documents are moved |
71 |
between servers; when no network connection is available, |
between servers; when no network connection is available, |
81 |
to documents stored on either one's computer [ref Thompson et al]. |
to documents stored on either one's computer [ref Thompson et al]. |
82 |
|
|
83 |
Advanced hypermedia systems such as Microcosm and Hyper-G |
Advanced hypermedia systems such as Microcosm and Hyper-G |
84 |
address dangling links through a notification system: |
address dangling links through a notification system [ref]: |
85 |
When a document is moved, servers storing links to it are notified. |
When a document is moved, servers storing links to it are notified. |
86 |
Hyper-G uses an efficient protocol for delivering such notifications |
Hyper-G uses an efficient protocol for delivering such notifications |
87 |
on the public Internet. |
on the public Internet. |
112 |
or fork to a different branch. |
or fork to a different branch. |
113 |
|
|
114 |
In this paper, we present Storm (for *storage module*), a design |
In this paper, we present Storm (for *storage module*), a design |
115 |
dealing with these issues of link intactness and version management. Storm is a library |
dealing with versioning and dangling links. Storm is a library |
116 |
for storing and retrieving data as *blocks*, immutable |
for storing and retrieving data as *blocks*, immutable |
117 |
byte sequences identified by cryptographic content hashes |
byte sequences identified by cryptographic content hashes |
118 |
[ref ht'02 paper]. Additionally, Storm provides services |
[ref ht'02 paper]. Additionally, Storm provides services |
119 |
for versioned data and Xanalogical storage [ref]. |
for versioned data and Xanalogical storage [ref]. |
120 |
The Storm design, a hypermedia system built to make use |
|
121 |
of the emerging peer-to-peer search technologies, |
The main contribution of this paper is the Storm design, |
122 |
is the main contribution of this paper. |
a hypermedia system built to make use of the emerging |
123 |
|
peer-to-peer search technologies. Additionally, we hope to |
124 |
|
provide an input to the ongoing discussion about peer-to-peer |
125 |
|
hypermedia systems [ref ht01, ht02]. |
126 |
|
|
127 |
Currently, Storm is partially implemented as a part of the Gzz |
Currently, Storm is partially implemented as a part of the Gzz |
128 |
project [ref], which uses Storm exclusively for all disk storage. |
project [ref], which uses Storm exclusively for all disk storage. |
167 |
2. Related Work |
2. Related Work |
168 |
=============== |
=============== |
169 |
|
|
170 |
In advanced hypermedia systems such as Microcosm[] and Hyper-G[], |
The dangling link problem has received a lot of attention |
171 |
several approaches has been proposed to deal with the dangling/other link |
in hypermedia research [refs]. As examples, we examine the ways |
172 |
management problems. |
in which HTTP, Microcosm [ref], Chimera [ref] and Hyper-G [ref] |
173 |
|
deal with the problem. |
174 |
|
|
175 |
|
In HTTP, servers are able to notify a client that a document |
176 |
|
has been moved, and redirect it accordingly [ref spec?]. However, |
177 |
|
this is not required, and there are no facilities for |
178 |
|
updating a link automatically when its target is moved. |
179 |
|
Consequently, broken links are a common experience for Web users. |
180 |
|
|
181 |
|
In Microcosm, hypermedia functionality is implemented |
182 |
|
through *filters*, which react to arbitrary messages |
183 |
|
(such as 'find links to this anchor') generated by |
184 |
|
a client application. Filters are processes on the local system |
185 |
|
or on a remote host [ref distributed microcosm]. When |
186 |
|
a document is moved or deleted, a message is sent |
187 |
|
to the filters. Linkbases implemented as filters can |
188 |
|
update their links accordingly. A client selects a set |
189 |
|
of remote filters to use. Only links stored by one |
190 |
|
of these filters can be found. |
191 |
|
[HymEbook?] |
192 |
|
|
193 |
|
.. Microcosm systems can independently choose |
194 |
|
whether to import filters from other systems, and whether |
195 |
|
to host and export own filters; thus, a system can act |
196 |
|
as both a client and server at the same time, |
197 |
|
for example in a workgroup. |
198 |
|
|
199 |
|
In Hyper-G, documents are bound to servers, and a link |
200 |
|
is stored on the servers of the two documents it connects |
201 |
|
[kappe95scalable]. This ensures that all links to a document |
202 |
|
can always be found, but requires the cooperation |
203 |
|
of both servers. Hyper-G employs a scalable protocol |
204 |
|
for notifying servers when a document has been moved or removed. |
205 |
|
A server hosting links to this document can then ask |
206 |
|
the link's author to change the link, or at least the link |
207 |
|
can be removed automatically. The *p-flood* algorithm |
208 |
|
employed by Hyper-G for this purpose guarantees that a message |
209 |
|
is delivered to all interested servers, but requires that each |
210 |
|
interested server keeps a list of all the others. |
211 |
|
|
212 |
|
[XXX Chimera -- or any other distributed hypermedia system?] |
213 |
|
|
214 |
|
All of these systems are built around the fundamental assumption |
215 |
|
that it is impossible to resolve a random [XXX] identifier. |
216 |
The use of location-independent identifiers |
The use of location-independent identifiers |
217 |
for documents, resolved through a peer-to-peer lookup system, |
for documents, resolved through a peer-to-peer lookup system, |
218 |
makes such a notification unnecessary; when a document is moved, |
makes notification of the servers storing links unnecessary; |
219 |
|
when a document is moved, |
220 |
but retains its identifier, it can be found by the same mechanism as |
but retains its identifier, it can be found by the same mechanism as |
221 |
before the move. It is possible to retrieve the document |
before the move. It is possible to retrieve the document |
222 |
from any system storing a copy; this means that documents may be |
from any system storing a copy; this means that documents may be |
223 |
accessible even after the original publisher has taken them off-line [#]_. |
accessible even after the original publisher has taken them off-line [#]_. |
224 |
|
|
225 |
[Relocate this, e.g. at the end of this section ? -Hermanni] |
Conversely, an external link published by any host can be found |
226 |
|
when the endpoint of the link is known... XXX |
227 |
|
|
228 |
.. [#] Intentionally or unintentionally. We believe that it is |
.. [#] Intentionally or unintentionally. We believe that it is |
229 |
a good thing if published documents remain available even when |
a good thing if published documents remain available even when |
233 |
[Possible refs: http://www.openp2p.com/topics/p2p/p2p_law/. |
[Possible refs: http://www.openp2p.com/topics/p2p/p2p_law/. |
234 |
However, they are necessarily directly related to this :( -Hermanni] |
However, they are necessarily directly related to this :( -Hermanni] |
235 |
|
|
236 |
Microcosm addressed the linking problems of large archives |
Even Xanadu [ref], which went a long way to ensure that links do not break |
237 |
by separating the links from the documents and storing them on dedicated |
when their targets are copied from one document to another, |
238 |
linkbases, with the the following requirement: when a document (where a |
required permanent connection to a network of servers to function. |
239 |
position or document dependant link anchor occurs) is moved or deleted, |
Moreover, Xananu's 1988 incarnation [ref Green] addressed data |
240 |
the hypermedia document management system (or hyperbase), ought to be informed |
based on the address of a server holding a 'master copy.' |
|
[HymEbook?]. |
|
|
|
|
|
In Hyper-G, when there are similar changes, all other Hyper-G servers that |
|
|
reference to specific document can be informed, and an efficient protocol has been |
|
|
proposed for that purpose [kappe95scalable]. |
|
|
(All that does not change the basic assumption, may even be seen as |
|
|
workarounds from the p2p solution's point of view?) |
|
|
[yet Chimera and other OHS?] |
|
|
-- agreed: we're talking server-centric vs documents-not-bound-to-server, |
|
|
here; I believe most distributed hymedia sys are server-centric in this sense.] |
|
241 |
|
|
242 |
Likewise, version control systems like CVS or RCS [ref] usually assume |
Likewise, version control systems like CVS or RCS [ref] usually assume |
243 |
a central server hosting a repository. The WebDAV/DeltaV protocols, |
a central server hosting a repository. The WebDAV/DeltaV protocols, |
247 |
to branch and merge overlapping repositories without any central control |
to branch and merge overlapping repositories without any central control |
248 |
[is there a specific ref for this?]. |
[is there a specific ref for this?]. |
249 |
|
|
|
Even Xanadu [ref], which went a long way to ensure that links do not break |
|
|
when their targets are copied from one document to another, |
|
|
required permanent connection to a network of servers to function. |
|
|
Moreover, Xananu's 1988 incarnation [ref Green] addressed data |
|
|
based on the address of a server holding a 'master copy.' |
|
|
|
|
250 |
Lotus Notes [ref], popular database sharing and colloboration tool, has some |
Lotus Notes [ref], popular database sharing and colloboration tool, has some |
251 |
similarities to Storm. In both systems, for instance, data is identified by |
similarities to Storm. In both systems, for instance, data is identified by |
252 |
using GUIDs. However, partly because of the long age of the system, Lotus Notes |
using GUIDs. However, partly because of the long age of the system, Lotus Notes |
283 |
3. Block storage |
3. Block storage |
284 |
================ |
================ |
285 |
|
|
286 |
[Do we need a figure, which shows the overall structure of block storage |
.. [Do we need a figure, which shows the overall structure of block storage |
287 |
with pointers, diffs etc ? -Hermanni] |
with pointers, diffs etc ? -Hermanni] |
288 |
|
|
289 |
In our system, Storm (for *storage module*), all data is stored |
In Storm, all data is stored |
290 |
as *blocks*, byte sequences identified by a SHA-1 cryptographic content-hash |
as *blocks*, byte sequences identified by a SHA-1 cryptographic content hash |
291 |
[ref SHA-1 and our ht'02 paper]. Blocks have a similar granularity |
[ref SHA-1 and our ht'02 paper]. Blocks have a similar granularity |
292 |
as regular files, but they are immutable, since any change to the |
as regular files, but they are immutable, since any change to the |
293 |
byte sequence would change the hash (and thus create a different block). |
byte sequence would change the hash (and thus create a different block). |
294 |
Mutable data structures are built on top of the immutable blocks |
Mutable data structures are built on top of the immutable blocks |
295 |
(see Section 6). |
(see Section 6). |
296 |
|
|
297 |
Immutable blocks has several benefits over existing data storing |
Storing data in immutable blocks may seem strange at first, but |
298 |
techiques: |
has a number of advantages. Firstly, it makes it easy |
299 |
|
to replicate data between systems: A replica of a block never |
300 |
|
needs to be updated; cached copies can be kept as long as desired. |
301 |
|
When a document is replicated, different versions of it can |
302 |
|
coexist on the same system without naming conflicts, since |
303 |
|
each version will be stored in its own block with its own id. |
304 |
|
|
|
Storm's block storage makes it easy to replicate data between systems. |
|
|
Different versions of the same document can easily coexist at this level, |
|
|
stored in different blocks. |
|
|
[Previous sentence doesn't parse to me (what level ?) :( -Hermanni] |
|
305 |
To replicate all data from computer A |
To replicate all data from computer A |
306 |
on computer B, it suffices to copy all blocks from A to B that B |
on computer B, it suffices to copy all blocks from A to B that B |
307 |
does not already store. On the other hand for instance, several popular |
does not already store. This can be done through a simple 'copy' |
308 |
database management systems (e.g. Lotus Notes [ref]) have complex |
command. In contrast, a system based on mutable resources |
309 |
replication schemes, which may led awkward replication conflicts, |
has to use more advanced schemes, for example merging the changes |
310 |
because of they lack the immutable properties of data. |
done to a document at A or B. (Merging is still be necessary |
311 |
[Or does this belong to diff section ? -Hermanni] |
when a user wants to incorporate a set of changes, but not |
312 |
|
required at replication time.) |
313 |
|
|
314 |
|
Secondly, immutable blocks increase *reliability*. |
315 |
|
When saving a document, an application will only *add* blocks, |
316 |
|
never overwrite existing data. When a bug causes an application |
317 |
|
to write malformed data, only the changes from one session |
318 |
|
will be lost; the previous version of the data will still |
319 |
|
be accessible. This makes Storm well suited as a basis |
320 |
|
for implementing experimental projects (such as ours). |
321 |
|
Even production systems occasionally corrupt existing data |
322 |
|
when an overwriting save operation goes awry; for example, |
323 |
|
one of the authors has had this problem with |
324 |
|
Microsoft Word many times. |
325 |
|
|
326 |
|
.. On the other hand for instance, several popular |
327 |
|
database management systems (e.g. Lotus Notes [ref]) have complex |
328 |
|
replication schemes, which may led awkward replication conflicts, |
329 |
|
because of they lack the immutable properties of data. |
330 |
|
[Or does this belong to diff section ? -Hermanni] |
331 |
|
|
332 |
Storm blocks are MIME messages [ref MIME], i.e., objects with |
Storm blocks are MIME messages [ref MIME], i.e., objects with |
333 |
a header and body as used in Internet mail or HTTP. |
a header and body as used in Internet mail or HTTP. |
347 |
We have implemented the first three (using hexadecimal |
We have implemented the first three (using hexadecimal |
348 |
representations of the block ids for file names). |
representations of the block ids for file names). |
349 |
|
|
|
Storing all data in Storm blocks provides *reliability*: |
|
|
When saving a document, an application will only *add* blocks, |
|
|
never overwrite existing data. When a bug causes an application |
|
|
to write malformed data, only the changes from one session |
|
|
will be lost; the previous version of the data will still |
|
|
be accessible. This makes Storm well suited as a basis |
|
|
for implementing experimental projects (such as ours). |
|
|
|
|
|
[Example of common Microsoft Word saving issue ? -Hermanni] |
|
|
|
|
350 |
When used in a network environment, Storm IDs do not provide |
When used in a network environment, Storm IDs do not provide |
351 |
a hint as to where a specific block is stored in the network. |
a hint as to where a specific block is stored in the network. |
352 |
However, many existing peer-to-peer systems could be used to |
However, many existing peer-to-peer systems could be used to |
511 |
to index blocks provide the following callback |
to index blocks provide the following callback |
512 |
to a Storm pool:: |
to a Storm pool:: |
513 |
|
|
514 |
getMappings(block) -> set of (key, value) pairs |
getMappings(block) -> |
515 |
|
set of (key, value) pairs |
|
.. [What is mapping ? We should explain this :) -Hermanni |
|
|
isn't it explained above? it's a set of key-value pairs] |
|
516 |
|
|
517 |
This callback processes a block and returns a set of mappings |
This callback processes a block and returns a set of mappings |
518 |
to be placed into the index. The Storm pool, in turn, provides |
(key/value pairs) to be placed into the index. |
519 |
the following interface to the application: |
The Storm pool, in turn, provides |
520 |
|
the following interface to the application:: |
521 |
|
|
522 |
get(key) -> set of (block, value) pairs |
get(key) -> set of (block, value) pairs |
523 |
|
|
836 |
In broadcasting approach, implementations' differences mostly lie in the |
In broadcasting approach, implementations' differences mostly lie in the |
837 |
*structural level* of overlay network, i.e. super peers and peer clusters. |
*structural level* of overlay network, i.e. super peers and peer clusters. |
838 |
|
|
839 |
|
.. (Probabilistic access to documents may be ok in e.g. workgroups, |
840 |
|
but does not really seem desirable. (At the ht'02 panel, Bouvin |
841 |
|
said they might be ok, which others found very... bold.) |
842 |
|
One example may be a user's public comments on documents; |
843 |
|
these might be only available when that user is online. |
844 |
|
|
845 |
|
.. cf half-life of peers (Mojo Nation): Is it desirable that 'weak' peers |
846 |
|
participate in a DHT? -- In Circle, peers must have been online |
847 |
|
for at least an hour... In which ways, then, can 'weak' peers contribute |
848 |
|
to the network in a p2p fashion? Caching is certainly one central |
849 |
|
way, esp. when combined with multisource downloading (this can |
850 |
|
potentially boost download speeds to the full available bandwidth). |
851 |
|
This is a performance/reliability issue rather than something |
852 |
|
changing the fundamental qualities of the network, but still important. |
853 |
|
|
854 |
|
The important point about p2p publishing is that no account and setup |
855 |
|
is necessary to start publishing. |
856 |
|
|
857 |
|
One possibility: Use IBP for limited-time publishing, referring to |
858 |
|
the location through the DHT? This might be related to p2p publishing. |
859 |
|
|
860 |
|
|
861 |
Review of the use cases: what does storm in each? |
Review of the use cases: what does storm in each? |
862 |
------------------------------------------------- |
------------------------------------------------- |
899 |
7. When B reconnects, can check comments to the Document etc? How does that |
7. When B reconnects, can check comments to the Document etc? How does that |
900 |
happen? Index? |
happen? Index? |
901 |
|
|
902 |
|
|
903 |
8. Experience and future directions |
8. Experience and future directions |
904 |
=================================== |
=================================== |
905 |
|
|
928 |
Benja also noted about pointing to external data? (couldn't find the post |
Benja also noted about pointing to external data? (couldn't find the post |
929 |
from the archives) |
from the archives) |
930 |
|
|
931 |
|
|
932 |
9. Conclusions |
9. Conclusions |
933 |
============== |
============== |
934 |
|
|