227 |
88797, which matches the first three digits, then the routing algorithm forwards the query to a node which matches |
88797, which matches the first three digits, then the routing algorithm forwards the query to a node which matches |
228 |
the first four digits. To accomplish this, a each node forwards a packet to a neighbor whose label matches (from left |
the first four digits. To accomplish this, a each node forwards a packet to a neighbor whose label matches (from left |
229 |
to right) incrementally the destination label in one more digit than its own label does. For a system with $n$ nodes, |
to right) incrementally the destination label in one more digit than its own label does. For a system with $n$ nodes, |
230 |
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)$. |
231 |
|
|
232 |
|
|
233 |
\section{Tapestry} |
\section{Tapestry} |
234 |
Tapestry \cite{zhao01tapestry} is a adaption of Plaxton's algorithm \cite{plaxton97accessingnearby}. Tapestry |
Tapestry \cite{zhao01tapestry} is a adaption of Plaxton's algorithm \cite{plaxton97accessingnearby}. As in Plaxton's approach, |
235 |
routes queries with path lengths of $O(log n)$, and each node, for a systems with $n$ nodes, maintains routing table |
each node has a identifier. In addition to Plaxton algorithm, Tapestry has better fault handling and support for dynamic |
236 |
size of $O(log n)$. When a node leaves or joins to network, $O(log^2 n)$ messages are required. |
peers. In Tapestry, using IP addresses as node identifiers make the overlay network topology rather similar to the real |
237 |
|
network topology, because IP addresses ``enough close'' to each other share some length of the same prefix. Therefore, |
238 |
|
the latency of the query (messages) hop is minimal. Tapestry routes queries with path lengths of $O(log n)$, and each node, |
239 |
|
for a systems with $n$ nodes, maintains routing table size of $O(log n)$. When a node leaves or joins to network, |
240 |
|
$O(log^2 n)$ messages are required. |
241 |
|
|
242 |
\section{Pastry} |
\section{Pastry} |
243 |
In Pastry \cite{rowston01pastry}, the key space is considered as a virtual circle. Each node is responsible for keys |
In Pastry \cite{rowston01pastry}, the key space is considered as a virtual circle. Each node is responsible for keys |
279 |
needs a single nearby copy. |
needs a single nearby copy. |
280 |
|
|
281 |
\section{Gnutella} |
\section{Gnutella} |
282 |
\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 |
283 |
|
a small number of active connections to its neighbor. These peers are selected from a locally maintained host catcher list, which contains |
284 |
|
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 |
285 |
|
of a message in hops. Every node receiving a query will forward the message to all of its neighbour nodes, unless the message has |
286 |
|
reached the TTL limit. Therefore query results are fast, because BFS sends queries to every possible nodes. However, this approach wastes |
287 |
|
resources, since BFS sends queries to every possible neighbor nodes. |
288 |
|
|
289 |
|
|
290 |
\section{GISP} |
\section{GISP} |
291 |
\section{Coral} |
|
292 |
|
GISP (Global Information Sharing Protocol) \cite{kato02gisp} |
293 |
|
|
294 |
\section{Yappers} |
\section{Yappers} |
295 |
|
|
296 |
|
|
297 |
\section{FastTrack} |
\section{FastTrack} |
298 |
\section{Gnutella2} |
\section{Gnutella2} |
299 |
\section{JXTA} |
\section{JXTA} |
300 |
\section{Kademlia} |
|
301 |
|
\section{SWAN} |
302 |
|
|
303 |
\section{Freenet} |
\section{Freenet} |
304 |
\section{Alpine} |
\section{Alpine} |
305 |
\section{Napster} |
\section{Napster} |