Supporto in RMI per la collaborazione in rete
Transcript
Supporto in RMI per la collaborazione in rete
Supporto in RMI per la collaborazione in rete Autore Vincenzo Coco ([email protected]) Il framework che ho sviluppato segue questa linea di Corso di Reti di Calcolatori 2006/2007 principio eLS anche se in stato primordiale rispetto ai professore Antonio supportiCorradi esistenti, certamente più robusti, è stato un buon inizio per prendere coscienza delle variabili incognite della comunicazione in rete. Abstract Java Rmi è una tecnologia orientata ai servizi mentre una collaborazione di utenti è in orientata all'applicazione. Nulla vieta, al supporto creato, di poter essere utilizzato per l'erogazione di un servizio, naturalmente un servizio creato in questo modo risulta meno efficiente di un servizio progettato ad hoc in RMI.Nonostante questo, è molto più semplice sviluppare servizi o applicazioni con questo framework, quindi uno sviluppatore poco esperto può avvalersi di questa scelta. Nella sezione relativa all' parlerò in modo sommario delle parti che costituiscono il sistema, del motivo per cui sono state introdotte e del loro ruolo nel supporto. Nella parte relativa alla descriverò come le parti dialoghino fra di loro per offrire connettività a livello utente. Il paragrafo spiega i meccanismi che vengono innescati quando avviene un guasto di rete e delle perturbazioni di questi sul sistema. La sezione illustra quali sono le politiche per offrire un servizio di bilanciamento del carico in modo da rendere il sistema bilanciato in modo equo. Infine descriverò una di esempio che utilizza 1. Introduzione queste caratteristiche per offrire un servizio di lavagna La capacità di comunicare è una delle facoltà che rende gli essere umani unici nel loro genere, con l'avvento delle condivisa fra un numero di utenti arbitrario e i effettuati sia a livello di supporto che di applicazione. tecnologie informatiche e della rete questa capacità ha assunto caratteristiche sempre più accentuate, tanto che, è possibile comunicare con un altro individuo e per fino 2. Architettura Il sistema di supporto è composto principalmente da: con più individui contemporaneamente, situati al lato Mediator opposto del mondo. Queste tecnologie telecomunicative sono, tuttora, in via di Collaboration sviluppo e così anche il software di supporto che rende la MessageQueue Message comunicazione fruibile per ogni tipologia di utente. UserID Esistono dei software specializzati in determinati ambiti comunicativi e la loro architettura logica si basa su scelte di progetto idonee per soddisfare obiettivi presupposti 2.1 Mediatore Il mediatore costituisce il cuore del supporto e il suo scopo alla creazione dello stesso progetto. è quello di mediare la comunicazione fra gli utenti e Il framework che ho sviluppato segue questa linea di mantenere aggiornata la lista di quelli attualmente collegati. principio e anche se in stato primordiale rispetto ai supporti esistenti, certamente più robusti, è stato un buon Il mediatore svolge la funzione di Broker e quindi offre inizio per prendere coscienza delle variabili incognite della primitive di comunicazione quali l'invio di messaggi da un comunicazione in rete. utente all'altro e la possibilità di effettuare un broadcast a 1 tutti gli utenti (discusse nel dettaglio nella sezione comunicazione). Il sistema proposto è un framework per lo sv iluppo di applicazioni in rete in un ambiente collaborativ o per utenti che v ogliono comunicare fra loro. Lo scopo del progetto è quello di rendere lo sv iluppo di applicazioni in rete, in questo ambiente, più semplice cercando di aggirare le problematiche di lav orare a liv ello più basso, eliminare i problemi di sincronizzazione, offrire primitiv e di comunicazione a più alto liv ello di astrazione, rendere il serv izio architettura affidabile introducendo politiche di qualità di serv izio e replicazione. Il framework è stato implementato in Jav a Rmi che comunicazione offre la comunicazione in rete tramite l'uso di Prox y ma lascia in sospeso questioni come la trasparenza di locazione e l'ampliamento del classico modello replicazione client/serv er. Jav a Rmi è comunque una scelta v alida per la creazione di un supporto come quello che ho qualità di serv izio descritto. applicazione test Il mediatore svolge la funzione di Broker e quindi offre primitive di comunicazione quali l'invio di messaggi da un utente all'altro e la possibilità di effettuare un broadcast a tutti gli utenti (discusse nel dettaglio nella sezione comunicazione). Essendo un oggetto che deve essere conosciuto dagli utenti il mediatore è un oggetto remotizzabile e naturalmente permette la registrazione, la cancellazione di un utente e il prelievo della lista utenti. Il mediatore si registra al RMIRegistry locale per offrire connettività alle collaborazioni e svolge le lookup sui registri degli altri mediatori in lista (vedi sezione replicazione) tramite la . L'associazione utente/collaborazione è unica e viene mantenuta dal mediatore. La svolge una lookup sui registry in lista disponibili alla ricerca di mediatori per la connettività (vedi sezione replicazione). connect connect 2.4 Messaggio 2.2 Utente Figura Collaborazione Il messaggio è un oggetto serializzabile e incapsula il mittente, il destinatario, un etichetta, i dati e un identificativo mentre non esistono messaggi tipati. Nel caso di una broadcast il destinatario è assente. L'identificativo viene assegnato dalla collaborazione in modo incrementale ogni qualvolta si effettua una send/broadcast. Figura Mediator Un utente è un oggetto serializzabile che possiede delle proprietà che possono essergli assegnate in modo arbitrario, utile nel caso di assegnazione di un nome, una password o una qualunque altra proprietà che lo caratterizza. Importante è la proprietà ID che è un identificativo assegnato dal mediatore stesso all'atto della registrazione e l'hash costituito dalla combinazione di ID, nome e mediatore. Figura Messaggio 2.3 Collaborazione 2.5 MessageQueue Figura Utente Un utente è sempre parte di una collaborazione il cui scopo è quello di permettere l'invio di messaggi e la ricezione di messaggi destinati all'utente stesso. La collaborazione rappresenta l'interfaccia fra l'applicazione utente e il mediatore in modo da rendere più trasparente questa comunicazione. Inoltre è necessario estendere la collaborazione per creare applicazioni personalizzate secondo il tipo di messaggi scelti per lo scambio di informazioni. L'associazione utente/collaborazione è unica e viene mantenuta dal mediatore. La coda dei messaggi permette l'inserimento, il prelievo e la rimozione di un messaggio.Questa classe viene utilizzata dal mediatore per contenere i messaggi da smistare. I messaggi sono ordinati secondo una coda FIFO, quindi, un eventuale ordinamento coerente dovrà essere implementato a livello applicativo, così come eventuali politiche di ritrasmissione dei messaggi non ricevuti. 2 3.1 Send Nel caso di una il mediatore cerca la collaborazione a cui è associato l'utente destinatario e se lo trova in lista chiama la della collaborazione corrispondente.In caso contrario comunica con gli altri mediatori a cui è connesso(vedi sezione replicazione) per la ricerca dell'utente se anche questa non va a buon fine si richiama la send su tutti gli altri mediatori che ripetono a loro volta la stessa operazione. La è sincrona e il suo valore di ritorno dipende dal valore di ritorno della corrispondente se l'utente viene trovato, in caso contrario il valore di ritorno è false. La è asincrona e deposita semplicemente il messaggio nella coda del mediatore. Successivamente il MessageConsumer recupererà il messaggio dalla coda e lo passerà al mediatore per lo smistamento. send notify Figura CodaMessaggi 2.5 Architettura generale send notify firesend 3. Comunicazione Figura Send 3.2 Broadcast Il modello di comunicazione è a scambio di messaggi e le primitive di comunicazione offerte all'applicazione sono: send (Message) firesend (Message) broadcast (Message) firebroadcast (Message) notify (Message) Nel caso di un il mediatore chiama la di tutte le collaborazione a cui sono associati gli utenti e comunica con tutti gli altri mediatori conosciuti (vedi sezione replicazione) chiamando la su di essi, che svolgono quindi la medesima operazione. La è sincrona e il suo valore di ritorno dipende dal valore di ritorno delle corrispondenti, in dettaglio restituisce un valore positivo se tutte le hanno Quando una o una viene effettuata su ritornato un valore positivo, in caso contrario il valore di una collaborazione, questa chiama la rispettiva primitiva ritorno è false. del mediatore che si occupa dello smistamento. La è asincrona e deposita semplicemente il Il routing a livello di messaggio tra i mediatori segue uno messaggio nella coda del mediatore. schema a flooding finchè non viene ricevuto il messaggio Successivamente il MessageConsumer recupererà il da tutti gli utenti (caso broadcast) o dall'utente interessato messaggio dalla coda e lo passerà al mediatore per lo (caso send). smistamento. Il meccanismo che permette la ricezione di un messaggio tramite la è la callBack che il mediatore può svolgere perché possiede un istanza di ogni collaborazione attiva. broadcast notify broadcast broadcast notify notify send broadcast firebroadcast notify 3.1 Send 3 <IP> è l'indirizzo IP della macchina <PORTA> è la porta servita dal RmiRegistry <MEDIATOR> è il nome logico del servizio mediatore Figura Broadcast 4. Replicazione La replicazione nel supporto è implementata solo per i mediatori, i quali sono collegati fra di loro in una rete Mesh, più o meno fitta, secondo il grado di conoscenza che un mediatore ha degli altri mediatori. All'avvio di un mediatore, questo cerca di collegarsi agli altri mediatori in lista per la creazione del cluster. Il grado di replicazione e di tolleranza ai guasti dipende, quindi, dal numero di mediatori presenti nel cluster e visibili da una collaborazione. La tipologia di replicazione è attiva ma non esiste un gestore delle copie per la scelta di mantenere l'architettura più distribuita possibile, questo però incide sulla trasparenza di locazione. 4.1 Aggiornamento lista Figura scambio lista mediatori Esistono dei meccanismi di riconoscimento di caduta di un mediatore o di una collaborazione. 4.1 Guasto mediatore Il meccanismo di controllo da parte di una collaborazione è di HearthBeat con un operazione di Check di intervallo di tempo regolabile e in caso di risposta negativa parte il meccanismo di Recovering. Il recovering della connessione di una collaborazione al mediatore avviene semplicemente collegando la collaborazione a un altro mediatore in lista. In questo modo una collaborazione è sempre collegata ad un mediatore se, almeno uno di essi in lista alla collaborazione, è presente. E' stata implementata un aggiornamento della lista dei mediatori che viene effettuata ogni volta che si ha una connessione disponibile a un mediatore ricevendo la lista tramite la chiamata e aggiornando il file con i nuovi indirizzi ricevuti. Tramite questa tecnica si ha una distribuzione di conoscenza della locazione dei mediatori aumentando la probabilità di collegamento. Lo stesso aggiornamento della lista si ha anche lato mediatore ogni volta che viene effettuata la , questo aggiornamento recupera la lista da tutti i mediatori conosciuti e presenti al momento, tramite la chiamata aggiornando il file del mediatore. La lista dei mediatori è quindi distribuita e viene aggiornata di tanto in tanto da parte dei mediatori (10 Figura ricollegamento collaborazione minuti) in modo da evitare il partizionamento del cluster in sottocluster divisi. Il controllo fra i mediatori avviene ad ogni operazione di Il formato di un indirizzo è: send/broadcast e si aggiorna la lista locale dei mediatori rmi://<IP>:<PORTA>/<MEDIATOR> eliminando quelli guasti. <IP> è l'indirizzo IP della macchina 4 GetMediatorList ListaMediatori.tx t connect GetMediatorList ListaMediatori.tx t Figura eliminazione mediatore Facendo un esempio per reti di tipo LAN il Round Trip Time è una scelta discutibile perché, in generale, il tempo di risposta è più o meno simile. Al contrario in reti di tipo WAN questa stima della qualità di servizio è abbastanza appropriata. Il numero di utenti è generalmente applicabile a tutti gli scenari anche se in una rete WAN si può avere il problema di scegliere un mediatore che fisicamente è molto lontano. Poiché queste 2 stime possono variare col tempo l'applicazione può scegliere se la collaborazione deve cercare di tanto in tanto un mediatore migliore per ricollegarsi se la scelta ricade su un diverso mediatore in lista. Questo permette una maggior dinamicità nella qualità del servizio. 4.2 Guasto collaborazione Nel caso di guasto di una collaborazione, essa viene eliminata, insieme all'utente associato dalla lista del mediatore in modo da liberare le risorse, il check avviene in questo caso prima di chiamare la sulla collaborazione . notify 6. Applicazione Figura QoS L'applicazione di esempio sviluppata è una lavagna condivisa fra utenti che possono disegnare con un colore scelto casualmente e cancellare la lavagna. Figura eliminazione collaborazione I messaggi scambiati sono: tag:"start" data: Point tag:"drag" data: Point tag:"end" data:Point tag:"clear" data: assente La classe DrawCollaboration estende la classe RMICollaboration e ridefinisce il metodo La qualità di servizio è implementata nella ricerca del per applicare le azioni corrispondenti alla ricezione di un mediatore più idoneo, quando una collaborazione vuole messaggio. collegarsi. Nel caso del messaggio "start" si inserisce il punto. La scelta avviene secondo 2 meccanismi: Nel caso di un messaggio "drag" o "end" si disegna una 1. Numero di utenti presenti linea dall'ultimo punto dell'utente mittente. 2. Round Trip Time Se si riceve un messaggio "clear" la lavagna viene cancellata. Il primo meccanismo consiste nello scegliere il mediatore A ogni ricezione di un messaggio viene aggiornata una con il minor numero di utenti collegati attualmente. struttura dati per il mantenimento dell'ultimo messaggio Il secondo meccanismo sceglie il mediatore che ha un ricevuto dal mittente in modo da evitare duplicati e tempo di ritorno di risposta minore. ricordare l'ultimo punto disegnato. Sostanzialmente ho implementato queste 2 scelte La classe GUIApplication rappresenta la veste grafica applicabili secondo lo scenario di rete e l'applicazione che dell'applicazione e agisce alla pressione del pulsante Clear e si dispone. agli eventi del mouse se avvengono nell'area di disegno. 5 In entrambi i casi avviene un aggiornamento del disegno e una broadcast del messaggio corrispondente alla collaborazione che comunicherà con il supporto per lo smistamento del messaggio a tutti gli altri utenti. 5. Qualità di servizio notify(Message) In entrambi i casi avviene un aggiornamento del disegno e una broadcast del messaggio corrispondente alla collaborazione che comunicherà con il supporto per lo smistamento del messaggio a tutti gli altri utenti. La primitiva utilizzata è la broadcast sincrona ma per migliorare le prestazioni si potrebbe utilizzare quella asincrona e implementare una coda locale per la ricezione della giusta sequenza dei messaggi con ritrasmissione di quelli non recapitati. 7. Test I test sono stati prima svolti localmente in modo da verificare la presenza di problemi di programmazione logica e successivamente si è svolto un test distribuito. Durante lo sviluppo del supporto ho creato i test JUnit in modo da avere dei feedback su ciò che stavo sviluppando. Poi ho testato l'applicazione con un solo mediatore e diverse collaborazioni in modo da verificare una prima versione di collaborazione. Infine ho testato l'applicazione con più mediatori collegati fra di loro e l'effettivo riconoscimento di caduta di un nodo simulata attraverso una variabile booleana di TestFault presente nella collaborazione e nel mediatore. Il test distribuito è stato creato in una rete locale con 2 postazioni ognuna con un mediatore e un client in esecuzione. Il development dell'applicazione è semplice basta modificare il file ListaMediatori.txt manualmente in modo che ci sia connettività a livello applicativo tra le 2 collaborazioni. Quindi almeno un mediatore attivo e conoscenza da parte delle collaborazioni del mediatore. Figura Sistema Riguardo il controllo della presenza del mediatore il check è stato fissato a 0,5 secondi mentre per la qualità di servizio il tempo di ricerca è di 10 minuti. Quindi, per creare una applicazione che utilizzi il supporto presentato basta estendere la classe RMICollaboration e decidere la tipologia di messaggi da scambiare. Per quanto riguarda gli slot di tempo di reconnettività si può cambiare in funzione del tipo di applicazione o delle scelte sull'affidabilità e della performance della stessa. 6.1 Development Sono stati creati 2 file JAR: uno per il mediatore (collaboration.jar) e uno per l'applicazione (client.jar).con il rispettivo script di esecuzione. L'applicazione ha bisogno di almeno un mediatore raggiungibile per l'esecuzione. Una volta scelta la/le macchina/e che formano la backbone della rete collaborativa si deve aggiornare il file ListaMediatori.txt del supporto, secondo la conoscenza che si ha della rete collaborativa. Lo stesso aggiornamento deve essere fatto sull'applicazione per una miglior scelta di connettività. Una volta avviato un mediatore esso cerca di collegarsi agli altri per il clustering fino a un minuto poi ogni 10 minuti. Figura applicazione in macchina Piero 6 Passo 3 Looking up rmi://192.168.1.33:1099/TheMediator for clustering Mediatore rmi://192.168.1.33:1099/TheMediator non disponibile Looking up rmi://192.168.1.34:1099/TheMediator for clustering Got mediator Proxy[IRMIMediator,RemoteObjectInvocationHandler[Un icastRef [liveRef: [endpoint:[192.168.1.34:49354] (remote),objID:[170f669:1176d50a056:O7fff, 7818742598804724483]]]]] Registering member 0 as Piero Passo 8 Removing Piero Passo 9 Figura applicazione in macchina Vincenzo Le operazioni svolte sono riportate di seguito: 1. Avviare il mediatore su macchina Piero 2. Avviare il mediatore su macchina Vincenzo 3. Attendere un minuto in modo che i 2 mediatori si connettano fra loro 4. Avviare il client su macchina Vincenzo 5. Avviare il client su macchina Piero 6. Disegnare su macchina Vincenzo gli occhi e la bocca 7. Disegnare su macchina Piero i capelli 8. Chiudere il client su macchina Piero 9. Chiudere il mediatore su macchina Piero 10. Disegnare su macchina Vincenzo un punto 11. Chiudere il client su macchina Vincenzo 12. Chiudere il mediatore su macchina Vincenzo 7.1 Log MediatoreVincenzo Passo 2 Registering RMIMediator as "TheMediator" Created mediator, binding... Remote mediator ready... Looking up rmi://192.168.1.34:1099/TheMediator for clustering Got mediator Proxy[IRMIMediator,RemoteObjectInvocationHandler[ UnicastRef [liveRef: [endpoint:[192.168.1.34:49354] (remote),objID:[170f669:1176d50a056:O7fff, 7818742598804724483]]]]] Passo 3 Looking up rmi://192.168.1.33:1099/TheMediator for clustering Mediatore rmi://192.168.1.33:1099/TheMediator non disponibile Registering member 0 as Vincenzo Passo 10 Mediator Proxy[IRMIMediator,RemoteObjectInvocationHandler[Un icastRef [liveRef: [endpoint:[192.168.1.34:49354] (remote),objID:[170f669:1176d50a056:O7fff, 7818742598804724483]]]]] is KO:removing it Passo 11 Removing Vincenzo 7.2 Log MediatorePiero Passo 1 Registering RMIMediator as "TheMediator" Created mediator, binding... Remote mediator ready... Looking up rmi://192.168.1.34:1099/TheMediator for clustering Mediatore rmi://192.168.1.34:1099/TheMediator non disponibile Looking up rmi://192.168.1.33:1099/TheMediator for clustering Mediatore rmi://192.168.1.33:1099/TheMediator non disponibile Passo 3 Looking up rmi://192.168.1.34:1099/TheMediator for clustering Mediatore rmi://192.168.1.34:1099/TheMediator non disponibile Looking up rmi://192.168.1.33:1099/TheMediator for clustering Got mediator Proxy[IRMIMediator,RemoteObjectInvocationHandler[Un 7 icastRef [liveRef: [endpoint:[192.168.1.33:35669] (remote),objID:[O711db294:1176d524734:O7fff, 5380343055211056190]]]]] L'affidabilità del sistema e la qualità di servizio sono Got mediator caratteristiche importanti che andrebbero migliorate per Proxy[IRMIMediator,RemoteObjectInvocationHandler[Un aumentare la scalabilità del sistema. I test effettuati hanno comunque dimostrato una buona icastRef [liveRef: [endpoint:[192.168.1.33:35669] resistenza ai guasti. (remote),objID:[O711db294:1176d524734:O7fff, 5380343055211056190]]]]] Passo 4 Registering member 0 as Vincenzo 7.3 Log ClientVincenzo Passo 4 Looking:rmi://192.168.1.34:1099/TheMediator for QoS Looking:rmi://192.168.1.33:1099/TheMediator for QoS Looking up rmi://192.168.1.34:1099/TheMediator Got mediator Proxy[IRMIMediator,RemoteObjectInvocationHandler[ UnicastRef [liveRef: [endpoint:[192.168.1.34:49354] (remote),objID:[170f669:1176d50a056:O7fff, 7818742598804724483]]]]] Passo 9 Looking:rmi://192.168.1.34:1099/TheMediator for QoS Trying another mediator Looking:rmi://192.168.1.33:1099/TheMediator for QoS Looking up rmi://192.168.1.33:1099/TheMediator Got mediator Proxy[IRMIMediator,RemoteObjectInvocationHandler[ UnicastRef [liveRef: [endpoint:[192.168.1.33:35669] (remote),objID:[O711db294:1176d524734:O7fff, 5380343055211056190]]]]] 7.4 Log ClientPiero Passo 5 9. Possibili sviluppi Il supporto creato ha ancora molti limiti, per prima cosa si potrebbero implementare nuove primitive di comunicazione che utilizzino Poll Object per il recupero dei valori di ritorno. Un ampliamento semantico si potrebbe realizzare con l'invio di messaggi a gruppi differenziati secondo un meccanismo di qualità dei messaggi o dell'applicazione utilizzata con l'ausilio di messaggi tipati e un gestore di coda orientato alla qualità del servizio sui messaggi. L'affidabilità si può migliorare tramite la permanenza dei messaggi per un periodo di tempo limitato in modo da poter offrire il ripristino dei messaggi non ricevuti all'atto del ricollegamento di un utente. Lo stesso meccanismo si può utilizzare per disaccoppiare temporalmente gli utenti di una collaborazione per applicazioni come il newsgrouping. Un altro possibile miglioramento è nel discovering di nuovi mediatori, dato che si è scelto un approccio distribuito al problema, si potrebbe incrementare lo scambio delle liste dei mediatori introducendo gli stessi utenti nel aggiornamento della lista, oppure, in caso di mancanza di mediatori utilizzare un recupero basato su un Manager, servizio di Naming o un sito Web che aumenti la trasparenza di locazione. Looking:rmi://192.168.1.34:1099/TheMediator for QoS Looking:rmi://192.168.1.33:1099/TheMediator for QoS 10. Bibliografia Looking up rmi://192.168.1.33:1099/TheMediator [1] O'Reilly Java RMI Got mediator Proxy[IRMIMediator,RemoteObjectInvocationHandler[ [2] Java RMI: Remote Method Invocation by UnicastRef [liveRef: [endpoint:[192.168.1.33:35669] Troy Bryan Downing (remote),objID:[O711db294:1176d524734:O7fff, 5380343055211056190]]]]] [3] Slide Reti di calcolatori LS (http://wwwOlia.deis.unibo.it/Courses/RetiLS/Lucidi.h 8. Conclusioni tml) Il framework sviluppato permette una facile implementazione di applicazioni che si basano su gruppi di utenti che vogliono collaborare per scambiarsi informazioni. Fra queste applicazioni vi sono esempi come l'instant messaging, sistemi p2p per lo scambio di documenti, musica o video, sviluppo di software in ambito opensource e molti altri. L'affidabilità del sistema e la qualità di servizio sono caratteristiche importanti che andrebbero migliorate per aumentare la scalabilità del sistema. 8