Click here to load reader
Upload
donatella-novelli
View
240
Download
0
Embed Size (px)
Citation preview
JaCOP Just another Community Organization Protocol
JaCOPIl punto di partenza
Una comunità/rete di pari è così detta perché costituita da nodi che possono agire contemporaneamente da clienti e da servitori
Introduzione
Il fatto che il numero di potenziali servitori sia pari al numero dei nodi conferisce ai servizi p2p di un alto livello di disponibilità
Il meccanismo che permette ai nodi di conoscersi tuttavia è di tipo C/S con server centralizzato
Questo significa che la caduta del server ha come effetto al disgregazione dell’intera comunità
JaCOPPossibili soluzioni
Se ne possono individuare rapidamente due:
Introduzione
ha un costo contenuto mantiene centralizzato il controllo della comunità un evento imprevisto potrebbe isolare la sottorete su cui si trovano i server
1. Replicazione del server
privo di server centralizzati robusto scalabile
2. Intervento sul meccanismo di definizione della comunità
In modo da renderlo:
E’ stata percorsa la seconda strada (... anche perché più interessante)
JaCOP Introduzione
massimo numero di connessioni (n*(n-1))... ma massima robustezza
connessioni dirette tra ogni coppia di nodi
Soluzione 1
JaCOP Introduzione
massimo numero di connessioni (n*(n-1)).. ma massima robustezza
connessioni dirette tra ogni coppia di nodi
Soluzione 1
minimo numero di connessioni (n-1)... ma minima robustezza (la rete resiste alla caduta di un solo nodo)
ogni nodo è connesso solo ad un’altro
Soluzione 2
JaCOP Introduzione
massimo numero di connessioni (n*(n-1)).. ma massima robustezza
rete punto a punto
Soluzione 1
minimo numero di connessioni (n-1)... ma minima robustezza (la rete resiste alla caduta di un solo nodo)
ogni nodo è connesso solo ad un’altro
Soluzione 2
rete resistente alla caduta di k nodi (k si dice grado di coesione)
Soluzione 3
è un buon compromesso richiede che tra ogni coppia di nodi esistano almeno k cammini distinti che li congiungono
è stata perseguita la terza soluzione
JaCOP Gli algoritmi – A1
i nodi si aggiungono uno ad uno mediante un’operazione detta “join” (giunzione) ogni nodo può fare da server per un join (punto di giunzione) quando un nodo effettua un join viene messo a conoscenza da parte del server di alcuni dei suoi vicini
Idee base
il primo passo è stato definire un algoritmo per la costruzione di una rete con le proprietà desiderate
A1 (algoritmo di costruzione)Durante una giunzione il servant passa all’altro nodo k-1 suoi vicini scelti a caso
si può dimostrare che una rete costruita con A1 ha grado di coesione k
k = 2
JaCOP Gli algoritmi – A1
StrutturaL’insieme dei nodi ottenuti durante una operazione di join, più il punto di giunzione, si dicono “struttura” del nodo che effettua la giunzione.
Relazione di dipendenza
La relazione di dipendenza definisce sulla rete un ordine parziale
la chiave del funzionamento di A1 è che grazie ad esso ogni nodo ha almeno k legami con la rete indipendente
Sa a è di struttura per b si scrive: a S b
Si dice che a “dipende da” b, e si scrive:a bse b S a o c1, ...cn tali che b S cn, ... c1 S a
Rispetto ad un nodo la rete si può dividere in due porzioni “dipendente” ed “indipendente”
k = 2
JaCOP Gli algoritmi – A3
che sia visitabile che lo sia in modo efficiente
Osservazione
Perché una rete costruta con A1 possa essere di qualche utilità occorre:
A3 (algoritmo di esplorazione)Per ogni nodo sia BL(n) l’insieme dei nodi ad esso giuntati e FL(n) il punto di giunzione
A3 sfrutta questo fatto per esplorare in modo efficiente la rete
k = 2
L’insieme dei legami tra nodi e rispettivo punto di giunzione definisce uno spanning tree sulla rete
A partire da un nodo n si esplora prima BL(n) e poi FL(n).
Ad ogni passo il nodo di provenienza è sempre escluso dall’esplorazione
JaCOP Gli algoritmi – A2
se il nodo non è di struttura non si fa nulla se è di struttura si effettua una nuova operazione di join al punto di giunzione corrente
Non è sufficiente che un rete possa sostenere senza partizionarsi la caduta di k nodi
A2 (algoritmo di ristrutturazione)Si distinguono due sottocasi:
k = 2
Caso A: il nodo caduto non è il punto di giunzione (re-join)
Occorre che essa sia riorganizzata in modo che anche dopo la caduta per ogni nodo esistano k legami con la porzione di rete da esso indipendente
JaCOP Gli algoritmi – A2
il punto di giunzione sceglie tra i propri vicini un pool di candidati da utilizzare come nuova struttura
Il pool è calcolato mediante un algoritmo di programmazione dinamica che suppone: k = 2
i nodi che fanno parte della sua struttura corrente (che vengono così riciclati) nodi scelti dal pool, fino ad arrivare al numero di k-1
Al nodo che effettua il join sono passati:
che tutti i nodi di struttura di un dato nodo siano vicini del punto di giunzione che il punto di giunzione conosca la struttura di tutti i suoi vicini
I nodi candidati devono essere indipendenti dal nodo che effettua il re-join
JaCOP Gli algoritmi – A2
Caso B: il nodo caduto è il punto di giunzione (new-join)
k = 2
il nodo sceglie uno dei suoi vicini di struttura ed effettua verso di esso un nuova operazione di join tutto procede come nel caso precendente, ma i nodi della struttura corrente vengono riciclati solo se compaiono nel pool dei
candidati
questo è necessario perché rimangano soddisfatte le condizioni per il funzionamento
dell’algoritmo che elabora il pool
JaCOP Gli algoritmi – Variante del modello
1
4
0.75
2Come fattore di carico si è scelto:
k = 2
assegnado ad ogni nodo un fattore di carico introducendo la possibilità di delegare una richiesta di join
Per evitare di caricare troppo dei nodi può essere utile cercare di bilancare la rete
Variante
Questo può essere fatto:
DelegaSe il nodo che riceve una richiesta di join ha un vicino meno carico delega la richiesta al vicino con carico minore
Fattore di carico
L(n) = #conn/C(n)
Dove C(n) è la capacità del nodo
C = 2
C = 1
C = 4
C = 1
max numero di deleghe = 1
Dal pool dei candidati si scelgono i nodi con carico minore
JaCOP Il protocollo – introduzione
la rete è fornita di un meccanismo di identificazione dei nodi i pacchetti non vengono perduti e sono consegnati in ordine
Il protocollo sviluppato è a livello applicativo
Note introduttive
Suppone l’esistenza di una rete sottostante, su cui si fanno le seguenti assunzioni:
Il set TCP + IP soddisfa queste ipotesi, il set UDP + IP solo la prima
Per ottenere portabilità i pacchetti sono in formato XML
<?xml version="1.0" encoding="UTF-8"?><joinRequest> <community>comunità</community> <senderLoadFactor>1.2</senderLoadFactor> <receiverLoadFactor>0.75</receiverLoadFactor> <receiverIsStructure/> <node> <address>192.168.30.17</address> <port>3330</port> <loadFactor>1.2</loadFactor> </node> <force/> <nodeList> <node> <address>192.168.30.16</address> <port>3330</port> <loadFactor>1</loadFactor> <structure/> </node> <node> <address>192.168.30.15</address> <port>3330</port> <loadFactor>0.2</loadFactor> </node> </nodeList></joinRequest>
Per ragioni di chiarezza il protocollo è stato suddiviso in sottoprotocolli
JaCOP Il protocollo – introduzione
Note introduttive
Ogni nodo mantiene le seguenti strutture dati: F(n) = insieme dei vicini FL(n) = punto di giunzione BL(n) = vicini per cui il nodo corrente è punto di giunzione S(n) = struttura S(n, a) = vicini che fanno parte della struttura di un altro vicino FL(a) = punto di giunzione dei vicini dipendenti
Per ognuno dei sottoprotocolli descritti valgono le seguenti affermazioni: su ogni nodo può essere in esecuzione una sola conversazione alla volta si considerano prioritarie le conversazioni attivate da richieste provenienti da nodi indipendenti una conversazione non prioritaria può essere interrotta da una conversazione prioritaria, ma non viceversa una conversazione non prioritaria non può essere interrotta da una conversazione non prioriatria
JaCOP Il protocollo – P1
E’ innescato dall’invio/arrivo di un pacchetto “richiesta di join”
P1 (protocollo di join)
k = 2
join request [client, S(client), flag force]
client servant
Il servant determina il pool dei candidati, quindi sceglie la nuova struttura; i nodi di struttura esistenti vengono riciclati solo se compaiono nel pool
newStructure[ {chosen nodes}, connectionRank ]
servant client
Nessun nodo può rispondere ad una richiesta di join se la sua struttura non è “completa”
JaCOP Il protocollo – P1
Il servant quindi informa i nodi scelti del nuovo vicino e della sua struttura
k = 2
newNeighbor [ client, { client structure } ]
client ch. node
ok[ ]
ch.node client
i vicini rispondono con una conferma, ma non modificano il proprio stato
Il server ricalcola il pool dei nodi di struttura e controlla che la struttura passata sia ancora valida
Questo è necessario perché richieste di join in esecuzione su altri nodi potrebbero alterare le dipendenze
JaCOP Il protocollo – P1
Se i nodi scelti sono ancora validi il servant invia ad essi ed al client dei messaggi di conferma
k = 2
ok [ ]
servant ch.node
ok [ ]
servant client
Il client aggiunge i nuovi nodi, inizia a monitorarli ed elimina quelli della vecchia struttura che non sono stati riciclati
Il servant e i nodi scelti aggiungono il nuovo vicino ed iniziano a monitorarlo; memorizzano la sua struttura
JaCOP Il protocollo – P1
k = 2faultNotification [{ not recycl. nd }]
client joined nd.
Il client rimuove tutti i vicini il cui punto di giunzione è tra i nodi di struttura non riciclati
Il client invia ai nodi ad esso giuntati un messaggio che indica di rimuovere i nodi di struttura non riciclati
questo è necessario perché esiste una “finestra” di tempo in cui i nodi di struttura che saranno scartati possono passare il
nodo corrente a nodi giuntati
in questo modo la struttura dei nodi giuntati rimane costituita da vicini del punto di
giunzione
JaCOP Il protocollo – P2
Tramite questo protocollo un nodo viene notificato della presenza di un nuovo vicino dipendente
P2 (notifica nuovi vicini)
k = 2
newNeighbor [ node, { node structure } ]
client servant
dopo il secondo “ok” il servant aggiunge il vicino, ed aggiorna la struttura condivisa S(servant, node), memorizza il punto di giunzione del nuovo nodo
ok [ ]
client servant
Del nuovo vicino viene indicata anche la struttura
ok [ ]
client servant
JaCOP Il protocollo – P3
Indica ad un nodo di rimuovere alcuni dei suoi vicini (perché parte della struttura non riciclata del punto di giunzione)
P3 (notifica di eliminazione)
k = 2
fault notification [ { fallen nodes } ]
client servant
il servant: rimuove i vicini indicati rimuove tutti i vicini dipendenti il cui punto di giunzione è tra i nodi eliminati invia ai nodi ad esso giuntati un messaggio che indica di rimuovere i nodi da esso eliminati
fault notification [ { deleted nodes } ]
servant joined nd.
JaCOP Il protocollo – P4
E’ innescato dalla caduta di un vicino di struttura. Si distiguono due casi:
P4 (riorganizzazione)
k = 2
1) il nodo caduto non era il punto di giunzione
>> si effettua una nuova operazione di join verso lo stesso punto di giunzione (re-join)
2) il nodo caduto era il punto di giunzione
>> si sceglie un nuovo punto di giunzione tra i vicini di struttura e si effettua una nuova operazione di join (new-join)
JaCOP Il protocollo – P5
Permette di conoscere lo stato dei vicini, in particolare:
P5 (monitoraggio)
k = 2
se sono attivi o meno il loro fattore di carico
A intervalli regolari ogni nodo emette dei messaggi di heartbeat, cui il ricevente risponde (se il mittente non è riconosciuto come vicino non vi è alcuna risposta)
heartbeat [ ]
client servant
heartbeat [ ]
client servant
una mancata risposta indica che il nodo non è attivo tra le informazioni sul mittente trasmesse c’è il suo fattore di carico
JaCOP Implementazione - Introduzione
Caratteristiche dell’applicazione>> E’ stata realizzata in Java
è più leggero di TCP ma non garantisce la consegna dei pacchetti, né il loro arrivo in ordine
>> Come protocollo di base è stato scelto UDP
>> Per questo è stato necessario introdurre un framework che rimediasse alla mancanza
Struttura a livelli
FRAMEWORK
PA A3 TEST
Alla base c’è il framework descritto
Sfruttando le sue funzionalità sono stati costruiti:
una applicazione che implementa il protocollo come servizio (attuatore di protocollo) una seconda applicazione per il test dell’algoritmo A3
JaCOP
Caratteristiche del framework
Il framework sviluppato: gestisce la ritrasmissione e la consegna in ordine dei pacchetti definisce il concetto di conversazione è realizzato come un sistema ad eventi il nocciolo dell’architettura è il seguente:
Implementazione - Framework
scambio di pacchetti tra due o più nodi
>> è avviata dal nodo che invia il primo pacchetto>> vi partecipano tutti i nodi che rispondono ad un pacchetto che ne fa parte
Conversazione:
JaCOP
Il receiver e il transmitter sono implementati come thread l’InGate utilizza una socket per ricevere pacchetti, l’Unmarshaller ne permette la decodifica Il Receiver attende costantemente l’arrivo di pacchetti quando ne arriva uno innesca un evento e lo inserisce nel Dispatchter, costituito da una collezione di mailbox associate ciascuna ad una conversazione
Implementazione - Framework
i pacchetti da inviare vengono inseriti in una coda FIFO (OutQueue) il Transmitter preleva pacchetti dalla coda l’OutGate permette il loro invio su una socket, previa codifica effettuata dal Marshaller
JaCOP
i moduli principali dell’attuatore si basano sul ConversationFramework il modulo JaCOP Actuator implementa il protocollo JaCOP l’Heartbeat System esegue il protocollo di heartbeat il modulo Node Status mantiene informazioni sullo stato del nodo L’interfaccia utente può intervenire sull’attuatore di protocollo per innescare una giunzione o sul modulo Node Status per avere informazioni
Implementazione – Protocol Actuator
Architettura dell’attuatore di protocollo
Si è scelto di descrivere l’attuatore di protocollo per componenti, a causa della sua complessità
JaCOP
la classe ControlSystem fa da facciata e mentiene un registro dei trhead in esecuzione la classe SystemSemaphore implementa un semaforo binario che dà la precedenza ai thread prioritari il vincolo che un nodo non possa rispondere a richieste di giunzione se non ha stuttura integra è implementato mediante una variabile condizione
Implementazione – Protocol Actuator
Funzionamento dell’attuatore di protocollo
La ricezione di un messaggio di richiesta, di uno di notifica o una richiesta di giunzione da parte dell’utente causano l’attivazione di un thread che gestisce la conversazione
Per ogni sottoprotocollo dunque esistono in generale due tipi di thread: “client” e “server”
Il rispetto del corretto ordine di esecuzione è affidato ad un apposito sistema di controllo
JaCOP
la definizione di algoritmi per la costruzione di una rete connessa con grado di coesione arbitrario, per la sua ristrutturazione e per la sua esplorazione la specifica di un insieme i protocolli per realizzare e mantenere dinamicamente queste reti in un ambiente distribuito una implementazione del protocollo basata su reti UDP/IP e su un framework per la gestione delle conversazioni
Conclusioni e sviluppi futuri
ConclusioniGli aspetti salienti del lavoro svolto sono stati:
migliorare il protocollo aumentandone l’efficienza risoluzione di alcuni problemi (problema del partizionamento, bottleneck dello spanning tree in A3) l’implementazione di politiche per l’accesso alle comunità aggiungere sicurezza alle comunicazione, ad esempio cifrandone i contenuti trovare modalità efficienti per l’individuazione di nodi o contenuti specifici sulla rete
Sviluppi futuriAlcuni sviluppi futuri possono essere: