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 JXTA: Hello World Requirement Java SDK (http://java.sun.com) JXTA (http://download.jxta.org/index.html) Documentation (http://platform.jxta.org/java/api/overview-summary.html) Esempi (http://www.jxta.org/ProgGuideExamples.zip) JXTA: Hello World Compilare usando JXTA javac -classpath .\lib\jxta.jar SimpleJxtaApp.java Lanciare un applicazione java -classpath .\lib\jxta.jar;.\lib\log4j.jar; .\lib\bcprov-jdk14.jar;. SimpleJxtaApp JXTA: Hello World import net.jxta.peergroup.PeerGroup; import net.jxta.peergroup.PeerGroupFactory; import net.jxta.exception.PeerGroupException; public class SimpleJxtaApp { // This is a simple example of how an application would start jxta static PeerGroup netPeerGroup = null; public static void main(String args[]) { System.out.println("Starting JXTA ...."); SimpleJxtaApp myapp = new SimpleJxtaApp(); myapp.startJxta(); System.out.println("Hello from JXTA group " + netPeerGroup.getPeerGroupName() ); System.out.println(" Group ID = " + netPeerGroup.getPeerGroupID().toString()); System.out.println(" Peer name = " + netPeerGroup.getPeerName()); System.out.println(" Peer ID = " + netPeerGroup.getPeerID().toString()); System.out.println( "Good Bye ...."); myapp.netPeerGroup.stopApp(); System.exit(0); } private void startJxta() { try { // create and start the default JXTA NetPeerGroup netPeerGroup = PeerGroupFactory.newNetPeerGroup(); } catch (PeerGroupException e) { // could not instantiate the group, print the stack and exit System.out.println("fatal error : group creation failure"); e.printStackTrace(); System.exit(1); } } } JXTA: Configurazione JXTA: Configurazione JXTA: Configurazione Demo