Progetto di un Gestore di Nomi Corso di Reti di Calcolatori L-S prof. Antonio Corradi A.A 2003/2004 Autore: Molesini Ambra.

Presentazione sul tema: "Progetto di un Gestore di Nomi Corso di Reti di Calcolatori L-S prof. Antonio Corradi A.A 2003/2004 Autore: Molesini Ambra."— Transcript della presentazione:

1 Progetto di un Gestore di Nomi Corso di Reti di Calcolatori L-S prof. Antonio Corradi A.A 2003/2004 Autore: Molesini Ambra

2 Introduzione Da quando è “esploso” Internet si è sentita sempre forte l’esigenza di una entità capace di trasformare il “nome logico“ di un servizio nelle sue “coordinate”, cioè nell’indirizzo di rete e numero di porta su cui è in attesa il servitore: questa entità è chiamata Gestore dei Nomi il tipo di servizio che offre è prezioso, occorre che anche in caso di un guasto il sevizio non venga negato, oppure che i tempi in cui il servizio non sia disponibile siano brevissimi. occorre pensare al gestore dei nomi come ad un servizio replicato

3 Obbiettivi Il gestore deve essere replicato per garantire comunque il servizio I servitori si possono registrare/cancellare al servizio di nomi I clienti devono fornirne il nome logico e otterranno indirizzo di rete e numero di porta o indicazione di errore. Le copie devono essere calde Le copie devono monitorare il sistema per identificare guasti Ipotesi di guasto singolo ai nodi

4 Idea Generale Gestore Nomi Server Cliente Richiesta registrazione/ cancellazione Richiesta indirizzo e porta del server Gestore Nomi Gestore Nomi

5 Progetto: idea generale Il gestore dei nomi è “un’entità complicata” che deve svolgere innumerevoli attività durante il suo ciclo di vita: fornire un servizio a server e clienti esterni monitorare le copie che compongono il servizio attendere nuove copie risolvere problemi dovuti a crash si è pensato per cui di strutturare l’entità come un insieme di Demoni che collaborano tra loro al fine di fornire il servizio richiesto

6 Progetto: replicazione Come abbiamo già detto occorre che il gestore sia replicato per poter tollerare guasti di diversa natura e garantire comunque il servizio. Il tipo di replicazione scelto per questa applicazione segue il modello delle copie passive di tipo Master-Slave Si è inoltre deciso che le copie si devono autoconfigurare in una catena dopo che è partita la copia Master Si è deciso di utilizzare un checkpointing event driven (ad ogni interazione con una entità server) seguendo la catena: Il master aggiorna il primo slave che aggiornerà il secondo….e così via

7 Progetto: analisi guasti(1) Prima di vedere come è stata strutturata l’applicazione è bene porre l’attenzione sulla tipologia di guasti che si devono riconoscere e risolvere. Come scelta progettuale è stato sottolineato che le copie si devono configurare in una catena e che si vuole un modello a copie calde: MasterI SlaveII Slave N  Salve

8 Progetto: analisi guasti(2) Con questo tipo di configurazione abbiamo diverse tipologie di guasti possibili Caduta del master Caduta di uno slave intermedio MasterI SlaveII Slave N  Salve Master I SlaveII Slave N  Salve I Slave

9 Progetto: analisi guasti(3) Caduta dell’ultimo slave MasterI SlaveII Slave N  Salve N-1 Slave Attesa nuovo slave

10 Struttura del master

11 Struttura dello slave

12 Comunicazione tra Demoni(1) La comunicazione tra demoni facenti parte della stessa applicazione avviene attraverso il Gestore dei Nomi che mette a disposizione un ambiente comune per il “dialogo”. Durante il normale funzionamento solo due Demoni hanno bisogno di scambiarsi le informazioni: nel caso master: DemonServer e DemonAggiorna nel caso slave: DemonAggiornato e DemonAggiorna Gestore Nomi DemonServer inserisci DemonAggiorna Aggiorna

13 Comunicazione tra Demoni(2) Quando si verificano guasti, si rende necessaria la comunicazione di più Demoni perché in base alla tipologia di guasto si devono prendere le opportune decisioni di terminazione o di attesa Passiamo ora a vedere i protocolli di comunicazione

14 Protocolli Comunicazione 1 Comunicazione tra server esterno e DemonServer Comunicazione tra cliente e DemonClient

15 Protocolli di Comunicazione 2 Comunicazione tra DemonAggiorna e DemonAggiornato Comunicazione per ingresso del master Gestore Nomi Entro Time out Master

16 Protocolli di comunicazione 3 Comunicazione tra DemonAttesa e nuova copia in arrivo Il master era in attesa Uno slave era in attesa

17 Protocolli di Comunicazione 4 Comunicazioni tra DemonLive e DemonLiveSlave Normale Segnale copia diventa master La copia deve sostituire lo slave intermedio caduto

18 Prototipo E’ stato realizzato un prototipo dell’applicazione nell’ambiente di sviluppo Java che realizza tutti gli obbiettivi che ci siamo posti all’inizio. Scelte fatte: I demoni sono stati realizzati attraverso Thread I demoni accedono alla struttura dove sono memorizzati i dati relativi ai server in modo mutuamente esclusivo Uso delle DatagramSocket e del protocollo UDP per lo scambio dei messaggi ulteriore struttura in cui vengono inseriti i messaggi di registrazione/ cancellazione dei server utilizzata per facilitare la fase stessa di aggiornamento.

19 Sviluppi futuri Estendere il prototipo affinchè possa funzionare con il multicast raffinare ulteriormente i protocolli per ridurre i tempi necessari alle varie copie per accorgersi di un problema gestire il caso dell’arrivo contemporaneo di due slave USI CONCRETI questa applicazione è utilizzata nel progetto di un collega di corso che ha realizzato un servizio di chat

20 Conclusioni La strutturazione del sistema in molti demoni è nata dalla necessità di avere un sistema estremamente “reattivo” nel senso che si voleva che il sistema fosse sempre pronto a fornire il servizio richiesto da entrambe le tipologie di utenti, delegando ad altri il compito di fornire un aggiornamento alle copie e di attenderne di nuove La scelta di fare l’aggiornamento ad ogni nuova richiesta dei server e di strutturare le copie in una “catena” è stata dettata dal fatto di avere le copie “quanto più calde possibili” per riuscire a garantire comunque un buon servizio aggiornato anche in caso di caduta del Master

21 Conclusioni L’applicazione realizzata si basa su protocolli e regole di interazione semplici, non bisogna farsi trarre in inganno dal numero di thread che la costituiscono, ogni thread realizza una sola funzionalità, così oltre che al requisito della semplicità guadagniamo anche in efficienza nei tempi di risposta. Inoltre questo ha permesso di sviluppare le varie parti del sistema in modo quasi indipendente e di capire molto velocemente la causa di malfunzionamenti riscontrati durante la stesura del codice