Supporto in RMI per la collaborazione in rete Autore:Vincenzo Coco Matricola: Corso di Reti di Calcolatori LS 2006/2007 Docente: Antonio Corradi

Descrizione del progetto Il progetto è un framework per lo sviluppo di applicazioni in rete in ambiente collaborativo Gli obiettivi sono Semplicità nello sviluppo di applicazioni in rete che utilizzino il supporto Offrire primitive di comunicazione fra gli utenti Rendere il supporto affidabile Introdurre dei meccanismi di qualità del servizio nel supporto

Descrizione del sistema Il sistema è composto da: Mediator: Oggetto remotizzabile per mediare la comunicazione tra gli utenti Collaboration:Oggetto remotizzabile per l'interfaccia tra il supporto e l'applicazione MessageQueue: Oggetto contenente i messaggi in attesa di invio Message: Oggetto serializzabile per lo scambio di dati UserID: Oggetto serializzabile che identifica un utente

Comunicazione Le primitive disponibili per la comunicazione sono: Send (Message) Broadcast (Message) FireSend(Message) FireBroadcast(Message) Notify (Message) La send e la broadcast sono sincrone La fireSend e la fireBroadcast sono asincrone la notify è utilizzata per la ricezione del messaggio tramite linterfaccia Collaboration di callBack

Ordinamento e smistamento dei messaggi Quando si esegue una fireSend o una fireBroadcast il messaggio viene messo in coda La coda è ordinata secondo un ordinamento FIFO e non ammette duplicati Il Thread consumatore recupera il primo messaggio dalla coda e chiama la primitiva sul mediatore Il mediatore smista il messaggio con uno schema a flooding inserendolo nella coda di ogni altro mediatore conosciuto La send e la broadcast sincrone utilizzano la chiamata di procedura remota sui mediatori

Replicazione e fault tollerance La replicazione è attuata solo per i mediatori che costituiscono una MeshNet Il tipo di replicazione è attiva ma senza un gestore che coordini le copie Si riconoscono i fault sia dei mediatori che delle collaborazioni Il grado di tolleranza ai guasti dipende dal numero di mediatori conosciuti dalle rispettive parti

ERRORE Replicazione e fault tollerance Caso di guasto del mediatore MEDIATOR2 HearthBeat OK MEDIATOR1 MEDIATOR3 UTENTE Collaboration1 UTENTE Collaboration4 UTENTE Collaboration3 UTENTE Collaboration2

Replicazione e fault tollerance Caso di guasto del mediatore MEDIATOR2 Check Notify Check ERRORE Notify OK Broadcast MEDIATOR3 UTENTE Collaboration3 UTENTE Collaboration2 MEDIATOR1 UTENTE Collaboration1 Broadcast UTENTE Collaboration4

ERRORE Replicazione e fault tollerance Caso di guasto della collaborazione UTENTE Collaboration1 Broadcast Notify Broadcast Check OK Check Notify UTENTE Collaboration2 MEDIATOR3 UTENTE Collaboration4 UTENTE Collaboration3 MEDIATOR1

Connect Replicazione e fault tollerance Scambio lista dei mediatori MEDIATOR1 MEDIATOR2 UTENTE Collaboration1 UTENTE Collaboration3 UTENTE Collaboration2 Lista Mediatori Lista Mediatori

Qualità del servizio La collaborazione può scegliere il mediatore secondo 2 parametri di qualità di servizio: 1. Numero di utenti 2. Round Trip Time Problema: La variabilità dei parametri nel tempo influisce sulla performance del sistema Soluzione: Controllo dinamico del miglior mediatore

Qualità del servizio Scambio parametri qualità 10 GetQoS 20 Connect MEDIATOR1 MEDIATOR2 UTENTE Collaboration1 UTENTE Collaboration3 UTENTE Collaboration2

Esempio Applicazione Collaborazione per una WhiteBoard fra utenti APPLICAZIONE SUPPORTO CONNECT BROADCASTNOTIFY

Conclusioni e sviluppi futuri Il supporto sviluppato permette una facile implementazione di nuove applicazioni come linstant messaging, scambio di file e molti altri. Aumentare la scalabilità del sistema Arricchire il supporto con nuove primitive Disaccoppiamento temporale Meccanismi di QoS sui messaggi Discovering nuovi mediatori