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

Diff of /manuscripts/storm/article.rst

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

revision 1.108 by benja, Fri Feb 7 15:09:27 2003 UTC revision 1.109 by benja, Fri Feb 7 23:27:22 2003 UTC
# Line 60  We address two issues raised by data mob Line 60  We address two issues raised by data mob
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,
# Line 76  they should be able to form an ad-hoc ne Line 81  they should be able to form an ad-hoc ne
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.
# Line 107  to work on the version at hand and then Line 112  to work on the version at hand and then
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.
# Line 159  Section 9 concludes the paper. Line 167  Section 9 concludes the paper.
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
# Line 181  accessible even after the original publi Line 233  accessible even after the original publi
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,
# Line 205  into a global namespace and allows indep Line 247  into a global namespace and allows indep
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
# Line 247  as well as serverless versioning (like e Line 283  as well as serverless versioning (like e
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.
# Line 291  in a Zip archive, in a database or throu Line 347  in a Zip archive, in a database or throu
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
# Line 465  mappings into the index. Instead, applic Line 511  mappings into the index. Instead, applic
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    
# Line 791  implementations *peers* self-organise in Line 836  implementations *peers* self-organise in
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  -------------------------------------------------  -------------------------------------------------
# Line 833  hosts. (does storm actually do this / is Line 899  hosts. (does storm actually do this / is
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    
# Line 861  interestingly zope by default stores dif Line 928  interestingly zope by default stores dif
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    

Legend:
Removed from v.1.108  
changed lines
  Added in v.1.109

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