Reti L-S 2005 Servizio per la ricerca distribuita basato sul protocollo Rossi Daniele 193074.

Presentazione sul tema: "Reti L-S 2005 Servizio per la ricerca distribuita basato sul protocollo Rossi Daniele 193074."— Transcript della presentazione:

1 Reti L-S 2005 Servizio per la ricerca distribuita basato sul protocollo Rossi Daniele 193074

2 Reti L-S 2005 Architettura WebServer layer eBiblioServer layer ChordNode layer Interfaccia per effettuare la ricerca Area in cui viene mostrato il risultato

3 Reti L-S 2005 Architettura WebServer layer eBiblioServer layer ChordNode layer WebServer basato sul progetto Cassini Si pone in ascolto sulla porta 80 del nodo locale Interpreta le richieste provenienti dallinterfaccia Web Interroga il livello sottostante e fornisce una rappresentazione del risultato come pagina html Supporta linterrogazione a partire dal codice ISBN di unopera Si pone in ascolto sulla porta 6001 del nodo locale Gestisce la replicazione delle informazioni sui nodi della rete Interroga il livello sottostante per individuare il nodo della rete che mantiene linformazione cercata Supporta linterrogazione a partire dalla chiave di una risorsa Implementa il protocollo di rete CHORD Si pone in ascolto sulla porta 6000 Gestisce bilanciamento di carico, disponibilità e scalabilità Gestisce join e leave multiplo di nodi

4 Reti L-S 2005 Introduzione P2P: cosè? Peer-to-peer systems and applications are distributed systems without any centralized control or hierarchical organization, where the software running at each node is equivalent in functionality. [SMK+01] Usi comuni: Archiviazione ridondante Permanenza Ricerca Autenticazione Naming gerarchico Naming gerarchico (ad es. SETI@Home) Computazione Distribuita (ad es. SETI@Home)

5 Reti L-S 2005 Tipologie di lookup Lookup centralizzato (Napster) Architettura ibrida. Più server centrali risolvono le ricerche. Publish Search Flooded queries (Gnutella) Peer to Peer puro non strutturato Ogni nodo invia ricorsivamente la richiesta ai propri vicini. Routed Queries Architettura pura strutturata. Ogni peer attua politiche di routing

6 Reti L-S 2005 Protocollo scalabile per il lookup di chiavi in un sistema peer-to-peer con frequente arrivo e abbandono di nodi. Un nodo può entrare o uscire dalla rete in ogni momento Ad ogni nodo e risorsa è assegnata una chiave univoca tramite un algoritmo di consistent hasing Ogni chiave è mappata in un dato instante su un unico nodo della rete La responsabilità di una chiave può spostarsi da un nodo allaltro quando i nodi si disconnettono. La gestione delle risorse associate alle chiavi è lasciata a protocolli di livello applicativo 0 1 3 2 4 5 6 7 Load balance Decentralization Scalability Availability La chiave k viene assegnata al primo nodo attivo il cui id è uguale o maggiore allidentificativo k della chiave. O(N) per il lookup Utilizzo di una tabella di Routing riduce fino a O(log(N)) il numero di nodi contattati in un lookup

7 Reti L-S 2005 Routing : Finger Table NotazioneDefinizione Finger[k].start.interval.node successor predecesor (n+2 k-1 ) mod 2 m, 1k m [finger[k].start,finger[k+1].start) first noden.finger[k].start the next node on the identifier circle finger[1].node the previous node on the identifier circle N80 80+2 3 80+2 2 80+2 1 80+2 4 80+2 5 80+2 0 L i-esima riga della finger table del nodo n contiene lidentificatore del nodo che lo segue di almeno 2 posizioni nellanello (i-1) Lidea è quindi quella di raddoppiare ad ogni passo la distanza a cui si cerca il nodo responsabile di una chiave. Ogni nodo ha una forte conoscenza dei nodi a lui vicini nell anello e una conoscenza sempre più vaga sui nodi distanti.

8 Reti L-S 2005 Multiple Node Join Ogni nodo esegue periodicamente un protocollo di stabilizzazione per mantenere aggiornato il proprio successore e predecessore La Multiple Join NON notifica al resto della rete lingresso del nodo n Stabilize() x = (finger[1].node).Find_Predecessor(); if ( x in [ n, finger[1].node ) finger[1].node = x; (finger[1].node).Notify(n); Chiede al suo successore, il predecessore Notifica al successore (eventualmente aggiornato) che n potrebbe essere il suo nuovo predecessore Se non cè predecessore (es. nodo in corso di join) o n è il nuovo predecessore, aggiorna linformazione Notify(n) if ( predecessor is null or n in [ predecessor, n ) predecessor = n; Se la rete non è stabilizzata, x potrebbe essere il nuovo successore. In tal caso aggiorna linformazione Algoritmo Utilizzato nel progetto

9 Reti L-S 2005 Lookup e fallimento di nodi Un lookup effettuato prima che la stabilizzazione abbia finito può terminare: 1) Correttamente: tutte le finger table sono ragionevolmente corrette nonostante il cambiamento dellanello 2) Correttamente ma dopo molto tempo: le finger tables sono inaccurate ma i nodi successori sono corretti. 3) Fallendo: lanello è in uno stato inconsistente al momento del lookup Gestione di fallimenti multipli Chord prevede che ogni nodo k mantenga anche una lista degli O (log(N)) successori. Se il nodo n si accorge che il suo successore è fallito, lo sostituisce con la prima entry valida nella sua lista dei successori. Ogni nodo è in grado di recuperare dal fallimento degli r-1 nodi a lui successivi

10 Reti L-S 2005 TCP – Implementazione ricorsiva La richiesta di lookup si propaga lungo il percorso di routing fino ad individuare il nodo responsabile della chiave. Ogni nodo esegue, se necessario, il forward della richiesta scegliendo il nodo più opportuno tra quelli presenti nella sua finger table. Una volta individuato il successore della chiave cercata, la risposta viene propagata in backward ?? lookup PROBLEMA Sia il nodo di origine, sia i nodi intermedi rimangono a lungo impegnati in attesa della risposta uso di meccanismi sincroni non bloccanti (?)

11 Reti L-S 2005 TCP – Implementazione iterativa La richiesta di lookup non si propaga. Il nodo che deve eseguire il lookup, contatta iterativamente nodi sempre più prossimi a quello responsabile della chiave. Lalgoritmo, a livello implementativo, cerca il predecessore più prossimo del nodo responsabile della chiave e, una volta individuato, lo interroga per conoscere il suo successore (cioè il nodo effettivamente cercato). Ogni nodo a cui viene domandato il predecessore della chiave, restituisce il nodo che, limitatamente alle informazioni in suo possesso, pensa che sia il predecessore. Lalgoritmo termina quando il predecessore restituito nP è tale per cui key appartiene allintervallo ( key, key.successor ] ?? successor predecessor

12 Reti L-S 2005 Acquisizione delle risorse Le risorse associate alle chiavi del nodo N, sono attualmente allocate sul successore di N N le richiede al suo successore non appena entra in rete Lazione di richiesta è a carico del nuovo nodo Il successore di N già dispone delle risorse replicate Non è garantita persistenza della informazioni se N e il suo successore dovessero andare in crash nello stesso momento Successore di N N Ipotesi di Single Fail

13 Reti L-S 2005 Replicazione Le risorse associate alle chiavi del nodo N, vengono replicate sul nuovo successore In caso di crash di N il nuovo successore è in grado di rispondere correttamente Nuovo successore N N Le risorse associate alle chiavi del nodo N1 sono ora di competenza di N (precedentemente replicate da N1 su N) N deve ora replicare le risorse associate alle nuove chiavi di sua competenza sul suo successore N1 Ipotesi di Single Fail

14 Reti L-S 2005 Conclusioni finali fornisce un esempio di applicazione di ricerca di informazioni su rete distribuita utilizza un protocollo di rete (CHORD) efficiente e robusto, trattando in particolare gli aspetti di scalabilità, bilanciamento di carico e disponibilità introduce un livello superiore al protocollo di rete per trattare la replicazione delle informazioni distribuite sui nodi Il progetto realizzato estensione del protocollo CHORD per gestire il recovery in caso di network partition miglioramento della replicazione, estendendola al caso di fallimento di più nodi consecutivi contemporaneamente ampliamento della interfaccia lato utente e della gestione delle informazioni sui singoli nodi Sviluppi futuri