[Gzz-commits] manuscripts/storm article.rst

[Hermanni Hyytiälä]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Hermanni Hyytiälä <address@hidden>      03/01/29 04:28:59

Modified files:
        storm          : article.rst 

Log message:
        More p2p overview

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

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.51 manuscripts/storm/article.rst:1.52
--- manuscripts/storm/article.rst:1.51  Wed Jan 29 03:23:49 2003
+++ manuscripts/storm/article.rst       Wed Jan 29 04:28:59 2003
@@ -309,25 +309,40 @@
 Intensive work in p2p field has yielded two main approaches: broadcasting 
 [ref: gnutella1, kazaa, limewire, shareaza] and Distributed Hash Tables (DHT) 
 [refs: chord, can, tapestry, pastry, kademlia, symphony, viceroy, skip graphs, 
-swan]. Both of these approaches build an *application* level overlay network.
- 
-However, there are *significant* differences between broadcasting and DHT 
-approach, i.e. in scalability and efficiency properties, how the overlay 
network
-is created and maintained and how queries are performed. For instance, in 
-broadcasting approach, a peer performing a query sends a query request to a 
subset 
-of its neighbors and these peers to their subsequent neighbors. The process 
-will continue as long as query's time-to-live (TTL) hasn't been reached. In 
DHT 
-approach, query request is deterministically routed towards the node which 
hosts a 
-specific data item.
-
-Furthermore,   
-For instance, in SWAN [ref] and Skip Graph [ref] implementations, *data items* 
-self-organise in a virtual address space, while in other DHT implementations, 
-*peers* self-organise in virtual address space.
+swan]. Both of these approaches build an *application* level overlay 
connectivity 
+graph network. However, there are *significant* differences between 
broadcasting 
+and DHT approach, i.e. in scalability and efficiency properties, how the 
overlay 
+network is created and maintained and how queries are performed. DHT is seen 
as 
+scalable approach and usually provides (poly)logarithmic bounds to *all* 
internal 
+operations (footnote about 'stable state' ?), while broadcasting can't achieve 
+either of these. 
 
+In DHT approach, both keys and the addresses of peers are mapped into one 
virtual 
+key space. The form of key space depends on implementation. The mapping makes 
+possible to assign number of data items to a peer, based on how 'close' data 
+item's and peer's keys are each other. Thus, DHT's overlay connectivity graph 
+is structured. On the other hand, the overlay connectivity graph of 
broadcasting 
+approach is formed more or less (depends on implementation) in a random 
manner. 
 
+When performing queries, in broadcasting approach peer sends a query request 
to a 
+subset of its neighbors and these peers to their subsequent neighbors. The 
+process will continue as long as query's time-to-live (TTL) hasn't been 
reached. 
+In DHT approach, query request is deterministically routed towards the peer 
+which hosts a specific data item. Routing is based on 'hints' (based on 
+differences between data item's key and peer's key), which each peer provides 
+along the routing path.
 
-For our purposes, DHT approach has major benefits over broadcasting.
+Of course, there are major differences within approaches. For DHT approach, 
+perhaps the biggest difference is *what* is self-organized into virtual key 
space. 
+For instance, in SWAN [ref] and Skip Graph [ref], *data items* self-organise 
+into  virtual address space, while in other DHT implementations *peers* 
+self-organise in structured form in virtual space. In broadcasting approach, 
+implementations' differences lie in the structural *level* of overlay network 
+(super peers, clusters).
+
+
+
+For our purposes, DHT seems to be the best choice.