La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Corso di Reti di Calcolatori LS Prof. Antonio Corradi Corso di Laurea in Ingegneria Informatica Facoltà di Ingegneria – A.A. 2005/2006 Università degli.

Presentazioni simili


Presentazione sul tema: "Corso di Reti di Calcolatori LS Prof. Antonio Corradi Corso di Laurea in Ingegneria Informatica Facoltà di Ingegneria – A.A. 2005/2006 Università degli."— Transcript della presentazione:

1 Corso di Reti di Calcolatori LS Prof. Antonio Corradi Corso di Laurea in Ingegneria Informatica Facoltà di Ingegneria – A.A. 2005/2006 Università degli studi di Bologna Progetto di Roberta Calegari

2 Lo scopo del progetto è realizzare una semplice applicazione distribuita che preveda lutilizzo di stampanti comuni. Nello svolgimento si vogliono trattare le tematiche che tipicamente emergono nella realizzazione nel distribuito: apertura e scalabilità trasparenza replicazione e fault tolerance Al fine di affrontare le tematiche proposte il progetto si occupa della realizzazione di: protocollo di discovery (apertura e scalabilità) servizio di lookup (replicazione calda e trasparenza) servizio di stampa (replicazione fredda) gestore di un pool di risorse (replicazione tiepida e bilanciamento del carico) Java Tecnologia implementativa scelta: Java; risponde infatti a tutte le esigenze nate in fase di progettazione.

3 discovery Il protocollo di discovery permette ad una nuova entità di entare nel sistema, scoprendo le risorse e i servizi attivi in quel momento. Il servizio base, per cui ogni entità chiederà al momento di ingresso nel sistema, è il servizio di Lookup. Il protocollo realizzato prevede che la nuova entità invii in multicast un messaggio discovery che contenga il nome di ciò che si sta cercando (Lookup) e che tipo di entità lo sta cercando (Lookup, Server, Client). nuova entità Lookup nuova entità Server (ResourceManager, Resource) e nuova entità Client discovery lookupService address WSP master/ addressBis bisWSP discovery lookupService server lookupService address WRP discovery lookupService client lookupService address WRP

4 Lookup replicazione calda Un sistema a risorse condivise che vuole rispondere ai requisiti di apertura e dinamicità vede come necessaria la presenza di un servizio di Lookup che permetta ad una nuova entità (client/server) di agganciarsi al sistema stesso scoprendo le risorse a disposizione. Questo servizio, che possiamo vedere come risorsa del sistema, risulta quindi essenziale per il funzionamento e permette di esaminare la replicazione calda di risorse software. Larchitettura scelta per la replicazione del servizio è quella di un sistema a catena in cui e presente un solo master che esegue le richieste ricevute dai nodi del sistema e si occupa poi di aggiornare le risorse (replicazione PASSIVA). ipotesi di guasto singolo: Per la tolleranza ai guasti si è fatta unipotesi di guasto singolo: caduta del master caduta del master caduta dellutlimo slave caduta dellutlimo slave caduta di un nodo intermedio caduta di un nodo intermedio

5 WSP/ MP MULticastPort MULticastPort: porta di multicast necessaria per il discovery Quando nasce un LookUpService manda un messaggio multicast per sapere se ci sono altri LookUpServices nel sistema. Allo scadere di un timeout, se nessuna risposta è stata ricevuta lentità si configura come slave, altrimenti si aggancia alla catena diventando lultimo slave. SUPUP MSP Upgrade List Service Table MUL WaitingSlavePort WaitingSlavePort: su questa porta lultimo slave della catena attende un nuovo slave MonitorPort MonitorPort: se non si è lultimo slave la porta di waiting non deve essere attiva; si deve però comunicare con lo slave in modo da farsi monitorare MonitorSlavePort MonitorSlavePort: su questa porta lo slave controlla il suo predecessore UpgradePort UpgradePort: da questa porta si mandano gli aggiornamenti al successore SlaveUpgradePort SlaveUpgradePort: su questa porta si ricevono gli aggiornamenti dal predecessore WaitingRequestPort WaitingRequestPort: se si è master un demone resta in ascolto di richieste discovery lookupService address WSP master/ addressBis bisWSP WRP ID portaddressinterface HPInkJet PRINT

6 ready Upgrade List MP UP WSP SUP MSP live ready UP bisUP UP Il funzionamento a regime del Lookup può essere così schematizzato: slave UpgradePort WRP registartion interface address port ID delete interface address port ID lookingFor ID lookingForInterface interface WRP MasterSlave I

7 WSP SUP MSP MP UP live Master live Larchitettura realizzata prevede tre ipotesi di guasto: 1.caduta del master MP UPSUP MSP WRP changeLookupService address port Invio di un messaggio multicast per avvisare eventuali client del cambiamento del master. Master Slave I Slave II Master

8 WSP SUP MSPMP UP MP UPSUP MSP Problems MSP SUP live Master Slave myMasterAddr myMasterWSP myMasterUP live Larchitettura realizzata prevede tre ipotesi di guasto: 2.caduta di uno slave intermedio master Slave I Slave II

9 MP UP WSP SUP MSP live Terminate live MP UP MP UP Larchitettura realizzata prevede tre ipotesi di guasto: 3.caduta dellultimo slave WSP SUP MSP master Slave I Slave II

10 WRP TCP EP Resource Printer Request queue Le funzionalità della risorsa stampante sono espletate da due demoni attivi (per tutto il tempo di vita dellapplicazione) su due porte diverse. WaitingRequestPort WaitingRequestPort: porta di attesa richieste di stampa da parte del client ExecutePort porta TCP ExecutePort: porta su cui è attivo il demone che si occupa della vera gestione della richiesta. Prevede lattivazione di una connessione sulla porta TCP, dove attende lo stream di dati da stampare da parte del client. guasto singolo Anche in questo caso lipotesi di guasto fatta prevede il caso di guasto singolo: caduta della risorsa stampante lease caduta del client (tempo di lease) risorsa stampante replicazione fredda delle risorse La realizzazione della risorsa stampante prende in esame la replicazione fredda delle risorse. Solo in caso di guasto della risorsa si effettua la sua sostituzione, in modo trasparente allutente.

11 Resource Printer Client Request queue client ID address port CP WRP TCP IDresource address TCPport TCP EP WRP Il comportamento a regime di una risorsa è attendere richieste dal cliente sulla porta WRP. La richiesta prevede linvio dei dati del cliente stesso. Una volta ricevuta la richiesta viene accodata nella lista delle richieste della stampante e, quando prima in coda, viene gestita (politica FIFO possibilità di estendere con nuove politiche). aprendo una ServerSocket sulla porta TCPPort Il demone incaricato di eseguire la prima richiesta in coda provvederà ad aprire una connessione TCP con il cliente, aprendo una ServerSocket sulla porta TCPPort e rimanendo in attesa di una richiesta di connessione dal client (che deve avvenire entro un timeout). I dati relativi alla porta di attesa della risorsa vengono quindi comunicati al client, in modo che possa aprire la connessione. Sfruttando la connessione TCP il client può inviare alla stampante il file da stampare ed essa può quindi procedere nella stampa.

12 live Larchitettura realizzata prevede due fasi relative allipotesi guasto: 1.caduta della risorsa/client prima della connessione TCP Le porte per lo scambio di messaggi sono se non ricevono messaggi si accorgono del guasto, lo comunicano in multicast e tronano al funzionamento a regime. Client client ID address port CP Resource Printer WRP EP CPWRP 2.caduta della risorsa/client durante connessione TCP stabilita Client client ID address port Resource Printer TCP tempo di lease Introduzione tempo di lease entro il quale il client deve mandare un messaggio per mantenere impegnate le risorse. Lato client lerrore di non poter scrivere sulla socket produce il messaggio risorsa non raggiungibile.

13 WTP WRP Resource Manager Replicazione Servizio gestore delle risorse replicazione tiepidaarchitettura a catena PASSIVA di tipo master/slave bilanciamento del carico La realizzazione del gestore delle risorse prevede una replicazione tiepida con architettura a catena PASSIVA di tipo master/slave. I demoni relativi alla gestione della replicazione sono analoghi a quelli illustrati per il servizio di Lookup. In aggiunta sono presenti due demoni per la gestione delle risorse in modo da poter svolgere il compito di bilanciamento del carico: WaitingRequestPort WaitingRequestPort: attende registrazione da parte di stampanti e richieste da parte del cliente WaitingTerminationPort WaitingTerminationPort: attende messaggi di terminazione da parte delle stampanti gestite, in modo da poter aggiornare il numero di richieste accodate su quella risorsa. Resource Table La struttura dati principale è una tabella che mantiene un elenco centralizzato delle risorse attive a cui è possibile smistare richieste. Per svolgere il compito di bilanciamento carico è necessario un attributo aggiuntivo che memorizza il numero di richieste in coda su ciascuna risorsa. guasto singolo Lipotesi di guasto fatta è quella di guasto singolo ID portaddressinterface HPInkJet PRINT #request 0

14 WTP WRP Resource Printer Resource Manager Client Request queue registration interface address port IDResource (1) (2) OK client ID address port (3) client ID address port (4) CP WRP TCP IDresource address TCPport (5) TCP (6) IDresource terminate (7) TCP EP mediatore Le richieste alle risorse arrivano in questo caso in modo mediato, passando attraverso il gestore che ha appunto il ruolo di mediatore.

15 live Larchitettura realizzata prevede due ipotesi guasto: 1.caduta del gestore 1.caduta del gestore: larchitettura è la stessa del servizio di Lookup; identificazione guasto e recovery sono quindi analoghe 2.caduta di una risorsa trasparente allutente Il gestore prova ad inoltare la richiesta ad una risorsa, ma non riesce a comunicare. Elimina la risorsa dal suo elenco centralizzato rilevando il guasto e provvede a smistare la richiesta su una risorsa diversa. Il tutto avviene in modo trasparente allutente. Resource Manager Resource Printer Resource Printer Resource Printer

16 Java Thread Il prototipo del sistema è stato realizzato in Java (demoni realizzati come Thread). Il sistema è stato testato su una rete di 5 computer. discovery socket multicast protocollo UDP Il protocollo di discovery è stato implementato utilizzando le socket multicast, basate sul protocollo UDP. DatagramSocket Socket ServerSocket Per la realizzazione dei servizi si è scelto di utilizzare sempre le DatagramSocket (protocollo UDP) tranne per la connessione tra client e risorsa, dove si è ritenuta idonea una connessione TCP (attraverso luso di Socket e ServerSocket).

17 vengono affrontate le tematiche/problematiche di un sistema distribuito che ha come fine la condivisione di risorse Nel progetto svolto vengono affrontate le tematiche/problematiche di un sistema distribuito che ha come fine la condivisione di risorse. In particolare si affrontano le tematiche di replicazione (calda, tiepida, fredda), dinamicità ed apertura, e tolleranza ai guasti. struttura semplice che usa protocolli semplici Concetto rilevante nella realizzazione: struttura semplice che usa protocolli semplici. estensioni Possibili estensioni : ampliamento dei servizi forniti (come gestione di file comuni o accesso ad un database) estendere le politiche di gestione delle risorse e delle richieste cliente raffinamento dei protocolli per velocizzare lo scambio di informazioni potrebbe aumentare le performance del sistema


Scaricare ppt "Corso di Reti di Calcolatori LS Prof. Antonio Corradi Corso di Laurea in Ingegneria Informatica Facoltà di Ingegneria – A.A. 2005/2006 Università degli."

Presentazioni simili


Annunci Google