Utilizzato dai peer per eseguire il routing dei messaggi verso il peer destinata- rio. Le informazioni di routing comprendono la sequenza ordinata di IDs dei relay peer utilizzati per inviare il messaggio al destinatario.
Rendezvous Protocol
Questo protocollo viene utilizzato dal Peer Resolver Protocol e dal Pipe Bin- ding Protocol per propagare messaggi nella rete JXTA.
Tutti i protocolli JXTA sono asincroni e sono basati sul modello query/response.
2.5 Query Process e Resolver Protocol
Il Resolver Protocol ([12], [31]) è un servizio che permette di inviare generiche query sulla rete P2P e di ricevere la relativa risposta, di seguito si elencano gli aspetti principali:
Utilizza XML come linguaggio di interscambio.
Permette di creare applicazioni secondo il modello di comunicazione richiesta- risposta.
Segue il pattern di comunicazione broadcast-and-listen (simile al publish-and- subscribe ma qui lo scoping è il gruppo).
Viene utilizzato come servizio base per l'implementazione dei protocolli di discovery (PDP) e di information (PIP).
Esempio di query Supponiamo che il peer A voglia eseguire una ricerca di una risorsa nella rete JXTA (v. gura 2.5); le fasi di ricerca sono le seguenti:
Il peer A è un Edge peer ed è connesso al Rendezvous Peer R1.
La richiesta di A viene inviata ai peer che appartengono al suo peer group che si trovano nella stessa sotto rete locale via multicast; A è connesso al Rendezvous R1, quindi la richiesta viene inviata anche a quest'ultimo.
Figura 2.5: Query propagation attraverso i rendezvous peer
Se uno dei peer dispone dell'informazione nella propria cache invia la risposta direttamente al peer richiedente (peer A).
Se il RVP R1 non è in grado di fornire la risposta attraverso il suo indice SRDI allora contatta gli altri RVP utilizzando l'algoritmo limited-range walker [16]. Quando la richiesta raggiunge il peer che possiede la risorsa, esso risponderà direttamente al peer A richiedente.
Lungo il cammino in rete la query potrebbe subire la riduzione del TTL(Time to Live), espresso dal numero di hop che attraversa. Questo è dovuto per evitare eetti di rimbalzo che possono veri carsi in rete instabili o molto dinamiche.
Notiamo che solo i peer che appartengono allo stesso peer group di A riceveranno il messaggio e potranno rispondere. L'ambito del Resolver Protocol è il peer group. Il resolver protocol è loosely consistent; il peer A potrebbe ricevere molte risposte oppure nessuna risposta. Non c'è garanzia che la richiesta arrivi a destinazione oppure che l'eventuale risultato venga inviato al peer richiedente.
2.5.1 Resolver Protocol: Broadcast Ping
In questa sezione si illustrano i passi principali che permettono a un peer di utiliz- zare il Resolver Protocol per l'invio di una query (che contiene una stringa Ping) attraverso il Resolver Protocol [31].
2.5. QUERY PROCESS E RESOLVER PROTOCOL 51 Eseguire la connessione ad un peer group: evitare l'utilizzo del gruppo di default perchè il suo scope sarebbe troppo ampio. De nire un nuovo gruppo speci co per l'applicazione che rappresenta lo scope della query.
Creare e registrare un handler (in questo esempio chiamato TestQueryHandler) per accettare richieste e inviare risposte dal Resolver Service. L'handler deve implementare l'interfaccia net.jxta.resolver.QueryHandler:
public interface QueryHandler {
int processQuery(ResolverQueryMsg query);
void processResponse(ResolverResponseMsg response); }
Inviare una richiesta Ping al Resolver Service.
Attendere la ricezione di una risposta dal Resolver Service.
Di seguito si descrive in dettaglio i metodi processQuery e processResponse. processQuery(ResolverQueryMsg query):
Metodo invocato quando si riceve una query dal Resolver Service. ResolverQueryMsg query è un messaggio in formato xml.
Avviene il parsing della query (in questo esempio si tratta di una stringa Ping). Viene creato un messaggio xml di risposta che contiene la stringa Pong; questo
messaggio viene inviato al peer richiedente come risposta alla query Ping. processResponse(ResolverResponseMsg response):
Viene invocato ogni volta che si riceve una risposta a seguito di una query. Il peer potrebbe ricevere più risposte, dunque, questo metodo potrebbe essere
invocato molte volte.
Descrive cosa fa il peer quando riceve la risposta response (in questo esempio il messaggio xml contiene la stringa Pong).
Il codice riportato sotto mostra come inviare una query: public void sendQuery(){
...
// ottengo il Resolver dal gruppo newGroup // e registro l'handler
ResolverServiceImpl resolver;
resolver = newGroup.getResolverService();
TestQueryHandler handler = new TestQueryHandler(handlerName,credential); resolver.registerHandler(handlerName, handler);
// creazione del messaggio
// e invio in broadcast a tutti i membri del gruppo resolver.sendQuery(null, message);
}
2.5.2 Indicizzazione delle risorse: SRDI
Shared Resource Distributed Index (SRDI) [13] è un servizio che fornisce meccanismi e cienti per la propagazione delle query e per la scoperta di risorse all'interno della rete JXTA. Il ruolo principale di questo servizio è svolto dai Rendezvous Peer che mantengono l'indice degli advertisement pubblicati dagli edge peer. La pubblicazio- ne di un nuovo advertisement da parte di un edge peer comporta che il servizio SRDI inserisca l'indice dell'advertisement nel rendezvous peer a cui è connesso. Grazie a questa gerarchia Rendezvous-Edge le query vengono propagate solo tra i rendezvous, riducendo il numero di peer partecipanti della ricerca di risorse. Come spiegato so- pra nella sezione 2.3.1 i Rendezvous peer dispongono loosely-consistent network di rendezvous conosciuti.
Il servizio SRDI utilizza la funzione hash SHA1 su uno spazio di indirizzamento di 160 bit; questo spazio è diviso tra i rendezvous peer. Quando un Rendezvous peer riceve un indice di un advertisement da indicizzare calcola la funzione hash per determinare l'indirizzo del rendezvous peer su cui replicare l'indice. Nell'esempio mostrato in gura 2.6:
2.5. QUERY PROCESS E RESOLVER PROTOCOL 53
Figura 2.6: JXTA SRDI
Il nodo A pubblica diversi advertisement.
Gli advertisement vengono indicizzati dal servizio SRDI utilizzando una chiave (ad esempio il nome oppure l'identi catore dell'adv).
Il peer A è connesso al Rendezvous RDV1 quindi gli indici per questi adverti- sement sono inviati a RDV1 sotto forma di messaggi SRDI. Occorre precisare che i Rendezvous peer mantengono solo gli indici minimizzando la quantità di informazioni da gestire.
vuti sui rendezvous peer 2, 3, 4 secondo l'algoritmo Loosely-Consistent DHT Rendezvous Walker ([16]).
Supponiamo ora che il peer C esegua una query per un advertisement pub- blicato dal peer A. Il rendezvous RDV2 riceve la richiesta di C (in quanto rendezvous a cui C è connesso); l'indice SRDI di RVD2 indica Q(A)=RDV3, quindi RDV2 contatta RDV3.
Notiamo che se il RDV3 è irraggiungibile allora RDV2 esegue l'algoritmo Wal- ker che percorre la Rendezvous Peer View di RDV2 alla ricerca di un ren- dezvous che contenga la replica dell'indice dell'advertisement cercato. La ri- cerca ha esito negativo se i RDV2, RDV3, RDV4 (che mantengono la replica dell'indice) non sono raggiungibili.
Il rendezvous RDV3, in ne, inoltra la richiesta al peer A che risponderà direttamente al peer richiedente C, inviando l'advertisement richiesto.