Progettazione di un protocollo P2P per la comunicazione basata su predicati

Candidato: Daniele Spaccapeli

Relatore: Michele Loreti

Comunicazione

Tipologie di routing più comuni:

  • Unicast
  • Broadcast
  • Multicast

i messaggi sono indirizzati in maniera specifica ai destinatari

Comunicazione basata su predicati

gruppo di destinatari è individuato dinamicamente in base alla valutazione di un predicato logico

  • astrazione per trattare di complessi sistemi adattivi (CAS)
  • i nodi non devono essere coscienti della presenza reciproca
  • adatto in contesti altamente dinamici 

Architettura Reti

Modello Client-Server

Modello Peer-to-Peer

  • Relativa semplicità di sviluppo
  • Sicurezza
  • Flessibilità di aggiornamento
  • Riduzione dei costi
  • Scalabilità
  • Assenza del punto critico
  • Costo
  • Congestione traffico
  • Collo di bottiglia

Hash Table Distribuita (DHT)

P2P di seconda generazione

  • Ricerca (chiave, valore)
  • Hashing consistente
  • Lista dei nodi vicini

Esempi: BitTorrent, YaCy, CDN, Chord, Kademlia ...

Framework

Funzionalità generiche che facilitano lo sviluppo software 

Framework P2P studiati:

  • JXTA
  • XNap
  • Pastry

Framework - Confronto

Documentazione Reperibilità Semplicità
JXTA ✓
XNap ✓ ✓
Pastry ✓ ✓ ✓

Vediamo Pastry in dettaglio ...

Pastry - Introduzione

sviluppato dalla Rice University e Microsoft Research

Caratteristiche:

  • identificativi a 128 bit
  • routing del messaggio al nodo più vicino alla chiave
  • ogni nodo mantiene un leaf set
  • ogni nodo mantiene una tabella di routing

Pastry - Routing

  • ID scelti con probabilità uniforme
  • contiene indirizzi IP
  • 32 righe e 16 colonne
  • gli elementi in riga n condividono le prime n cifre
O(log_{16}{N})
O(log16N)O(log_{16}{N})

Numero di salti per ricezione:

Pastry - Esempio

Protocollo P2P per la comunicazione basata su predicati

basato su Pastry, costruito espandendo le primitive per supportare la comunicazione su predicati

  • i messaggi sono scambiati a seconda degli attributi (servizi) offerti dal nodo
  • propagazione dei messaggi basato su alberi multicast
  • ogni agente manterrà una lista di tutti gli attributi presenti nella rete
  • gli attributi si dividono in federazioni e ognuna di esse avrà un super-nodo responsabile della comunicazio

Protocollo - Definizioni

Albero Multicast

  • trasmissione unidirezionale
  • traffico dalla radice alle foglie
  • filtrato a seconda dei predicati

Formato dei predicati

\bigwedge_{j=1}^n \left( \bigvee_{k=1+j}^{m(j)} L_{j,k-j} \right)
⋀j=1n(⋁k=1+jm(j)Lj,k−j)\bigwedge_{j=1}^n \left( \bigvee_{k=1+j}^{m(j)} L_{j,k-j} \right)

Forma normale congiuntiva, massima espressività, parsing semplice

Federazioni

Hashing

Partizioni delle formule possibili. Le formule in due partizioni diverse sono indipendenti tra loro 

\forall \;\; \mathit{F}_i, \mathit{F}_j \;\; con \;\; (i\neq j)
∀Fi,Fjcon(i≠j)\forall \;\; \mathit{F}_i, \mathit{F}_j \;\; con \;\; (i\neq j)
\forall \;\; \varphi \in \mathit{F}_i, \;\; \forall \;\; \psi \in \mathit{F}_j
∀φ∈Fi,∀ψ∈Fj\forall \;\; \varphi \in \mathit{F}_i, \;\; \forall \;\; \psi \in \mathit{F}_j
\varphi \;\; indipendente \;\; da \;\; \psi
φindipendentedaψ\varphi \;\; indipendente \;\; da \;\; \psi

Ogni attributo e formula appartenente a una stessa federazione indurrà codifica univoca

h_{\mathscr{F}}(\varphi) = id, \; \; \;\forall \varphi \subset \mathscr{F}
hF(φ)=id,∀φ⊂Fh_{\mathscr{F}}(\varphi) = id, \; \; \;\forall \varphi \subset \mathscr{F}

Protocollo - Fase Iniziale

Bootstrapping

operazioni di handshake:

  • recupero attributi
  • recupero funzione hash

Advertising

dopo n ingressi un messaggio circolare per iniziare la creazione degli alberi multicast

Impostazione degli attributi

per ogni federazione i nodi faranno sapere al proprio padre dell'albero multicast, i valori dei propri attributi

Protocollo - Fase Principale

Invio dei messaggi

  • tramite operazione di send
  • invio al RP (caching)
  • inoltro a cascata dei messaggi

Protocollo - Post Sequenza Principale

Nuovi arrivi

Cambio di valori

Malfunzionamenti

  • contatto col nodo/i di bootstrap
  • inizio immediato Advertising
  • perdita efficienza per un gran numero di ingressi
  • nuova impostazione degli attributi
  • aggiornamento al padre
  • se necessario catena di aggiornamenti
  • messaggi di keep-alive per verificare l'integrità
  • Due scenari possibili

Protocollo - API

/**
 * Comunica il valore di verità di un attributo (positivo) al padre del 
 * nodo all’interno dell’albero multicast.
 *
 * @param  attributo           l'attributo da modificare
 * @param  valore_booleano     valore - True, False per effettuare un unsubscribe
 * @return                     True se l'operazione ha avuto successo, False altrimenti
 */
Bool set(Attribute attributo, Bool valore_booleano){...};

/**
 * Comunica il valore di verità di un attributo (negativo) al padre del 
 * nodo all’interno dell’albero multicast.
 *
 * @param  attributo           l'attributo da modificare
 * @param  valore_booleano     valore - True, False per effettuare un unsubscribe
 * @return                     True se l'operazione ha avuto successo, False altrimenti
 */
Bool unset(Attribute attributo, Bool valore_booleano){...};

/**
 * Serve per effettuare lo scambio di messaggi.
 *
 * @param  messaggio           messaggio da inviare
 * @param  formula_logica      predicato logico per l'invio
 * @return                     True se l'operazione ha avuto successo, False altrimenti
 */
Bool send(String messaggio, CNF formula_logica){...};

/**
 * Utilizzato dall’agente per recuperare i messaggi ricevuti. I messaggi ricevuti potranno 
 * essere letti in maniera asincrona e verranno tutti memorizzati in una coda.
 *
 * @return                     Restituisce una lista di Stringhe, al primo posto il messaggio e al secondo 
 *                             la stringa che identifica la federazione da cui il messaggio proviene.
 */
String[] receive(){...};

Conclusione

In sistemi composti da un gran numero di agenti la topologia dell rete è vitale

È altrettanto importante un instradamento dei messaggi efficiente che non provochi overhead

Il risultato è un protocollo efficiente che permette  l'interazione dinamica in reti con churn modesto; corredato da un tipo di comunicazione molto versatile

Miglioramenti

Caching

Load-Balancing

Sicurezza

sfruttando le proprietà di Pastry pensiamo a una possibile replicazione delle strutture dati nei nodi adiacenti ai RP e nodi di bootstrap

il meccanismo di caching può essere sfruttato per alleggerire il carico di lavoro dei RP, dato che molti messaggi passano per i nodi del leaf set

il protocollo presume che gli agenti collaborino tra di loro; si può pensare di introdurre un meccanismo di reputazione

Simulazione

un analisi completa del protocollo necessiterebbe strumenti ad hoc

Grazie dell'attenzione

Tesi di Laurea Triennale

By Daniele Spaccapeli

Source: mauroch

Tesi di Laurea Triennale

presentazione della tesi salvata dall'alt account

  • 1,123

More from Daniele Spaccapeli