Corso di Reti di Calcolatori LSProf. Antonio Corradi

Corso di Laurea in Ingegneria InformaticaFacoltà di Ingegneria – A.A. 2005/2006

Università degli studi di Bologna

Progetto di Roberta Calegari

Lo scopo del progetto è realizzare una semplice applicazione distribuita che preveda l’utilizzo di stampanti comuni. Nello svolgimento si vogliono trattare le tematiche che tipicamente emergono nella realizzazione nel distribuito:

• apertura e scalabilità• trasparenza • replicazione e fault toleranceAl 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)

Tecnologia implementativa scelta: JavaJava; risponde infatti a tutte le esigenze nate in fase di progettazione.

Il protocollo di discoverydiscovery 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 lookupService

lookupServiceaddressWSPmaster/ addressBis bisWSP

discovery lookupService server

lookupServiceaddressWRP

discovery lookupService client

lookupServiceaddressWRP

Un sistema a risorse condivise che vuole rispondere ai requisiti di apertura e dinamicità vede come necessaria la presenza di un

servizio di LookupLookup 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 replicazione calda di risorse software.

L’architettura 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).

Per la tolleranza ai guasti si è fatta un’ipotesi di guasto singolo:ipotesi di guasto singolo:• caduta del mastercaduta del master• caduta dell’utlimo slavecaduta dell’utlimo slave• caduta di un nodo intermediocaduta di un nodo intermedio

WSP/MP

MULticastPortMULticastPort: 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 l’entità si configura come slave, altrimenti si aggancia alla catena diventando l’ultimo slave.

SUP UP

MSP

Upgrade List

ServiceTable

MUL

• WaitingSlavePortWaitingSlavePort: su questa porta l’ultimo slave della catena attende un nuovo slave

• MonitorPortMonitorPort: se non si è l’ultimo slave la porta di waiting non deve essere attiva; si deve però comunicare con lo slave in modo da farsi monitorare

• MonitorSlavePortMonitorSlavePort: su questa porta lo slave controlla il suo predecessore

• UpgradePortUpgradePort: da questa porta si mandano gli aggiornamenti al successore

• SlaveUpgradePortSlaveUpgradePort: su questa porta si ricevono gli aggiornamenti dal predecessore

• WaitingRequestPortWaitingRequestPort: se si è master un demone resta in ascolto di richieste

discovery lookupService lookupService

lookupServiceaddressWSPmaster/ addressBis bisWSP

WRP

ID

port addressinterface

HPInkJet5000 3032

127.0.0.1PRINT

ready

Upgrade List

MP

UP

WSP

SUP

MSPlivelive

ready UP bisUP UP

Il funzionamento a regime del Lookup può essere così schematizzato:

slaveUpgradePort

WRP

registartion interfaceaddressportID

deleteinterfaceaddressportID

lookingForID

lookingForInterfaceinterface

WRP

Master Slave I

WSP

SUP

MSPMP

UP

Masterlivelive

livelive

L’architettura realizzata prevede tre ipotesi di guasto:1.1.caduta del mastercaduta del master

MP

UPSUP

MSP

WRPchangeLookupService addressport

Invio di un messaggio multicast per avvisare eventuali client del cambiamento del master.

Master Slave I Slave IIMaster

WSP

SUP

MSPMP

UP

MP

UPSUP

MSP

Problems MSP SUP

Master Slave myMasterAddr myMasterWSP myMasterUP

livelive

livelive

L’architettura realizzata prevede tre ipotesi di guasto:2.2.caduta di uno slave intermediocaduta di uno slave intermedio

master Slave I Slave II

MP

UP

WSP

SUP

MSP

Terminate

livelive

live

liveMP

UP

MP

UP

L’architettura realizzata prevede tre ipotesi di guasto:3.3.caduta dell’ultimo slavecaduta dell’ultimo slave

WSP

SUP

MSP

master Slave I Slave II

WRP

TCPEP

ResourcePrinter

Request queue

Le funzionalità della risorsa stampante sono espletate da due demoni attivi (per tutto il tempo di vita dell’applicazione) su due porte diverse.

• WaitingRequestPortWaitingRequestPort: porta di attesa richieste di stampa da parte del client• ExecutePortExecutePort: porta su cui è attivo il demone che si occupa della vera gestione della richiesta. Prevede l’attivazione di una connessione sulla porta TCPporta TCP, dove attende lo stream di dati da stampare da parte del client.

Anche in questo caso l’ipotesi di guasto fatta prevede il caso di guasto guasto singolosingolo:• caduta della risorsa stampante• caduta del client (tempo di leaselease)

La realizzazione della risorsa stampante risorsa stampante prende in esame la replicazione fredda delle replicazione fredda delle risorserisorse. Solo in caso di guasto della risorsa si effettua la sua sostituzione, in modo trasparente all’utente.

ResourcePrinter

Client

Request queue

clientIDaddressport

CP

WRP

TCPIDresourceaddressTCPport

TCP

TCPEP

Il comportamento a regime di una risorsa è attendere richieste dal cliente sulla porta WRPWRP. La richiesta prevede l’invio 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).

Il demone incaricato di eseguire la prima richiesta in coda provvederà ad aprire una connessione TCP con il cliente, aprendo una aprendo una ServerSocket sulla porta TCPPort 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.

L’architettura realizzata prevede due fasi relative all’ipotesi guasto:1.1.caduta della risorsa/client prima della connessione TCPcaduta 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

clientIDaddressport

CP

ResourcePrinter

WRP

EP

CPWRP

2.2. caduta della risorsa/client durante connessione TCP caduta della risorsa/client durante connessione TCP stabilitastabilita

Client

clientIDaddressport

ResourcePrinter

TCPTCP

Introduzione tempo di tempo di lease lease entro il quale il client deve mandare un messaggio per mantenere impegnate le risorse. Lato client l’errore di non poter scrivere sulla socket produce il messaggio “risorsa non raggiungibile”.

WTP

WRP

ResourceManager

Replicazione Servizio

La realizzazione del gestore delle risorse gestore delle risorse prevede una replicazione tiepidareplicazione tiepida con architettura a architettura a catena PASSIVA di tipo master/slavecatena 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 caricobilanciamento del carico:• WaitingRequestPortWaitingRequestPort: attende registrazione da parte di stampanti e richieste da parte del cliente• WaitingTerminationPortWaitingTerminationPort: 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.

L’ipotesi di guasto fatta è quella di guasto singologuasto singolo.

127.0.0.1

ID

port addressinterface

HPInkJet5000 3032

PRINT

#request

0

WTP

WRP

ResourcePrinter

ResourceManager

Client

Request queue

registration interface address port IDResource

(1)

(2) O

K

clientIDaddressport

(3)

clientIDaddressport

(4) CP

WRP

TCPIDresourceaddressTCPport

(5)

TCP

(6)

IDresourceterminate

(7)

TCPEP

Le richieste alle risorse arrivano in questo caso in modo mediato, passando

attraverso il gestore che ha appunto il ruolo di mediatoremediatore.

L’architettura realizzata prevede due ipotesi guasto:1.1.caduta del gestorecaduta del gestore: l’architettura è la stessa del servizio di Lookup; identificazione guasto e recovery sono quindi analoghe2.2.caduta di una risorsacaduta di una risorsa

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 trasparente all’utenteall’utente.

ResourceManager

ResourcePrinter

ResourcePrinter

ResourcePrinter

Il prototipo del sistema è stato realizzato in Java Java (demoni realizzati come ThreadThread). Il sistema è stato testato su una rete di 5 computer.• Il protocollo di discoverydiscovery è stato implementato utilizzando le socket multicastsocket multicast, basate sul protocollo UDPprotocollo UDP.• Per la realizzazione dei servizi si è scelto di utilizzare sempre le DatagramSocketDatagramSocket (protocollo UDP) tranne per la connessione tra client e risorsa, dove si è ritenuta idonea una connessione TCP (attraverso l’uso di SocketSocket e ServerSocketServerSocket).

Nel progetto svolto vengono affrontate le tematiche/problematiche vengono affrontate le tematiche/problematiche di un sistema distribuito che ha come fine la condivisione di di un sistema distribuito che ha come fine la condivisione di risorserisorse. In particolare si affrontano le tematiche di replicazione (calda, tiepida, fredda), dinamicità ed apertura, e tolleranza ai guasti.

Concetto rilevante nella realizzazione: struttura struttura semplicesemplice che usa che usa protocolli sempliciprotocolli semplici.

Possibili estensioniestensioni:

• 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