JDICS
Java Dynamic Infrastructure for C/S systems
Laura Galli matr.180699
Reti di calcolatori LS, Prof. A.Corradi
A.A 2004-05
Agenda



JDICS Architecture
 Client
 Proxy
 Broker
 Server
JDICS Interaction protocols
 Client-Proxy
 Proxy-Broker
 Server-Broker
 Broker-Broker
JDICS QoS (fault tolerance, load balancing)
JDICS architecture
Architecture


L’architettura di JDICS
consiste di quattro entità
fondamentali :
 Client
 Proxy
 Broker
 Server
Tali entità si trovano su due
livelli logici distinti :


livello applicativo
livello middleware
clients
proxy
server
brokers
Server


I server di JDICS sono oggetti remoti,
referenziabili via RMI da applicazioni Java
disposte fisicamente su nodi distinti.
Nell’ottica di una architettura fault tolerant, il
supporto prevede la possibilità di gestire la
replicazione a livello server, introducendo il
concetto di servizio o (cluster di servizio) e copia
server.
Server architecture
Un servizio è disponibile se esiste
almeno una copia server attiva in
grado di implementarlo.
Un servizio può essere con o
senza stato, ma la presenza del
cluster non deve modificare la
semantica RMI : lo stato deve
essere condiviso da tutte le copie
server
server
service
cluster
Counter service
cluster state
manager
Client


In JDICS i client sono
applicazioni Java, che per
realizzare la propria logica
applicativa necessitano di
servizi via RMI
Un client può conoscere a
priori il nome di un servizio
(staticamente), oppure può
scoprire i servizi disponibili
run-time (dinamicamente).
RMI
s1
s3
s1
Dynamic
or static ?
s2
Remote objects
(services)
Client requests…

Riferimento
a echo !
Quale
Quali
intefaccia
servizi
?
per echo ?
Un client può richiedere :



i servizi al momento
disponibili sulla rete
Ecco !
l’interfaccia di un particolare
servizio (metodo e
parametri)
il riferimento ad un
particolare servizio
counter,
String
echo…
echo(String)
counter
echo
Proxy




Chi risponde alle richieste dei
client ?
I client devono poter uscire dalla
loro località per esplorare la rete…
oppure possono delegare questo
compito ad una entità apposita : il
proxy.
Il proxy è una entità locale al nodo
ed è condiviso da tutti i client dello
stesso host.
Il proxy incapsula la capacità di un
host di conoscere lo stato della
rete
But how do
they know ?
???
net info…
???
Broker


???
I broker sono i punti di
riferimento assoluti per
una rete JDICS.
Lo scopo dei broker è
quello di creare un link tra
mondo client e mondo
server raccogliendo la
conoscenza (dinamica)
sullo stato della rete.
counter service
is available
with 2 copies at
192.168….
info…
counter
echo
accounting
billing
JDICS interaction
protocols
Server Insertion Protocol
Un server può essere la prima copia del
cluster, oppure può inserirsi in un cluster già
esistente
billing
billing
new server/ billing
service/acer-150
Ogni server conosce un indirizzo di multicast con
cui raggiungere tutti i broker della rete per inviare
la propria richiesta di registrazione
multicast
Il broker che gestisce la registrazione (server-token)
risponde al server inviando alla socket datagram un
pacchetto con l’ID
239.1.2.4
ID=2
datagram socket
acer-150
Il broker che gestisce la registrazione avverte tutti gli
altri broker via multicast, affinchè sappiano
new server/
dell’esistenza del nuovo server .
billingservice/ID=2
multicast
239.1.2.3
Proxy Insertion Protocol
Un proxy che voglia entrare nella rete ed
esplorarla deve avere il riferimento ad un
broker. Essendo i broker noti solo a run-time,
deve prima effettuare una registrazione per
ottenere un ID e un riferimento (remoto) ad
una entità broker.
new proxy/acer-150
Ogni proxy conosce un indirizzo di multicast con
cui raggiungere tutti i broker della rete per inviare
la propria richiesta di registrazione.
multicast
Il broker che gestisce la registrazione risponde al
proxy inviando alla socket datagram un pacchetto
con l’ID del proxy, il suo ID e il suo indirizzo RMI. Il
proxy recupera il riferimento al broker all’indirizzo
RMI fornitogli.
239.1.2.4
datagram socket
acer-150
Il broker che gestisce la registrazione avverte tutti gli
new proxy/ ID=123
altri broker via multicast, affinché sappiano
dell’esistenza del nuovo proxy a lui legato .
ID=123/RMiadd
r…
multicast
239.1.2.3
Broker Insertion Protocol
Un broker può essere il primo del sistema ed in
quel caso è l’iniziatore del sistema , oppure
deve inserirsi nel ring dei broker.
new broker/RMI addr…/
acer-150
Id=1
Nel caso in cui il ring sia già formato, il protocollo di
inserimento prevede :
Id=3
• invio in multicast della richiesta di inserimento
Id=4
• attesa di un numero di risposte pari alla cardinalità
del ring
• selezione del proprio predecessore
Id=…/
RMI addr/
#=3
Id=5
• determinazione del proprio ID
• invio del proprio ID al predecessore scelto (via RMI)
e raccolta delle informazioni sullo stato della rete
Id =1
Id =5
• fase di informazione (via multicast) della nuova
configurazione del ring agli altri broker
Id =4
Id =3
JDICS QoS
Fault tolerace, Load balancing
Broker failure
Se il server che vuole registrarsi non riceve
risposta da nessuno (time-out) invia (in
multicast) un messaggio di richiesta di aiuto a
tutti i broker.
I broker attivano una procedura di
identificazione del guasto :
• ogni broker controlla il proprio successore nel
ring
• il broker che rileva il guasto gestisce la
richiesta di registrazione (il broker guasto ha
portato alla perdita del server-token), avvia un
processo di riconfigurazione del ring
rimuovendo il nodo guasto e ripristina il token
server sul nuovo successore
S.O.S
Broker failure
Un broker può accorgersi del fallimento del
proprio successore nel momento in cui tenta di
passargli il token
Il broker attiva una procedura di
riconfigurazione dell’anello ripristinando il
token sul nuovo successore
Broker failure
Un broker nuovo che vuole inserirsi nel ring
può accorgersi di un guasto nel momento in
cui riceve un numero di answers inferiore alla
cardinalità dell’anello comunicatagli.
Il nuovo broker avverte uno dei pari che gli ha
risposto indicandogli da chi ha ricevuto
answers.
Il broker informato individua il broker che non
ha risposto, verifica il guasto e attiva una
procedura di riconfigurazione in cui il nuovo
broker prende il posto di quello fallito
(compresi gli eventuali token).
!
Broker failure
Errore
!
Un proxy può accorgersi del fallimento del
proprio broker nel momento in cui lo referenzia
(via RMI )per ottenere dei servizi.
1
Help !
Broker 1
failed
Il proxy invia una richiesta di aiuto (via
multicast) indicando il broker che non gli ha
risposto.
1
Il proxy invia una richiesta di aiuto (via
multicast) indicando il broker che non gli ha
risposto.
2
Il predecessore del broker fallito, risponde al
proxy via socket datagram e si propone come
nuovo riferimento.
Il predecessore fa la stessa cosa per tutti i
proxy che erano legati al broker fallito
Il predecessore del broker fallito avvia la
procedura di riconfigurazione del ring
avvertendo i suoi peer.
5
id=5/RMIaddr
…
2
5
Server failure
Errore !
Il guasto di un server può essere rilevato da un
client che lo utilizza. Il client infatti può riceve
una eccezione nel momento in cui lo riferisce.
Il client avverte il suo proxy, che a sua volta
avverte il suo broker
Il broker consegna al proxy un nuovo
riferimento e il proxy a sua volta provvede a
passare il nuovo riferimento al client.
Errore !
Errore !
Load balancing
Il load balancing è implementato mediante la
tecnica del reference-counting.
E’ compito del broker realizzare la politica di
load balancing nell’ambito di ciascun cluster,
provvedendo ad assegnare (come riferimento)
ad ogni richiesta la copia più “libera.”
21
2
echo
2