Progetto Di Un’infrastruttura
Che Permetta La Modifica Di
Dati Condivisi Distribuiti Su Più Nodi
Gozzi Daniele 0000193625
Reti di calcolatori L-S 2004-2005
Introduzione
Creazione un’infrastruttura che permetta di
condividere dati:
 Letture su copia locale.
 Mantenga la consistenza tra le varie copie dei
file.
 Permetta il lock distribuito dei file:
 Modifiche.
 Aggiornamenti.
 Struttura
dinamica.
 Registrazione
e de-registrazione dati.
 Registrazione e de-registrazione client.
Struttura
Divisa in 3
parti:
Client
Server
DBMS
Devo produrre dei multicast a tutti i client
registrati su un file.
Il server mantiene lo stato dei nodi:
• Minore complessità
• Minore overhead.
Struttura - Server
Processo che si occupa di rendere
disponibili ai client i dati necessari
all’interazione tra pari.
 Mantiene lo stato della rete.

 Client
presenti.
 File condivisi.
Persistenza dei dati affidata al DBMS.
 Richieste semplici e veloci da risolvere.

 Difficilmente
cono di bottiglia.
 Facile introdurre replicazione.
Struttura - Client
Interfaccia verso l’infrastruttura.
 Etichette su ogni file.

 Numero
logico del file.
 Numero fisico del file.
Mantenimento dei lock sui file.
 Gestione algoritmo di votazione tra pari.
 Sincronizzazione nell’accesso ai file.
 Richieste al server.

Algoritmo Di Votazione
Server
1: Richiesta al server
2: Elenco client interessati
3
4
3
4
3
3: Vote request.
4
4: Risposta positiva o meno
5a: Abort vote request.
5b: Release al termine dell’uso.
Ottenimento Del Lock
Il
lock è ottenuto se N/2+1 client rispondono
positivamente.
A:1ok 2 abort
1
B:1abort 2 ok
2
C:1abort 2 ok

Non c’è ritrasmissione della richiesta in caso di
conflitto.
 In
alcuni client lock non memorizzato: possono
essere al più N/2 –1.
 Solo un client può avere abbastanza risposte positive
per procedere. Gli altri abortiscono la vote request.
Concorrenza
Attesa
Per rendere
asincrone e
parallele le
richieste ad altri
client.
del gestore solo delle risposte
necessarie per procedere
Restituzione del controllo
I thread del pool terminano il loro
compito asincronamente
Rmi
 Due
tipi di interfacce registrate.
 IServer.
 IClient.
 Utilizzo
di RMI porta, sia i client sia il
server, a poter gestire richieste in parallelo.
 Synchronized sui metodi di modifica dello
stato.
 Controlli sul lock effettuati prima in locale.
Utilizzo Di Diverse Politiche



Mutex distribuito: strumento di base per gestire
la concorrenza.
Default: in caso di conflitto attesa e successivi
tentativi di accesso.
Utilizzo dei file come contenitori di strutture per
gestire l’accesso a risorse:
 Possibilità
di implementare politiche di accesso
complesse.
 Accesso rapido al file che comporta difficilmente
conflitti.
 In caso di conflitto ritrasmissione.
Sviluppi
Introduzione dell’hash dei file invece di
una stringa relativa al nome.
 Un’ottimizzazione degli aggiornamenti dei
file che a volte potrebbero essere evitati o
effettuati solo in parte.
 Prevedere dei controllori sullo stato della
rete che si occupino di:


De-registrare client in caso di fallimenti
ripetuti
 Reinizializzare il server in caso di crash.