Infrastruttura per la
gestione distribuita di un
sistema di prenotazione
Progetto di:
Fabio Fabbri
Matricola 169678
Introduzione
► Il
progetto consiste nella realizzazione di
un’infrastruttura su cui sviluppare un sistema di
prenotazione distribuito




► Le
Individuazione dinamica dei partecipanti
Comunicazione tra nodi
Corretto utilizzo delle risorse
Sincronizzazione risorse
entità che partecipano al sistema sono:
 Clienti: coloro che desiderano utilizzare le risorse (ad
esempio per effettuare prenotazioni)
 Servitori: Si coordinano per consentire ai clienti di
usufruire del servizio in modo corretto ed efficiente
Arrivo di un servitore
►
Non si fanno ipotesi sull’indirizzo dei servitori. Chi vuole
offrire il servizio deve inviare periodicamente le proprie
informazioni ad un gruppo di multicast che mette in
comunicazione reciproca i servitori presenti
Multicast Service
Server
►
Server
L’invio di messaggi attraverso multicast consente di:
 individuare degli altri servitori presenti
 verificare eventuali cadute dei servitori già presenti (time to live)
Arrivo di un cliente
► Un
cliente che vuole richiedere un servizio si
aggrega al gruppo di multicast e, non appena
riceve un messaggio relativo ad un servitore (“first
server”), richiede a questo di connettersi
► Il servitore controlla lo stato di tutti i servitori
presenti e decide a quale di questi (“best server”)
si dovrà connettere il client per mantenere
bilanciato il carico del sistema.
 La politica di bilanciamento considera soltanto quanti
clienti sono al momento connessi al servitore
► Il
first server invia al cliente le informazioni sul
best server, al quale può richiedere il servizio
Caduta di un nodo
► Servitore:
 I messaggi di multicast dovrebbero arrivare
periodicamente. Se dopo un certo numero di
periodi non è arrivato alcun messaggio da un
servitore, il suo time to live arriva a 0 e questo
non viene più considerato.
► Cliente:
 Periodicamente il servitore a cui il cliente è
connesso richiede un “ping”. Se il servitore non
riceve risposta, considera il cliente caduto, lo
disconnette e rilascia eventuali risorse da questo
acquisite.
Modello risorse
► Le
risorse del sistema vengono replicate su
ogni servitore (letture molto più frequenti
delle modifiche).
► È necessario però che chi intende modificare
una risorsa vi acceda in modo mutuamente
esclusivo.
► È previsto quindi un token per ogni oggetto
su cui si voglia realizzare mutua esclusione
 Bisogna dimensionare la granularità degli oggetti
Acquisizione e rilascio token(1)
►
►
►
►
Il token possiede una coda nella quale vengono inseriti i
servitori che desiderano utilizzare l’oggetto associato.
Ogni servitore possiede una coda per ogni oggetto, nelle
quali memorizza i clienti che desiderano utilizzare l’oggetto
associato.
Ogni servitore può disporre del token per un certo tempo
massimo dopodichè, se qualcun altro è in coda, lo deve
rilasciare. Inoltre se non ha ancora terminato di servire
tutte le richieste, deve rimettersi in fondo alla coda.
Allo scadere del timeout il token viene comunque rilasciato
soltanto dopo aver servito la richiesta corrente (ipotesi
richieste brevi).
Acquisizione e rilascio token(2)
Creazione token
Se un servitore è l’unico presente nel sistema crea tutti i
token.
► Però se sono presenti più servitori:
►


►
I primi due possono riconoscersi subito a vicenda, quindi nessuno
decide di creare i token
Un servitore che possedeva un token è caduto, quindi il token non
è più presente
Caso d’uso di token non presente:
1. Il servitore S1 effettua una token request
2. Tutte risposte negative o scade il timeout di risposta senza aver
ottenuto risposte positive
3. S1 suppone che il token non sia presente
4. Invia la richiesta al servitore con priorità statica più bassa S0
5. S0 controlla che il token non sia presente, lo crea e lo invia ad S1.
Sincronizzazione risorse
►
Caso d’uso “Sincronizzazione riuscita”:
1.
2.
3.
4.

Scenario alternativo “Caduta server durante la
sincronizzazione”:
4.
5.

Un cliente modifica la risorsa
La risorsa aggiornata e viene inviata al suo servitore con
l’indicatore di versione aggiornato
Il servitore inoltra la versione modificata a tutti gli altri servitori
I servitori modificano la propria risorsa (aggiornando la versione)
Un servitore cade prima di aver esteso le modifiche
Quando tornerà attivo risincronizzerà le risorse, sostituendo
quelle non aggiornate.
Scenario alternativo “Caduta server prima della
sincronizzazione”:
3.
4.
Il primo servitore cade prima di aver inoltrato le modifiche
Se si riattiva prima di ulteriori modifiche (ha la versione più
aggiornata) invia la propria versione agli altri servitori; altrimenti
si aggiorna con la versione presente nel resto del sistema.
Sviluppi futuri
► Risolvere
alcuni problemi
 Il servizio di multicast (su Internet) da alcune postazioni
non funziona usare metodi alternativi
► Fornire
ulteriori servizi:
 Autenticazione
 Richieste su più oggetti
 …
► Sviluppare
un’applicazione per la prenotazione
basata su questa infrastruttura
 Ad esempio ad Ingegneria potrebbe essere utile per le
prenotazioni dei laboratori