JXTA: Protocols
JXTA definisce una formati per messaggi XML (aka
protocolli) per la comunicazione fra peer:




Peer Discovery Protocol (PDP) utilizzato dai peer per pubblicare
le loro risorse (peers, peer groups, pipes o services) e scoprire
risorse presso altri peer. Ogni risorsa è descritta e pubblicata
tramite un advertisement
Peer Information Protocol (PIP) usato per ottenere informazioni
di stato da altri peer (uptime, state, recent traffic…)
Peer Resolver Protocol (PRP) permette ai peer di inviare
richieste e di ricevere risposte da altri peer. Le richieste (query)
possono essere dirette a tutti i peer di un gruppo oppure a uno
specifico peer. PRP differisce da PDP e da PIP perché permette
la richiesta di informazioni generiche (non solo query predefinite)
Pipe Binding Protocol (PBP) usate per creare pipes. In
particolare PBP permette a un peer di legare fra loro due o più
endpoints.
JXTA: Protocols
JXTA definisce una formati per messaggi XML (aka
protocolli) per la comunicazione fra peer:






Peer Discovery Protocol (PDP)
Peer Information Protocol (PIP)
Peer Resolver Protocol (PRP)
Pipe Binding Protocol (PBP)
Endpoint Routing Protocol (ERP) usato dai peer per instradare i
messaggi. Le informazioni relative all’instradamento contengono
una seguenza di relay peer che può essere usata per
raggiungere la destinazione.
Rendezvous Protocol (RVP) meccanismo utilizzato per la
propagazione dei messaggi
Tutti i protocolli si basano su un modello
domanda/risposta. Ad ogni domanda possono
corrispondere 0, 1 o più risposte.
JXTA: PDP
Type



0 peer
1 group
2 adv generico
Threshold

num max risposte che ogni peer può fornire
Attribute, Value

Condizioni da verificare (Es Attribute = name, Value = test*)
PeerAdv

Può contenere l’advertisement del peer che effettua la query
JXTA: PDP
JXTA: PDP
Type
Count

num risposte
Attribute, Value

Condizioni verificatesi
PeerAdv

l’advertisement del peer che risponde alla query
Response (contiene una scadenza)
JXTA: PDP
JXTA: PIP
Fornisce una serie di query predefinite per ottenere
informazioni sui peer (Es. il messaggio PIP ping, serve a
stabilire se un peer è attivo).
sourcePid

L’id del peer che effettua la richiesta.
targetPid

L’id del peer che riceve la richiesta.
request

Una struttura che descrive la richiesta.
JXTA: PIP
JXTA: PIP
sorcePid
targetPid
uptime

tempo di attività del servizio
timestamp

Tempo in ms dal 1/1/1970 GMT
response

risposta a una PIP query precedente e deve contenere la query
id della precedente query (query id fa parte del protocollo PRP)
traffic

contiene informazioni sul traffico effettuato dal target peer
JXTA: PRP
Permette ai peer di inviare query generiche ad altri peer
Le query possono essere inviate direttamente ad altri
peer o propagate attraverso rendezvous
PIP and PDP si basano su PRP
Può anche utilizzare il servizio SRDI (Shared Resource
Distributed Index).
JXTA: PRP
<jxta:Cred>

Le credenziali di chi genera la query
<HandlerName>

Una stringa che specifica la destinazione della query (quale modulo deve processare la
query).
<SrcPeerID>

L’ id del peer che genera la query.
<QueryID>

L’identificatore della query. Deve essere incluso nel messaggio di risposta alla query
<HC>

Rappresenta il numero di hop già attraversati dalla query. Deve essere incrementato ogni
volta che un peer inoltra la query
<Query>
JXTA: PRP
JXTA: PRP
<jxta:Cred> credenziali del nodo che risponde alla
query.
<HandlerName>
<ResPeerID> L’id del peer che risponde alla query
<QueryID> L’id della query alla quale si sta rispondendo.
<Response>
JXTA: PRP
JXTA: PBP
Una pipe può essere vista come una coda di messaggi che
supporta le operazioni di create, open(bind), close(unbind), delete,
send e receive.
L’operazione create è l’operazione effettuata dal peer per legare un
pipe endpoint con un protocollo di trasporto.
Le pipe vengono pubblicate attraverso pipe advetisement
<Id>
<Type>



JxtaUnicast
JxtaUnicastSecure
JxtaPropagate
<Name> (Non deve essere necessariamente univoco)
JXTA: PBP
<MsgType> query o answer.
<Pipe ID>
<Type>
<Cashed> (non viene più usato)
<Peer>.
<Found> + <PeerAdv>
JXTA: ERP
Il protocollo ERP (Endpoint routing protocol) fornisce una
serie di query/risposte che permette a un peer di
instradare messaggi.
Quando un peer riceve un messaggio da instradare,
controllo se nella propria cache ha una entry verso la
destinazione, in caso contrario, invia una route resolver
query verso un peer routers per ottenere informazioni
relative all’instradamento del messaggio.
Ogni gruppo di solito utilizza una serie di peer come
routers, i quali dispongono di una ampia cache per la
memorizzazione di informazioni di instradamento.
Ogni messaggio mantiene informazioni su tutti i peer che
ha attraversato. Tali informazioni permenttono di evitare
cicli e di scoprire nuove rotte.
JXTA: ERP
Route information
<DstPID> Il peer ID associato alla destinazione.
<Dst>Contiene una lista di endpoint addresses associati alla destinazione.
<Hops> Una lista di Access Point Advertisements che descrive una rotta
verso la destinazione.
JXTA: ERP
Route query message
<Dst> Il peer ID associato alla destinazione.
<Src> Route advertisement del peer che richiede informazioni.
JXTA: ERP
Route response message
<Dst> Route advertisement del peer di cui abbiamo richiesto info.
<Src> Route advertisement del peer che ha richiesto informazioni.
JXTA: RVP
Il RendezVous Protocol viene utilizzato per la
propagazione di messaggi all’interno di un gruppo.
Ogni rendezvous peer collabora con altri rendezvous
nella propagazione dei messaggi fra peer.
I rendezvous peer formano una struttura dinamica detta
Peer View che permette la propagazione dei messaggi
in maniera consistente senza l’utilizzo di una
componente centralizzata.
Il Peer View protocol permette ai peer rendezvous di
organizzarsi in maniera decentralizzata.
JXTA: RVP
RendezVous Advertisement
<RdvGroupId> L’ ID del gruppo per il quale il peer fa da rendezvous.
<RdvPeerId> L’ ID del peer che fa da rendezvous.
<RdvServiceName> Informazioni relative alla PeerView
<Name> Nome del rendezvous peer. Può anche essere uguale al nome del
peer.
<RdvRoute> Una rotta verso il Rendezvous Peer. Contiene al suo interno
una Route advertisement
JXTA: RVP
Propagation control

Un peer rendezvous inoltra tutti i messaggi a meno che:
si è verificato un ciclo
TTL = 0
Il messaggio è un duplicato

Il controllo è effettuato includento in ogni messaggio inoltrato
alcune informazioni