Lezione 6Lezione 6

JXTAJXTA

JXTA Programmers Guide v. 2.5JXTA Programmers Guide v. 2.5

JXTA Protocol Specification v.2.0JXTA Protocol Specification v.2.0

JXTA: Cos’è?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 P2PObiettivo, 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’è?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 interoperabiliJXTA 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: ArchitetturaJXTA: ArchitetturaL’architettura di JXTA si può riassumere in tre livelli

JXTA: ArchitetturaJXTA: ArchitetturaL’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 P2PStorage system

File sharing

Distributed File systems

Authentication

Application Layer

JXTA: ComponentiJXTA: ComponentiLa 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.

No DNSNo DNS

JXTA: PeersJXTA: PeersNel 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 I peer non devono avere necessariamente una connessione necessariamente una connessione diretta. Alcuni intermediari possono diretta. Alcuni intermediari possono

essere utilizzati durante le essere utilizzati durante le comunicazionicomunicazioni

JXTA: Peer groupsJXTA: Peer groupsUn 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 contemporaneamente 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 Ma non spiega quando e perchè creare un gruppo!!!!perchè creare un gruppo!!!!

JXTA: Peer groups (Why?)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 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 Non tutti i servizi vengono implementati in ogni gruppo. implementati in ogni gruppo.

Quando un gruppo non definisce Quando un gruppo non definisce un servizio questo viene ereditato un servizio questo viene ereditato

dal gruppo padredal gruppo padre

JXTA: Network services 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 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 effettua 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 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: 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 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 I peer riceventi devono comunque appartenere comunque appartenere allo stesso gruppo del allo stesso gruppo del

peer che invia il peer che invia il messaggiomessaggio

JXTA: Canali di comunicazione JXTA: Canali di comunicazione bidirezionali e affidabilibidirezionali e affidabili

Partendo dalle pipe JXTA definisce inoltre dei canali di comunicazione più affidabili:

Reliable LibraryAssicura ordine dei messaggiAssicura che i messaggi arrivino a destinazioneEspone interfacce per la realizzazione di messaggi e stream

JXTA Socket e JXTAServerSocket (costruite usando le pipes e la reliable library)

Sono bidirezionali e sicurePermette la suddivisione del messaggio in chunk e di configurare il buffering

JXTA BiDiPipe e JXTAServerPipe (costruite usando le pipes e la reliable library)

Sono bidirezionali e sicureNon suddividono il messaggio in chunk (l’applicazione deve verificare che i messaggi non superino la dimensione massima).

Utili per gestire Utili per gestire stream di datistream di dati

Utili per gestire Utili per gestire messaggimessaggi

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: Canali di comunicazione JXTA: Canali di comunicazione bidirezionali e affidabilibidirezionali e affidabili

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: MessaggiJXTA: Messaggi

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: AdvertisementJXTA: 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: AdvertisementJXTA: Advertisement

JXTA: AdvertisementJXTA: Advertisement

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: SecurityJXTA: 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: SecurityJXTA: Security

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: IDJXTA: ID

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 architectureJXTA: 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 può inviare e ricevere messaggi mantiene informazioni su advertisement noti, di conseguenza risponde a messaggi di discovery, fornendo le informazioni nella propria cache. non instrada messaggi

Rendezvous peer: Relay peer:

JXTA: Network architectureJXTA: Network architecture

Rendezvous peer:può inviare e ricevere messaggimantiene 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 architectureJXTA: 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)

JXTA: Network architectureJXTA: Network architectureTutti peer possono Tutti peer possono

implementare i servizi implementare i servizi di Relay e RendezVous di Relay e RendezVous

anche anche contemporaneamentecontemporaneamente

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.

JXTA: SRDIJXTA: SRDI

Una sorta di DHT su Una sorta di DHT su una rete non strutturatauna rete non strutturata

JXTA: QueriesJXTA: Queries

Il peer A (edge) usa il peer R1 come rendezvous… il peer R1 conosce altri Il peer A (edge) usa il peer R1 come rendezvous… il peer R1 conosce altri rendezvous R2 e R3.rendezvous R2 e R3.

Quando il peer A inizia il discovery, la richiesta viene inviata in broadcast sulla 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 sottorete del peer A e al peer R1, dopodichè il peer rendezvous R1 inoltra il messaggio ai rendezvous R2 e R3. messaggio ai rendezvous R2 e R3.

I vari rendezvous che utilizzano il servizio SDRI, verificano se la richiesta 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 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) tali peer (essi risponderanno direttamente al nodo che ha generato la query) e bloccano la query.e bloccano la query.

JXTA: SRDIJXTA: SRDI

JXTA: Firewall e NATJXTA: Firewall e NAT

Un peer all’esterno di un firewall non è in Un peer all’esterno di un firewall non è in grado di contattare un nodo all’interno del grado di contattare un nodo all’interno del firewall.firewall. Per permettere la comunicazione di peer Per permettere la comunicazione di peer

attraverso firewalls è necessario che:attraverso firewalls è necessario che: Almeno un peer interno al firewall conosce Almeno un peer interno al firewall conosce almeno un peer esterno al firewall;almeno un peer esterno al firewall;

Tali peer supportano il protocollo http;Tali peer supportano il protocollo http;

Il firewall permette il traffico http;Il firewall permette il traffico http;

JXTA: Firewall e NATJXTA: Firewall e NAT