Nell'architettura di rete di JXTA si individuano quattro tipi peer:
Minimal edge peer: sono classi cati in questa categoria dispositivi (come PDA e telefoni cellulari) con risorse limitate, dunque non in grado di eettuare il caching degli advertisement oppure non in grado di eseguire il routing dei messaggi di altri peer. Questi peer eseguono solo le operazioni fondamentali di scambio di messaggi con altri peer.
Full-featured edge peer: rappresentano la maggior parte dei JXTA peer; oltre a inviare e ricevere messaggi, mantengono la cache degli advertisement. Rendezvous peer (RVP): come i full-featured edge peer mantengono la ca-
che degli advertisement; inoltre contribuiscono alla ricerca di risorse perché possono inoltrare una richiesta a loro pervenuta ad altri Rendezvous peer. Relay peer: partecipa al routing dei messaggi; se un peer non dispone del-
le informazioni di routing necessarie allora le richiede al relay peer. Questa situazione è frequente per i peer che si trovano all'interno di sistemi protet- ti da rewall oppure sistemi NAT che devono contattare un relay peer per comunicare con altri peer al di fuori della loro rete.
2.3. ARCHITETTURA DI RETE DI JXTA 45
Figura 2.4: Esempio di rete JXTA con rewall e relay peer
Un peer appartenente a un sistema protetto da rewall può comunicare di- rettamente con i peer che si trovano fuori dal rewall, ma un peer esterno al rewall non è in grado di stabilire una connessione diretta con il peer interno al rewall. Vale lo stesso per i peer a monte si un NAT.
Al ne di permettere ad un peer A, protetto da rewall o NAT, di comunicare nella rete JXTA occorre che A esegua una connessione ad un peer C usando un protocollo come HTTP, che può attraversare il rewall (v. gura 2.4). Il peer C si connette con il peer B attraverso i protocolli TCP/IP. Dunque è stata stabilita una connessione virtuale tra Peer A e Peer B.
2.3.1 Rendezvous Peer
I Rendezvous Peer sono particolarmente interessanti nell'architettura di JXTA per- ché intervengono nelle fasi di pubblicazione e ricerca di risorse [30].
Un RVP può essere considerato come ogni altro peer ma in più: Mantiene una cache degli advertisement.
Partecipa al Discovery Protocol (inoltra le richieste del Discovery Service). Mantiene la Rendezvous PeerView cioè una lista degli altri RVP conosciuti
Mantiene una lista dei peer che lo stanno utilizzando come RVP.
Periodicamente seleziona in maniera casuale altri Rendezvous Peer e invia loro la lista dei RVP conosciuti.
Periodicamente elimina dall PeerView i RVP non più attivi.
Ogni peer group mantiene e gestisce il proprio insieme di Rendezvous Peer (Rendezvous PeerView) e può utilizzare tutti quelli di cui ha bisogno.
La Standard Reference Implementation di JXTA richiede che almeno uno dei peer di un peer group si comporti come Rendezvous. I Rendezvous Peer possono dinamicamente connettersi e disconnettersi ai vari peer group proprio come un nor- male peer. Ogni peer può essere connesso a più RVP (nella JXTA release 2.0 ogni peer poteva essere connesso al massimo con un RVP in ogni istante).
Rendezvous pubblici (come quelli indicati nella con gurazione iniziale della piat- taforma JXTA) agiscono solo come rendezvous peer per il gruppo di default Net- PeerGroup. Se si ha bisogno di rendezvous peer per un particolare gruppo diverso da quello di default allora l'applicazione stessa deve fornire un proprio insieme di RVP.
Se un'applicazione JXTA viene eseguita esclusivamente su rete locale e comunica solo con altri peer che si trovano nella stessa sottorete non è necessario attendere la connessione a un rendezvous peer; questo però è un caso piuttosto limitato infatti la maggior parte delle applicazione desiderano comunicare con peer sparsi in tutto il mondo.
Quando un peer esegue il join ad un peer group, esso cerca automaticamente un rendezvous per quel peer group. Se non lo trova può decidere di diventare lui stesso RVP attraverso meccanismi forniti dalla piattaforma.
Strategie per diventare RVP L'applicazione stessa deve determinare il criterio migliore per eleggere i peer rendezvous secondo i propri obiettivi. La API di JXTA fornisce due modalità per diventare RVP attraverso i metodi dell'interfaccia net.jxta. protocol. RendezVousSerice:
2.3. ARCHITETTURA DI RETE DI JXTA 47 Invocare il metodo setAutoStart(true, period): il peer controlla lo sta- to ogni period millisecondi e diventa rendezvous (oppure torna in modali- tà edge peer) secondo le necessità del gruppo per mantenere un rapporto edge/rendedezvous adeguato.
RVPs per i sottogruppi Per default, un sottogruppo usa la stessa implemen- tazione del rendezvous service del parent group, essi però hanno stati diversi: il servizio rendezvous di ogni peer group mantiene un proprio stato, quindi un RVP per il gruppo di default (o qualsiasi altro gruppo) NON diventa automaticamente RVP per il sottogruppo.
Con gurazione iniziale dei RVP La con gurazione statica de nita attraverso il con gurator (o attraverso i metodi della classe net.jxta.platform. NetworkCon - gurator) rappresentata dal le PlatformCon g si applica SOLO al NetPeerGroup. Non esiste l'equivalente per i sottogruppi. Quindi i RVPs e Relay peers indicati nella con gurazione iniziale valgono solo per il gruppo di default NetPeerGroup.
Retrocessione RVP -> EDGE
Un peer diventato RVP grazie al meccanismo di autostart può tornare al suo stato di EDGE peer automaticamente.
Il meccanismo automatico di retrocessione entra in gioco quando ci sono più di 5 RVPs in un gruppo.
Fino a 5 RVPs la situazione è considerata non critica (anche se tutti i peer del gruppo sono rendezvous).
Se ci sono più di 5 RVPs nella view di un RVP e se nel gruppo non c'è nessun client allora quel RVP retrocede a EDGE peer.
Se ci sono più di 5 RVPs nella view di un RVP e ci sono meno di 3 client viene scelto in maniera random un RVP da retrocedere a EDGE.
Obiettivi
Eliminare lentamente i RVPs poco utilizzati.
Meccanismo a cascata che permette ai peer di conoscere altri RVPs a partire dal RVP a cui sono direttamente connessi.
I peer smettono di eseguire il meccanismo di ricerca attiva dei RVPs e entrano in un meccanismo di scambio random più lento quando hanno 4 RVPs nella loro view.