Lezione 6
JXTA
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
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 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
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.
Non tutti i servizi vengono
I servizi forniti da un gruppo sono
implementati in ogni gruppo.
Quando un gruppo non definisce un
servizio questo viene ereditato dal
gruppo padre






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.
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 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
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)
Utili per gestire
Sono bidirezionali e sicure
stream di dati
Permette 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 sicure
Non suddividono il messaggio in chunk (l’applicazione deve verificare
che i messaggi non superino la dimensione massima).
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 multihop 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
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 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:
Tutti peer possono
implementare i servizi
di Relay e RendezVous
anche
contemporaneamente
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: 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