1 Team project A.A. 2003/2004 Reti di calcolatori LS Bertaccini Simone 169703 Ingegneria informatica Laurea specialistica 24/10/2004.

Presentazione sul tema: "1 Team project A.A. 2003/2004 Reti di calcolatori LS Bertaccini Simone 169703 Ingegneria informatica Laurea specialistica 24/10/2004."— Transcript della presentazione:

1 1 Team project A.A. 2003/2004 Reti di calcolatori LS Bertaccini Simone 169703 Ingegneria informatica Laurea specialistica 24/10/2004

2 Team Project Bertaccini Simone - 169703 2 Introduzione Uno degli aspetti più complessi da gestire durante l’implementazione e il mantenimento di un progetto è generalmente la collaborazione dei vari componenti del team di sviluppo, in particolare quando team e progetto diventano di medie o grandi dimensioni. I problemi principali sono la comunicazione tra i vari componenti del gruppo e la gestione della “concorrenza” sui vari moduli costitutivi del progetto. Mentre il primo aspetto può essere risolto organizzando frequenti riunioni di allineamento e mettendo a disposizione dei partecipanti strumenti di comunicazione quali programmi di messaggistica immediata, di conferenza e di posta elettronica, il secondo è difficilmente gestibile attraverso questi mezzi e può necessitare di un supporto gestionale automatico “semi-intelligente” (o più semplicemente che cerchi di garantire il rispetto di alcune regole).

3 Team Project Bertaccini Simone - 169703 3 Obiettivi Progettare un sistema per la gestione di progetti da parte di più utenti contemporaneamente anche distanti nello spazio. Rendere il sistema facilmente estendibile. Implementare un prototipo di tale sistema … … che possa essere avere un’installazione distribuita. … implementando il quale si abbia l’occasione di studiare il maggior numero di modalità di comunicazione possibili. … possa essere testato senza l’uso di una rete. Rilevare le situazioni in cui il prototipo si comporta in modo anomalo.

4 Team Project Bertaccini Simone - 169703 4 Descrizione del progetto Il sistema deve gestire un insieme di file ai quali accedono molti utenti. Lo scopo principale è impedire che più di un utente lavori contemporaneamente sullo stesso file. A differenza della protezione fornita dal file system quella di team project: Files gestiti 1 2 7 6 3 4 5 File 4 In modifica Acquisizione esclusiva Permesso scrittura negato è indipendente dall’effettiva apertura del file deve avere una gestione distribuita deve essere indipendente dal file system Deve funzionare anche se ogni utente lavora sulla propria copia locale del file (a condizione che questi si attengano ad alcune regole)

5 Team Project Bertaccini Simone - 169703 5 Modifica di un file Se un utente desidera modificare un file: Aggiorna le informazioni su questo file, controllando se è bloccato da un altro utente. Nel caso non sia allineato scarica l’ultima versione. Richiede il lock sul file Effettua le modifiche (sulla propria copia) Effettua l’upload della nuova versione Sblocca il file

6 Team Project Bertaccini Simone - 169703 6 Esempio di interazione Files gestiti 1 2 7 6 3 4 5 ? 7 7 AAAB Dddd ccccc QQQB Dqqq ccccc Versione? Out of date ! AAAB Dddd pppQs AAAB Dddd pppQs

7 Team Project Bertaccini Simone - 169703 7 Architettura del sistema 1. Interfaccia verso l’esterno: definisce le modalità con cui altre applicazioni o gli utenti possono comunicare con il servizio. 2. Connection Manager: si occupa delle politiche riguardanti le connessioni. Può decidere se scartare una connessione in caso di congestione o in che modo gestire diverse connessioni contemporanee. In questo livello è possibile collocare la gestione della qualità di servizio. 3. Presentation Layer: si occupa della “traduzione” delle richieste in chiamate a funzioni del motore e delle risposte del servizio nel formato di uscita. 4. Authentication Service: si occupa di identificare l’utente e scoprire il ruolo che questo ricopre all’interno del progetto richiesto. Se il servizio fosse erogato a pagamento all’interno di questo livello potrebbero essere inseriti anche i criteri di accounting. Presentation layer Authentication service Connection Manager Account mng

8 Team Project Bertaccini Simone - 169703 8 ? File manager Message manager Architettura del sistema (2) 5. Service engine: è adibito a “scoprire” i servizi disponibili e a ridirigere le richieste al modulo opportuno. E’ suo compito anche inizializzare il sistema. 6. General authorization control layer: effettua i controlli generali sulle abilitazioni dell’utente: riguarda autorizzazioni non strettamente legati ad ogni singolo modulo. 7. Moduli funzionali: ogni modulo può essere dotato di un authorizazation control sub-layer che effettui i controlli relativi al modulo specifico. Ogni componente di questo livello è adibito alla gestione di una diversa funzionalità. 8. Protocols layer: nel caso ci sia la necessità di avere server replicati, gestisce la concorrenza e la consistenza nel distribuito utilizzando il protocollo opportuno. 9. Storage layer: gestisce l’accesso ai dati. Conosce l’ubicazione fisica dei dati ed è in grado di reperirli per i moduli funzionali. Presentation layer Authentication service Service engine General Authorization Control layer F.A.C.L. M.A.C.L. Storage Layer Protocols layer Connection Manager Account mng

9 Team Project Bertaccini Simone - 169703 9 Flessibilità dell’architettura Data l’eterogeneità di esigenze che diversi progetti possono presentare, l’architettura è ricca di livelli opzionali. E’ altrettanto vero che non è possibile prevedere le esigenze di tutti a priori è quindi necessario permettere l’aggiunta di nuovi livelli non previsti. Connection Manager N X Message elaboration layer Service engine ? File manager Message manager F.A.C.L.M.A.C.L. N X Message elaboration layer Storage layer Per questo l’architettura inizialmente pensata è stata modificata in modo da prevedere alcuni livelli obbligatori e due “stack” di livelli opzionali. E’ quindi possibile aggiungere livelli nella struttura “verticale” e funzioni nella struttura “orizzontale”.

10 Team Project Bertaccini Simone - 169703 10 Deployement del sistema Il sistema non fa alcuna ipotesi sul tipo di deployement delle varie copie del sistema (non necessariamente sono più di una!!) se non nel livello dei protocolli. Nella mia implementazione le copie sono logicamente organizzate ad albero Questo garantisce una rapida diffusione dell’informazione “lock” senza la necessità di avere una connessione per ogni coppia di server. Altri protocolli potrebbero considerare un’organizzazione logica differente. I clienti possono accedere al servizio o con un principio di località (UDDI?) oppure attraverso un “broker” che garantisca il load sharing La scelta migliore dipende ovviamente dalle esigenze, dal tipo di progetto, dal traffico previsto, ecc…

11 Team Project Bertaccini Simone - 169703 11 Deployement del sistema (2) P2P like Distanza geografica Broker load sharing

12 Team Project Bertaccini Simone - 169703 12 Caratteristiche del sistema Sistema replicato in cui tutte le copie sono attive La replicazione ha lo scopo di mantenere il servizio attivo 24/7 e di migliorare i tempi di risposta delle operazioni di lettura (+ frequenti) Le copie guaste vengono rilevate attraverso l’assenza dell’heartbeat La sincronizzazione sulle operazioni di scrittura è lazy (conflitti gestiti dai lock …) La sincronizzazione sul protocollo di lock è eager Le copie sono collegate logicamente ad albero per permettere un minor numero di messaggi Durante la comunicazione Di heartbeat

13 Team Project Bertaccini Simone - 169703 13 Tecnologia utilizzata Team Project è stato sviluppato in.NET per diverse esigenze, in C# (ma moduli aggiuntivi potrebbero essere sviluppati in altri linguaggi). Il protocollo per i lock comunica attraverso socket e TCP Gli altri protocolli utilizzano remoting (  RMI), secondo il pattern “poll for result” per permettere la gestione dei time-out I messaggi I_M_ALIVE sono inviati via UDP (heartbeat), semantica may be, pattern “fire & forget” La comunicazione client-Web service avviene in SOAP over HTTP La comunicazione Web service-Team Project avviene in remoting binario (i due dovrebbero risiedere sulla stessa macchina)

14 Team Project Bertaccini Simone - 169703 14 Interfaccia al servizio Realizzata utilizzando un semplice web-service Signature: string PerformAction(string) Il parametro e il valore di ritorno sono stringhe xml il cui contenuto dipende in parte dal servizio richiesto. Il web service sarebbe in grado di attivare il servizio. Questo non è stato implementato in quanto per ora Team project è in realtà un’applicazione console, mentre sarebbe stato probabilmente opportuno implementare un servizio. L’uso di un web service rende il servizio accessibile da qualsiasi linguaggio su qualsiasi piattaforma.

15 Team Project Bertaccini Simone - 169703 15 Il protocollo per i lock Tra i protocolli sviluppati nel prototipo ci si è concentrati principalmente su quello per i lock. Le linee guida di questo protocollo sono: L’informazione “file bloccato” è quella che si deve propagare il più rapidamente possibile. Durante l’esecuzione del protocollo alcune copie possono anche “pensare” che un utente abbia acquisito un lock anche se in realtà è stato preso da un altro Al termine del protocollo tutte le copie devono essere d’accordo su chi ha effettivamente acquisito il lock. Caratteristiche: (N-1)*2 messaggi se non c’è nessun conflitto In caso di conflitto dipende da diversi fattori Il messaggio si propaga in (caso peggiore) 2*(h-1) passi

16 Team Project Bertaccini Simone - 169703 16 Esempio di conflitto 1 2 3 4 56 9 7 8 L2 L6 L2 L6

17 Team Project Bertaccini Simone - 169703 17 Rilevamento copie non disponibili Ogni copia invia ai propri vicini (nel nostro caso il padre e i figli nell’albero) un messaggio a intervalli regolari. Se non si ricevono per N (configurabile) volte un messaggio da una sorgente, questa viene considera fuori servizio (o comunque irraggiungibile). La copia che rileva il problema invia a tutte le altre un messaggio per indicare la rimozione. Ad ogni comunicazione è comunque assegnato un time- out. Se questo scatta la copia con la quale si tentava di comunicare viene considerata off-line. Per le ritrasmissioni ci si affida al protocollo di comunicazione sottostante.

18 Team Project Bertaccini Simone - 169703 18 Risoluzione dei guasti 1 2 5 34 67 Guasto della root 1 2 5 34 67 Guasto nodo intermedio 1 2 5 34 67 Split del gruppo

19 Team Project Bertaccini Simone - 169703 19 Ingresso nel gruppo L’ingresso di una nuova copia nel sistema è una situazione anomala che dev’essere gestita correttamente, eventualmente con l’intervento di sistemisti: Se la copia è disallineata potrebbe essere necessario trasferire una grossa quantità di dati. E’ opportuno scegliere al meglio la posizione della copia all’interno dell’albero. E’ necessario ri-configurare opportunamente il broker o comunque il meccanismo di scelta della copia da interpellare. Nel prototipo, per scopi di test, è possibile che una copia si unisca al gruppo come figlia di un’altra a cui inoltra la richiesta. Al momento non è implementata alcuna operazione di allineamento. Si tratta comunque soltanto di esplorare ricorsivamente tutte le “locations” ed effettuare gli opportuni download. La copia che si inserisce nel gruppo si trova sempre in uno stato “out of date” (o al massimo “current”)

20 Team Project Bertaccini Simone - 169703 20 Problemi non gestiti Se le copie non sono allineate si ha un comportamento anomalo Es: lettura di un file che in altre copie risulta cancellato L’ordine dei messaggi non è concordato con tutte le copie. Problema: Nel sistema viene cancellato una file A loccato da UA Su una copia dove la cancellazione è già avvenute, l’utente UB crea un file B con il medesimo nome di A. Per qualche ragione il messaggio di creazione si propaga più velocemente di quello di cancellazione. In una copia viene richiesto di scrivere B senza che A sia stato cancellato, quindi genera un’eccezione. La copia su cui lavora UB lo notifica dell’errore ma non propaga ulteriormente l’eccezione. Altre copie potrebbero quindi mantenere il file B. Alcune situazioni di errore non gestite (politica lazy senza reconciliation) Es: una copia rifiuta la cancellazione di una location o un file)

21 Team Project Bertaccini Simone - 169703 21 Problemi non gestiti (2) Creazione contemporanea di due file con lo stesso nome su copie diverse. Alcuni di questi problemi sono di facile soluzione, anche se sarebbe stata necessaria un’attenta valutazione dei molti modi diversi in cui il problema si presenti. Il problema dell’ordinamento dei messaggi necessiterebbe forse di una gestione più complessa. Si è ritenuto che tali problemi dessero scarso valore aggiunto al progetto rispetto al tempo necessario per risolverli.

22 Team Project Bertaccini Simone - 169703 22 Client servizio Come esempio di come potrebbe essere utilizzato il servizio ho sviluppato un piccolo client L’applicazione costruisce gli xml di richiesta e li invia al web service in poche righe di codice.

23 Team Project Bertaccini Simone - 169703 23 Conclusioni Alcune delle tematiche che avrei desiderato includere nel progetto (come la QoS) non sono purtroppo state affrontate pienamente per problemi di tempo. Sebbene poi il prototipo sia lontano dal prodotto finito che avevo immaginato (ma che sapevo sarebbe stato impossibile portare a termine), mi ha dato la possibilità di studiare e scontrarmi con alcuni dei problemi legati al mondo distribuito. Rimane inoltre la soddisfazione di aver acquisito il know how legato all’implementazione di web service, dell’utilizzo di chiamate asincrone per la gestione dei time-out, della messa in pratica di alcuni concetti studiati per la sincronizzazione di sitemi multi-thread e altro ancora.