Team project

Team project
Ingegneria informatica
Laurea specialistica
24/10/2004
A.A. 2003/2004
Reti di calcolatori LS
Bertaccini Simone 169703
1
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).
Team Project
Bertaccini Simone - 169703
2
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.
Team Project
Bertaccini Simone - 169703
3
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:
Permesso
scrittura
negato
6
1
2
7
5
Files
gestiti 4
3
 è indipendente dall’effettiva apertura del
file
 deve avere una gestione distribuita
 deve essere indipendente dal file system
File 4
In modifica
Acquisizione
esclusiva
 Deve funzionare anche se ogni utente lavora sulla propria copia locale
del file (a condizione che questi si attengano ad alcune regole)
Team Project
Bertaccini Simone - 169703
4
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
Team Project
Bertaccini Simone - 169703
5
Esempio di interazione
?
6
1
2
7
5
Files
gestiti 4
!
3
7
7
AAAB
Dddd
pppQs
ccccc
QQQB
AAAB
Dqqq
Dddd
pppQs
ccccc
Team Project
Bertaccini Simone - 169703
6
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.
Connection Manager
Presentation layer
Authentication service
Account mng
Team Project
Bertaccini Simone - 169703
7
Architettura del sistema (2)
5. Service engine: è adibito a “scoprire”
6.
7.
8.
9.
i servizi disponibili e a ridirigere le
richieste al modulo opportuno. E’ suo
compito anche inizializzare il sistema.
General authorization control layer:
effettua i controlli generali sulle
abilitazioni dell’utente: riguarda
autorizzazioni non strettamente legati
ad ogni singolo modulo.
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à.
Protocols layer: nel caso ci sia la
necessità di avere server replicati,
gestisce la concorrenza e la
consistenza nel distribuito utilizzando
il protocollo opportuno.
Storage layer: gestisce l’accesso ai
dati. Conosce l’ubicazione fisica dei
dati ed è in grado di reperirli per i
moduli funzionali.
Connection Manager
Presentation layer
Authentication service
Account mng
Service engine
General Authorization Control layer
F.A.C.L.
M.A.C.L.
File
Message
manager
manager
?
Protocols layer
Storage Layer
Team Project
Bertaccini Simone - 169703
8
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
F.A.C.L.
M.A.C.L.
File
Message
manager
manager
?
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”.
Team Project
Bertaccini Simone - 169703
9
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…
Team Project
Bertaccini Simone - 169703
10
Deployement del sistema (2)
Distanza geografica
P2P like
Broker load sharing
Team Project
Bertaccini Simone - 169703
11
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
Team Project
Bertaccini Simone - 169703
12
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)
Team Project
Bertaccini Simone - 169703
13
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.
Team Project
Bertaccini Simone - 169703
14
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
Team Project
Bertaccini Simone - 169703
15
Esempio di conflitto
1
L2
L6
2
3
L6
L6
4
5
L2
L6
L2
L6
6
7
8
L6
L6
9
L6
Team Project
Bertaccini Simone - 169703
16
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 timeout. 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.
Team Project
Bertaccini Simone - 169703
17
Risoluzione dei guasti
1
1
1
2
3
4
2
3
4
2
3
4
5
6
7
5
6
7
5
6
7
Guasto della root
Guasto nodo intermedio
Team Project
Bertaccini Simone - 169703
Split del gruppo
18
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”)
Team Project
Bertaccini Simone - 169703
19
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)

Team Project
Bertaccini Simone - 169703
20
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.
Team Project
Bertaccini Simone - 169703
21
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.
Team Project
Bertaccini Simone - 169703
22
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.
Team Project
Bertaccini Simone - 169703
23