Un primo esempio di applicazione che si basa su questo principio è NAPSTER, in cui ogni peer si connette e informa il server centrale del proprio IP e dei propri contenuti. Quando qualcuno ha bisogno di un file, chiede al server, che gli risponde con la locazione (rappresentata dall'IP). Il problema è che la localizzazione dei file è centralizzata.
Gnutella invece è totalmente distribuito, non ha quindi server centralizzati, ma si basa sul principio che x e y sono collegati se hanno una connessione TCP in comune. Tutti i peer attivi sono nell'overlay. Il protocollo di ricerca è ricorsivo (ricerca in profondità) con un flooding limitato.
Kazaa è simile a gnutella ma esistono gruppi di peer, ognuno dei quali è munito di un group leader. Il leader ha una connessione TCP con ogni suo figlio e con altri due leader. In questo modo ogni leader conosci i contenuti dei suoi edge peer. Ogni file ha un descrittore hash nel suo database, se non p presente la chiave di ricerca chiede agli altri leader collegati. Quando qualcuno trova la risposta che la rimanda al cliente il quale scarica una copia HTTP.
Nei p2p strutturati le informazioni sul singolo file vengono messi in una posizione specifica a seconda dell'ID. L'ID viene usata come chiave di ricerca anche di singole parole chiave da usare nella ricerca. La ricerca, siccome si basa su Hash Table distribuite (DHT), è molto veloce ma soffre nei caso in cui i peer entrano escono frequentemente (churn). Grazie a questo metodo la ricerca viene effettuata in O(logN) passi al massimo ed ha la probabilità di HIT, nel caso in cui il file esista, pari a 1. Se un nuovo peer arriva estrae a caso un ID e cerca i suoi vicini. dai quali riceve parte degli indici. Nel caso in cui il peer si disconnetta, il suo indice deve essere passato ai suoi vicini (churn rate). Chi possiede un nuovo file ne calcola l'hash e lo registra nel peer che ha l'indice per quell'hash.
| < Prec. | Succ. > |
|---|
