[Gzz-commits] manuscripts/storm article.rst

[Hermanni Hyytiälä]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Hermanni Hyytiälä <address@hidden>      03/02/10 05:59:46

Modified files:
        storm          : article.rst 

Log message:
        Fixes, etc.

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/storm/article.rst.diff?tr1=1.125&tr2=1.126&r1=text&r2=text

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.125 manuscripts/storm/article.rst:1.126
--- manuscripts/storm/article.rst:1.125 Mon Feb 10 03:02:28 2003
+++ manuscripts/storm/article.rst       Mon Feb 10 05:59:46 2003
@@ -8,8 +8,8 @@
 We define data mobility as a collective term for the
 movement of documents between computers, locations on one computer and
 movement of content between documents.
-We identify dangling links, tracking identity and alternative versions as the 
main 
-roadblocks for the free movement of data,
+We identify dangling links, tracking identity and alternative versions as
+obstacles for the free movement of data,
 and review
 motivations and potential solutions in existing hypermedia research.
 We discuss some specific use scenarios, related to ad hoc networks,
@@ -18,7 +18,7 @@
 [mention some of the additional benefits?]
 in which the need for data mobility is obvious.
 
-We present our Storm (STORage Module) design as one possible solution
+We present Storm (STORage Module) design as one possible solution
 to the problems in the above scenarios.
 Storm uses
 location-independent globally unique identifiers, immutable block storage
@@ -31,8 +31,11 @@
     Open issues are discussed, and possibilities for future work in areas such 
as interoperability,
     scalability and security are identified.
 
-Keywords: hypermedia, P2P, peer-to-peer, location-independent identifiers,
-versioned hypermedia, xanalogical storage, distributed hashtables
+[Is it better to use passive form or 'We' form  in abstract ? -Hermanni]
+
+Keywords: hypermedia, versioned hypermedia, dangling links, xanalogical 
storage, P2P, 
+peer-to-peer, location-independent identifiers, location-independent routing, 
+distributed hashtables
 
 
 1. Introduction
@@ -49,10 +52,10 @@
 However, recent developments in peer-to-peer systems have
 rendered this assumption obsolete. Structured overlay networks
 [ref chord, can, tapestry, pastry, kademlia, symphony, viceroy,
-skip graph, swan] allow location-independent identifiers
+skip graph, swan, kelips] allow location-independent identifiers
 to be resolved on a global scale. 
-It is now feasible to do a global search to find all information
-about a given identifier, on any peer in the network.
+Thus, it is now feasible to do a global search to find all information
+related to a given identifier on any participating peer in the network.
 This, we believe, may be the most important result of peer-to-peer 
 research with regard to hypermedia.
 
@@ -74,7 +77,7 @@
 Dangling links and keeping track of alternative versions. 
 Resolvable location-independent identifiers
 make these issues much easier to deal with, since data
-can be recognized wherever it is moved [#]_. 
+can be identified wherever it is moved [#]_. 
 
 .. [#] It might be more appropriate to speak about *resources*
    and *references* instead of *documents* and *links*, but
@@ -120,7 +123,7 @@
 the modified version (e.g., a manual licensed under the Gnu FDL [ref]),
 or when a group of people collaborate on a set of documents,
 synchronizing irregularly with a central server (as in CVS [ref]),
-a network (as in Lotus Notes [ref]) or directly with each other 
+a network of servers (as in Lotus Notes [ref]) or directly with each other 
 (as in Groove[?] [ref]). In each of these cases, a user should be able
 to work on the version at hand and then either merge it with others 
 or fork to a different branch.
@@ -292,7 +295,7 @@
 related to peer-to-peer resource discovery, both academical and in the 
industry.
 There are two main approaches: broadcasting [gnutella1, kazaa, limewire,
 shareaza], and distributed hashtables (DHTs) [chord, can, tapestry, pastry,
-kademlia, symphony, viceroy]. Broadcasting systems
+kademlia, symphony, viceroy, kelips]. Broadcasting systems
 forward queries to all systems reachable in a given number of hops
 (time-to-live). DHTs store (key,value) pairs which can be found given
 the key; a DHT assigns each peer a subset of all possible keys, and
@@ -301,14 +304,16 @@
 by sending it to the peer responsible for the key. Both approaches
 use an application-level overlay network for routing.
 
-While broadcasting systems' performance is linear, DHTs' performance
+While broadcasting systems' performance is not always even linear, DHTs' 
performance
 usually has log-like bounds in the number of peers 
 for *all* internal operations [#]_. This scalability is
 what makes global searches feasible in DHTs. In broadcasting approaches,
-on the other hand, scalability is archieved by forwarding queries 
+on the other hand, scalability is achieved by forwarding queries 
 only to a limited subset of the peers (bounded by the time-to-live),
 which means that searches in these systems are not truly global.
 
+[broadcasting's message population can grow as fast as O(n^2) -Hermanni]
+
 .. [#] It's not clear whether *all* proposed DHT designs can preserve
    log-like properties when participants are heterogeneous and they 
    join and leave the system in a dynamic manner. 
@@ -321,9 +326,9 @@
 responsible for a hashtable key, then, is the one that is *closest*
 to it in the key space, according to the distance metric.
 A DHT peer is roughly analogous to a hashtable bucket.
-Queries are routed to the overlay network, each hop bringing
-them closer to its destination in key space, until they reach
-the peer responsible for them.
+Query is routed on top of overlay network, each hop bringing
+query closer to its destination in key space, until they reach
+the peer responsible for the query.
 
 .. http://sahara.cs.berkeley.edu/jan2003-retreat/ravenben_api_talk.pdf
    Full paper will appear in IPTPS 2003 -Hermanni
@@ -1222,6 +1227,8 @@
    potentially boost download speeds to the full available bandwidth).
    This is a performance/reliability issue rather than something
    changing the fundamental qualities of the network, but still important.
+   
+   [Symphony supports heterogeneity of peers -Hermanni]
 
    The important point about p2p publishing is that no account and setup
    is necessary to start publishing.
@@ -1277,3 +1284,4 @@
 a current version also)
 
 Harri Oinas-Kukkonen, observations (overall, about benefits, presentation)
+