Sistemi Peer to Peer Gennaro Cordasco Dipartimento di Informatica e Applicazioni Università degli Studi di Salerno cordasco[@]dia.unisa.it cordasco+p2p[@]gmail.com http://www.dia.unisa.it/~cordasco Laboratorio ISISLAB2 (DIA Piano 2) 11/01/2019

Materiale didattico i) Peer-to-Peer Systems and Applications Series: Lecture Notes in Computer Science , Vol. 3485 Sublibrary: Information Systems and Applications, incl. Internet/Web, and HCI www.peer-to-peer.info Steinmetz, Ralf; Wehrle, Klaus (Eds.) 2005, XVII, 629 p. With online files/update., Softcover ISBN: 978-3-540-29192-3 ii) Research papers (http://www.dia.unisa.it/~cordasco) iii) JXTA java Programmers guide (http://www.dia.unisa.it/~cordasco) iv) JXTA Protocol Specifications (http://www.dia.unisa.it/~cordasco) v) Le slide del corso (http://www.dia.unisa.it/~cordasco) … che ovviamente non sono sufficienti per superare l’esame!!! 11/01/2019

20/10 Chord (2a parte) + Consistent Hashing 27/10 Altre DHT + LB 13/10 DHT + Chord (1a parte) 20/10 Chord (2a parte) + Consistent Hashing 27/10 Altre DHT + LB 03/11 JXTA 10/11 JXTA 17/11 Esercitazioni (parte teorica) 24/11 ??? 1/12 Prova scritta 15/12 JXTA 22/12 ??? 11/01/2019

Le vostre domande Nessun pervenuto!!! 11/01/2019

Lezione 7 JXTA JXTA Programmers Guide v. 2.5 JXTA Protocol Specification v.2.0

JXTA: Cos’è? JXTA (JuXTAppose) è una piattaforma di rete, realizzata per lo sviluppo di applicazioni P2P. JXTA fornisce un insieme di “building block” necessari allo sviluppo di applicazioni P2P Obiettivo, cercare di standardizzare la maniera in cui i nodi (peer): Scoprono altri peer Si organizzano in peer groups Pubblicizzano e trovano risorse e/o servizi Comunicano con altri peer Si controllano l’uno con l’altro

JXTA: Cos’è? I protocolli JXTA sono indipendenti dai linguaggi di programmazione (esistono implementazioni in Java, c++, Perl, ecc.) e dai protocolli di trasporto (TCP, HTTP, Bluetooth ecc.). L’indipendenza del protocollo da linguaggi di programmazione e protocolli di trasporto permette lo sviluppo di applicazioni interoperabili JXTA permette pertanto di connettere svariati tipi di device (PDA, Server, cell phone, PC) in una rete virtuale nella quale tutti comunicano e collaborano alla pari.

JXTA: Architettura L’architettura di JXTA si può riassumere in tre livelli

JXTA: Architettura L’architettura di JXTA si può riassumere in tre livelli: Core Layer Definisce le primitive essenziali Creazione di peer e di gruppi Discovery Trasporto (pipe) Security Services Layer Definisce alcuni servizi di rete non strettamente necessari, ma tipicamente utilizzati in un ambiente P2P Storage system File sharing Distributed File systems Authentication Application Layer

JXTA: Componenti No DNS La rete JXTA consiste in una serie di nodi interconnessi (peers) identificati attraverso un ID. I peers sono di solito organizzati in gruppi (peer groups) per fornire un insieme comune di servizi (file sharing, chat, ecc.) Ogni peer pubblica i propri servizi attraverso file XML chiamati (advertisement). Ogni peer usa delle connessioni virtuali (pipes) per scambiare messaggi (messages) con altri peer. Una pipe è in generale un canale asincrono e unidirezionale che è legata a un endpoint (indirizzo IP + porta) I messaggi sono documenti XML contenenti vari tipi di informazioni.

JXTA: Peers Nel protocollo JXTA un peer è semplicemente un dispositivo che implementa almeno un protocollo JXTA (sensori, cellulare, PDA, PC, Server). Ogni peer, dispone di un unico ID, è indipendente ed opera in modo asincrono rispetto agli altri. dispone di almeno una interfaccia di rete (peer endpoint) utilizzata per stabilire connessioni uno a uno con altri peer. I peer sono di solito configurati in modo da trovare spontaneamente gli altri peer nella rete I peer non devono avere necessariamente una connessione diretta. Alcuni intermediari possono essere utilizzati durante le comunicazioni

Ma non spiega quando e perchè creare un gruppo!!!! JXTA: Peer groups Un peer group è un sottoinsieme di JXTA peer che si è accordato sull’utilizzo di uno specifico insieme di servizi Ogni peer group, dispone di un unico group ID, Stabilisce la politica di accesso al gruppo (gruppo aperto <--> gruppo protetto). Ogni peer può appartenere a più gruppi contemporaneamente ed in particolare tutti i peer appartengono al gruppo NetPeerGroup Il protocollo JXTA descrive come i peer Pubblicano un gruppo Trovano un gruppo Si connettono a un gruppo Possono monitorare un gruppo Ma non spiega quando e perchè creare un gruppo!!!!

JXTA: Peer groups (Why?) Sicurezza (ad esempio limitare l’accesso a peer non autorizzati). Monitoraggio (tutti i peer appartenenti a uno stesso gruppo possono essere monitorati per uno specifico scopo) Specializzazione (i peer appartengono allo stesso gruppo perché collaborano allo stesso progetto) File sharing group Collaborative group CPU sharing group

JXTA: Peer groups I gruppi formano una gerarchia, ogni gruppo ha un singolo gruppo padre (la radice è NetPeerGroup) Gli advertisement di un gruppo vengono inviati anche al gruppo padre. I servizi forniti da un gruppo sono Discovery service, utilizzato per scoprire risorse (peer, peer group, pipe, services) nel gruppo. Membership services, utilizzato dai membri del gruppo per autorizzare o meno operazioni di join al gruppo (autorizza tutti, tutti i membri decidono autonomamente, un sottoinsieme dei membri decide, si vota). Access services, alcuni servizi richiedono delle credenziali per essere utilizzati. Pipe services, per creare pipe fra due membri del gruppo Resolver services, utilizzato per richieste generiche fra peer (stato di un servizio…) Monitoring services, permettono a un peer di monitorare gli altri peer del gruppo. Non tutti i servizi vengono implementati in ogni gruppo. Quando un gruppo non definisce un servizio questo viene ereditato dal gruppo padre

JXTA: Network services I peer trovano in servizi di rete attraverso il protocollo PDP (Peer Discovery Protocol). I servizi possono essere preinstallati nel peer oppure scaricati dalla rete a runtime (come un plug-in). Esistono due tipi di servizi di rete: Peer service, il servizio è disponibile presso un solo peer (se il peer abbandona il sistema il servizio non è più disponibile). Più peer possono implementare lo stesso servizio ma ogni peer pubblicizza in maniera autonoma il proprio servizio. Peer Group Services, il servizio si compone di una serie di istanze (le quali possono anche cooperare) disponibili presso diversi peer dello stesso gruppo (se un peer cade il servizio rimane attivo). Il servizio è pubblicato come group advertisement.

JXTA: Modules Un modulo rappresenta l’astrazione di un pezzo di codice (classe java, jar, dll, files XML, script) I moduli sono utilizzati di solito per realizzare differenti implementazioni di uno specifico servizio su differenti piattaforme Quando un peer si connette a un gruppo potrebbe dover utilizzare i servizi specifici per il nuovo gruppo. Attraverso i moduli, i peer operanti su qualsiasi piattaforma sono in grado di implementare tali servizi.

JXTA: Modules Module abstraction: Module class: identifica per grandi linee il comportamento della classe; (Module class ID) Module specification: definisce la logica di un modulo. (Module spec ID contiene il Module class ID) Module implementation: L’implementazione di un module specification. Possono esserci diverse implementazioni di una determinata Module specification (Es. una per ogni piattaforma), tuttavia queste implementazioni devono essere tra loro compatibili. (Ogni implementazione indica il Module Spec ID implementato). Per ogni module class possono esserci più module specification (le quali non devono essere necessariamente compatibili) e per ogni module specification possono esserci più module implementation tra loro compatibili. Es (Discovery Service)

JXTA: Pipes JXTA utilizza le pipe per lo scambio di messaggi. Ogni pipe è asincrona, unidirezionale e inaffidabile (ad eccezione delle pipe sicure) Ogni pipe si lega di solito a due endpoint input pipe (o riceiving end) e output pipe (o sending end). La connessione di una pipe agli endpoint avviene a run time, di conseguenza una pipe si può legare (non contemporaneamente) a diversi endpoint. Pipes communication: Point to point pipes Propagate pipes Secure unicast pipes (Forniscono un servizio affidabile e sicuro)

JXTA: Pipes Pipes communication: Point to point: per ogni output endpoint c’è un solo input endpoint Propagate: come nel multicast il messaggio viene mandato a più peer contemporaneamente. I peer riceventi devono comunque appartenere allo stesso gruppo del peer che invia il messaggio

JXTA: Canali di comunicazione bidirezionali e affidabili Partendo dalle pipe JXTA definisce inoltre dei canali di comunicazione più affidabili: Reliable Library Assicura ordine dei messaggi Assicura che i messaggi arrivino a destinazione Espone interfacce per la realizzazione di messaggi e stream JXTA Socket e JXTAServerSocket (costruite usando le pipes e la reliable library) Sono bidirezionali e sicure Permette la suddivisione del messaggio in chunk e di configurare il buffering JXTA BiDiPipe e JXTAServerPipe (costruite usando le pipes e la reliable library) Non suddividono il messaggio in chunk (l’applicazione deve verificare che i messaggi non superino la dimensione massima). Utili per gestire stream di dati Utili per gestire messaggi

JXTA: Canali di comunicazione bidirezionali e affidabili JXTAServerSocket e JXTAServerPipe, espongono una input pipe alla quale un peer può connettersi per negoziare una connessione, dopodichè JxtaSocket e JxtaBiDiPipe si legano ai loro rispettivi canali creando una connessione privata e indipendente dalla connessione utilizzata per richiedere il canale.

JXTA: Messaggi Un messaggio è l’unità di base per la comunicazione fra peer. Il messaggio è di solito una serie di coppie chiave/valore. Tipicamente i messaggi sono inviati attraverso le pipe. Ogni piattaforma definisce come i messaggi possono essere convertiti da/a strutture dati native. Vi sono diverse rappresentazioni dei messaggi (XML, binary). Inoltre dati binari possono essere incapsulati nel body di un documento XML. Perché XML? Versatile Permette a ogni peer di identificare facilmente i dati di cui ha bisogno e/o di scartare le informazioni che non può processare.

JXTA: Advertisement Il protocollo JXTA utilizza gli advertisement per descrivere e divulgare informazioni relative ai servizi messi a disposizione. Tali informazioni sono di solito contenute in un file XML Ogni advertisement ha una scadenza (ciò permette ai peer di mantenere aggiornata la propria cache, senza un controllo centralizzato). Ovviamente un advertisement può essere ripubblicato in modo da posporre la scadenza di un un vecchio advertisement.

JXTA: Advertisement Esistono vari tipi di advertisement Peer advertisement (name, peerID, available endpoint, rendezvous) Peer group advertisement (name, peergroupID, description…) Pipe advertisement (pipeID, pipe type) Module Class advertisement Module Implementation advertisement Rendezvous advertisement Peer Info advertisement

JXTA: Advertisement

JXTA: Security Ovviamente le applicazione che si appoggiano sul protocollo JXTA avranno bisogno di un minimo di sicurezza. In JXTA ogni peer opera con l’autorità fornitagli da un altro peer (fidato) nel sistema. Requisiti di base: Confidentiality (il contenuto del messaggio è disponibile solo per utenti autorizzati) Authentication (garantisce l’identità del sender) Authorization (autorizza un peer a inviare un messaggio) Data integrity (garantisce che il messaggio non è stato modificato in transito) Refutability

JXTA: Security I messaggi XML possono essere ampliati con ulteriori informazioni (certificati, credenziali, digests, chiavi pubbliche ecc.) I messaggi possono inoltre essere cifrati (usando chiavi pubbliche) e firmati (usando certificati) Requisiti di base: Confidentiality (cifratura) Authentication (credenziali) Authorization (credenziali) Data integrity (digests) Refutability (firma)

JXTA: ID Tutte le risorse in JXTA vengono identificate attraverso un identificatore unico. ID utilizzate per Peer Peer group Pipe Contents Module classes Module specification URNs (uniform resource name) sono utilizzate per rappresentare JXTA ID Le ID vengono di solito generate in maniera casuale Esistono due ID riservate una per Net Peer Group e una è Null ID

JXTA: Network architecture La rete JXTA è una rete ad-hoc, adattiva e multi- hop composta dai peer connessi alla rete. Le connessioni fra i peer sono dinamiche e di conseguenza il routing non è deterministico (I peer possono in ogni momento entrare ed uscire dal sistema, pertanto l’instradamento dei messaggi cambia frequentemente). Il protocollo JXTA non definisce l’organizzazione della rete (topologia)

JXTA: Network architecture Esistono quattro tipi di peer: Minimal edge peer: usato per device con limitate performance può inviare e ricevere messaggi non mantiene informazioni su advertisement noti non instrada messaggi Edge peer (Full featured edge peer): la maggior parte dei peer fa parte di questa categoria mantiene informazioni su advertisement noti, di conseguenza risponde a messaggi di discovery, fornendo le informazioni nella propria cache. Rendezvous peer: Relay peer:

JXTA: Network architecture Rendezvous peer: può inviare e ricevere messaggi mantiene informazioni su advertisement noti, di conseguenza risponde a messaggi di discovery, fornendo le informazioni nella propria cache. instrada messaggi di discovery per favorire l’operazioni di discovery di altri peer. mantiene una lista di altri rendezvous e una lista dei nodi che lo usano come rendezvous. Esiste almeno un rendezvous peer per ogni gruppo. Gli edge peer inviano le richieste di discovery al proprio rendezvous peer, il quale, se non ha informazioni, inoltra la richiesta a un altro rendezvous peer e così via finchè non si trova la risorsa oppure scade il TTL (time to live) del messaggio. I cicli vengono evitati mantenendo una lista dei peer che la path ha già attraversato. Relay peer:

JXTA: Network architecture Relay peer: può inviare e ricevere messaggi mantiene informazioni su advertisement noti, di conseguenza risponde a messaggi di discovery, fornendo le informazioni nella propria cache. mantiene una sorta di tabella di routing e permette l’instradamento dei messaggi ai peer. Quando un peer deve instradare un messaggio, esso verifica se ha nella propria cache informazioni sulla rotta. Nel caso queste informazioni non sono disponibili, il peer richiede tali informazioni a un relay peer. I relay peer si occupano anche di inoltrare i messaggi per conto dei peer che non hanno connessione diretta ad altri peer (NAT) Tutti peer possono implementare i servizi di Relay e RendezVous anche contemporaneamente

Una sorta di DHT su una rete non strutturata JXTA: SRDI Il protocollo JXTA 2.0 supporta un meccanismo shared resource distributed index (SRDI) che permette di migliorare l’efficienza delle query. I rendezvous peer mantengono l’indice degli advertisement pubblicati dai propri edge peer. Infatti quando un peer pubblica un advertisement esso invia l’indice dell’advertisement ai propri rendezvous peers. In questo modo le query si propagano solo attraverso rendezvous peer rendendo molto più veloce il discovery dei servizi. Solo l’indice dell’advertisement vengono mantenuti dai nodi rendezvous, pertanto non c’è un eccessivo speco di spazio. Quando un rendezvous riceve un indice esso inoltra tale indice ad alcuni dei rendezvous da lui conosciuti (si utilizza una funzione hash). I rendezvous peer mantengono una lista di altri nodi rendezvous. Per mantenere tale lista sempre aggiornata essi si scambiano continuamente informazioni su rendezvous conosciuti e cancellano le entry relative ai rendezvous che non rispondono. Una sorta di DHT su una rete non strutturata

JXTA: Queries Il peer A (edge) usa il peer R1 come rendezvous… il peer R1 conosce altri rendezvous R2 e R3. Quando il peer A inizia il discovery, la richiesta viene inviata in broadcast sulla sottorete del peer A e al peer R1, dopodichè il peer rendezvous R1 inoltra il messaggio ai rendezvous R2 e R3. I vari rendezvous che utilizzano il servizio SDRI, verificano se la richiesta riguarda uno dei propri edge peer e in caso positivo inoltrano la richiesta a tali peer (essi risponderanno direttamente al nodo che ha generato la query) e bloccano la query.

JXTA: SRDI

JXTA: Firewall e NAT Un peer all’esterno di un firewall non è in grado di contattare un nodo all’interno del firewall. Per permettere la comunicazione di peer attraverso firewalls è necessario che: Almeno un peer interno al firewall conosce almeno un peer esterno al firewall; Tali peer supportano il protocollo http; Il firewall permette il traffico http;

JXTA: Firewall e NAT

Grazie per l’attenzione 11/01/2019