Infrastruttura per la gestione distribuita di un sistema di prenotazione Progetto di: Fabio Fabbri Matricola

Introduzione ► Il progetto consiste nella realizzazione di un’infrastruttura su cui sviluppare un sistema di prenotazione distribuito  Individuazione dinamica dei partecipanti  Comunicazione tra nodi  Corretto utilizzo delle risorse  Sincronizzazione risorse ► Le 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 Server Multicast Service 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.Un cliente modifica la risorsa 2.La risorsa aggiornata e viene inviata al suo servitore con l’indicatore di versione aggiornato 3.Il servitore inoltra la versione modificata a tutti gli altri servitori 4.I servitori modificano la propria risorsa (aggiornando la versione)  Scenario alternativo “Caduta server durante la sincronizzazione”: 4.Un servitore cade prima di aver esteso le modifiche 5.Quando tornerà attivo risincronizzerà le risorse, sostituendo quelle non aggiornate.  Scenario alternativo “Caduta server prima della sincronizzazione”: 3.Il primo servitore cade prima di aver inoltrato le modifiche 4.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