Corso di Laurea in Ingegneria Informatica
Facoltà di Ingegneria – A.A. 2005/2006
Università degli studi di Bologna
Corso di Reti di Calcolatori LS
Prof. Antonio Corradi
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 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)
Tecnologia implementativa scelta: Java; risponde infatti a tutte le esigenze nate in fase
di progettazione.
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
lookupService
address
WSP
master/ addressBis bisWSP
discovery
lookupService
lookupService
• nuova entità Server (ResourceManager, Resource) e nuova entità Client
discovery
lookupService
server
discovery
lookupService
client
lookupService
address
WRP
lookupService
address
WRP
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.
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:
• caduta del master
• caduta dell’utlimo slave
• caduta di un nodo intermedio
Service
Table
ID
HPInkJet5000
MSP
interface
PRINT
WSP/
MP
port
MUL
3032
WRP
SUP
UP
discovery
lookupService
lookupService
lookupService
address
WSP
master/ addressBis bisWSP
address
127.0.0.1
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 l’entità si configura come slave, altrimenti si
aggancia alla catena diventando l’ultimo slave.
Upgrade
List
• WaitingSlavePort: su questa porta l’ultimo slave della catena attende un nuovo slave
• MonitorPort: 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
• MonitorSlavePort: su questa porta lo slave controlla il suo predecessore
• UpgradePort: da questa porta si mandano gli aggiornamenti al successore
• SlaveUpgradePort: su questa porta si ricevono gli aggiornamenti dal predecessore
• WaitingRequestPort: se si è master un demone resta in ascolto di richieste
delete
lookingFor
interface
ID
address
Ilregistartion
funzionamentoport
a regime del Lookup
ID
interface
address
port
ID
WRP
MP
può essere
così schematizzato:
lookingForInterface
interface
live
live
MSP
Master
WSP
Slave I
ready UP bisUP
UP
Upgrade
List
ready
SUP
UP
slave
UpgradePort
L’architettura realizzata prevede tre ipotesi di guasto:
1. caduta del master
MP
live
live
MSP
MP
Master live
live
MSP
WSP
WRP
changeLookupService
address
port
Master
UP
Slave I
Master
SUP
UP
Slave II
SUP
Invio di un messaggio multicast per avvisare eventuali client del cambiamento del
master.
L’architettura realizzata prevede tre ipotesi di guasto:
2.
caduta di uno slave intermedio
MP
live
live
MSP
Master
master
UP
Problems MSP SUP
live
MP
live
Slave
myMasterAddr
myMasterWSP
myMasterUP
MSP
Slave II
Slave I
SUP
UP
WSP
SUP
L’architettura realizzata prevede tre ipotesi di guasto:
3.
caduta dell’ultimo slave
live
MP
live
MSP
MP
WSP
live
live
MSP
WSP
Terminate
master
UP
Slave II
Slave I
SUP
UP
SUP
Request queue
WRP
Resource
Printer
EP
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
all’utente.
TCP
Le funzionalità della risorsa stampante sono espletate da due demoni attivi (per tutto il
tempo di vita dell’applicazione) su due porte diverse.
• WaitingRequestPort: porta di attesa richieste di stampa da parte del client
• ExecutePort: porta su cui è attivo il demone che si occupa della vera gestione della
richiesta. Prevede l’attivazione di una connessione sulla porta 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 singolo:
• caduta della risorsa stampante
• caduta del client (tempo di lease)
Il comportamento a regime di una risorsa è attendere
richieste dal cliente sulla porta WRP. La richiesta
prevede l’invio dei dati del cliente stesso.
Client
CP
client
ID
address
port
TCP
TCP
IDresource
address
TCPport
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 ServerSocket sulla porta TCPPort
WRP
e rimanendo in attesa di una richiesta di connessione
Resource
dal client (che deve avvenire entro un timeout). I dati
Printer
relativi alla porta di attesa della risorsa vengono
quindi comunicati al client, in modo che possa aprire
EP
TCP
la connessione.
Sfruttando la connessione TCP il client può inviare alla stampante il file da stampare ed essa
può quindi procedere nella stampa.
Request queue
L’architettura realizzata prevede due fasi relative all’ipotesi guasto:
1. caduta della risorsa/client prima della connessione TCP
WRP
client
ID
Resource
address
Printer
port
CP
Client
EP
2.
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.
caduta della risorsa/client durante connessione TCP stabilita
TCP
client
ID
Resource
address
port
Printer
TCP
Client
Introduzione tempo di 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”.
Replicazione
Servizio
WRP
ID
Resource
interface
Manager
PRINT
HPInkJet5000
port
3032
WTP
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
address
in modo #request
da poter svolgere il compito di bilanciamento del
carico:
127.0.0.1
0
• WaitingRequestPort: attende registrazione da parte di
stampanti e richieste da parte del cliente
• 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.
L’ipotesi di guasto fatta è quella di guasto singolo.
(3)
client
ID
address
port
WRP
Client
Resource
Manager
client
ID
address
port
(2)
OK
Request queue
WTP
TCP
CP
(4)
(5)
TCP
IDresource
address
TCPport
WRP
(1)
registration
interface
address port
IDResource
(7)
(6)
Resource
Printer
EP
TCP
IDresource
terminate
Le richieste alle risorse arrivano in questo caso in modo mediato, passando attraverso il
gestore che ha appunto il ruolo di mediatore.
L’architettura realizzata prevede due ipotesi guasto:
1. caduta del gestore: l’architettura è la stessa del servizio di Lookup;
identificazione guasto e recovery sono quindi analoghe
2. caduta 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 all’utente.
Resource
Manager
Resource
Printer
Resource
Printer
Resource
Printer
Il prototipo del sistema è stato realizzato in Java (demoni realizzati come
Thread). Il sistema è stato testato su una rete di 5 computer.
• Il protocollo di discovery è stato implementato utilizzando le socket multicast,
basate sul protocollo UDP.
• 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 l’uso di
Socket e ServerSocket).
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.
Concetto rilevante nella realizzazione: struttura semplice che usa protocolli semplici.
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