[Gzz-commits] gzz/Documentation/misc/hemppah-progradu mastert...

[Hermanni Hyytiälä]

CVSROOT:        /cvsroot/gzz
Module name:    gzz
Changes by:     Hermanni Hyytiälä <address@hidden>      02/12/10 09:07:11

Modified files:
        Documentation/misc/hemppah-progradu: masterthesis.tex 

Log message:
        once more DHT updates

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/Documentation/misc/hemppah-progradu/masterthesis.tex.diff?tr1=1.23&tr2=1.24&r1=text&r2=text

Patches:
Index: gzz/Documentation/misc/hemppah-progradu/masterthesis.tex
diff -u gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.23 
gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.24
--- gzz/Documentation/misc/hemppah-progradu/masterthesis.tex:1.23       Tue Dec 
10 08:05:08 2002
+++ gzz/Documentation/misc/hemppah-progradu/masterthesis.tex    Tue Dec 10 
09:07:11 2002
@@ -227,13 +227,17 @@
 88797, which matches the first three digits, then the routing algorithm 
forwards the query to a node which matches 
 the first four digits. To accomplish this, a each node forwards a packet to a 
neighbor whose label matches (from left 
 to right) incrementally the destination label in one more digit than its own 
label does. For a system with $n$ nodes, 
-Plaxton's algorithm routes in $O(log n)$ hops and requires a routing table 
size of $O(log n)$. 
+Plaxton's algorithm routes in $O(log n)$ hops and requires a routing table 
size of $O(log n)$.  
   
 
 \section{Tapestry}
-Tapestry \cite{zhao01tapestry} is a adaption of Plaxton's algorithm 
\cite{plaxton97accessingnearby}. Tapestry 
-routes queries with path lengths of $O(log n)$, and each node, for a systems 
with $n$ nodes, maintains routing table 
-size of $O(log n)$. When a node leaves or joins to network,  $O(log^2 n)$ 
messages are required.
+Tapestry \cite{zhao01tapestry} is a adaption of Plaxton's algorithm 
\cite{plaxton97accessingnearby}. As in Plaxton's approach, 
+each node has a identifier. In addition to Plaxton algorithm, Tapestry has 
better fault handling and support for dynamic 
+peers. In Tapestry, using IP addresses as node identifiers make the overlay 
network topology rather similar to the real
+network topology, because IP addresses ``enough close'' to each other share 
some length of the same prefix. Therefore, 
+the latency of the query (messages) hop is minimal. Tapestry routes queries 
with path lengths of $O(log n)$, and each node, 
+for a systems with $n$ nodes, maintains routing table size of $O(log n)$. When 
a node leaves or joins to network,  
+$O(log^2 n)$ messages are required.
 
 \section{Pastry}
 In Pastry \cite{rowston01pastry}, the key space is considered as a virtual 
circle. Each node is responsible for keys 
@@ -275,14 +279,27 @@
 needs a single nearby copy.
 
 \section{Gnutella}
-\section{OceanStore}
+Gnutella \cite{gnutellaurl} is a peer-to-peer file-sharing system which treats 
all nodes in the network functionally equivalent. Each peer tries to maintain 
+a small number of active connections to its neighbor. These peers are selected 
from a locally maintained host catcher list, which contains 
+the addresses of the neighbor peers. Gnutella uses a Breadt-First-Search (BFS) 
traversal with depth limit L, where L is the system-wide maximum TTL 
+of a message in hops. Every node receiving a query will forward the message to 
all of its neighbour nodes, unless the message has 
+reached the TTL limit. Therefore query results are fast, because BFS sends 
queries to every possible nodes. However, this approach wastes 
+resources, since BFS sends queries to every possible neighbor nodes.
+
+
 \section{GISP}
-\section{Coral}
+
+GISP (Global Information Sharing Protocol) \cite{kato02gisp}
+
 \section{Yappers}
+
+
 \section{FastTrack}
 \section{Gnutella2}
 \section{JXTA}
-\section{Kademlia}
+
+\section{SWAN}
+
 \section{Freenet}
 \section{Alpine}
 \section{Napster}