302 |
6. Peer-to-peer implementations |
6. Peer-to-peer implementations |
303 |
=============================== |
=============================== |
304 |
|
|
305 |
XXX |
6.1. Overview |
306 |
|
------------- |
307 |
|
During the last few years, there have been a lot of research efforts related |
308 |
|
to Peer-to-Peer (p2p) resource discovery, both in industry and academic world. |
309 |
|
Intensive work in p2p field has yielded two main approaches: broadcasting |
310 |
|
[ref: gnutella1, kazaa, limewire, shareaza] and Distributed Hash Tables (DHT) |
311 |
|
[refs: chord, can, tapestry, pastry, kademlia, symphony, viceroy, skip graphs, |
312 |
|
swan]. Both of these approaches build an *application* level overlay network. |
313 |
|
|
314 |
|
However, there are *significant* differences between broadcasting and DHT |
315 |
|
approach, i.e. in scalability and efficiency properties, how the overlay network |
316 |
|
is created and maintained and how queries are performed. For instance, in |
317 |
|
broadcasting approach, a peer performing a query sends a query request to a subset |
318 |
|
of its neighbors and these peers to their subsequent neighbors. The process |
319 |
|
will continue as long as query's time-to-live (TTL) hasn't been reached. In DHT |
320 |
|
approach, query request is deterministically routed towards the node which hosts a |
321 |
|
specific data item. |
322 |
|
|
323 |
|
Furthermore, |
324 |
|
For instance, in SWAN [ref] and Skip Graph [ref] implementations, *data items* |
325 |
|
self-organise in a virtual address space, while in other DHT implementations, |
326 |
|
*peers* self-organise in virtual address space. |
327 |
|
|
328 |
|
|
329 |
|
|
330 |
|
For our purposes, DHT approach has major benefits over broadcasting. |
331 |
|
|
332 |
|
|
333 |
|
|
334 |
|
|
335 |
7. Experience and future directions |
7. Experience and future directions |