Supporto in RMI per la collaborazione in rete

Transcript

Supporto in RMI per la collaborazione in rete
Supporto in RMI per la collaborazione in rete
Autore Vincenzo Coco
([email protected])
Il framework che ho sviluppato segue questa linea di
Corso di Reti di Calcolatori
2006/2007
principio eLS
anche
se in stato primordiale rispetto ai
professore Antonio
supportiCorradi
esistenti, certamente più robusti, è stato un buon
inizio per prendere coscienza delle variabili incognite della
comunicazione in rete.
Abstract
Java Rmi è una tecnologia orientata ai servizi mentre una
collaborazione di utenti è in orientata all'applicazione.
Nulla vieta, al supporto creato, di poter essere utilizzato per
l'erogazione di un servizio, naturalmente un servizio creato
in questo modo risulta meno efficiente di un servizio
progettato ad hoc in RMI.Nonostante questo, è molto più
semplice sviluppare servizi o applicazioni con questo
framework, quindi uno sviluppatore poco esperto può
avvalersi di questa scelta.
Nella sezione relativa all'
parlerò in modo
sommario delle parti che costituiscono il sistema, del motivo
per cui sono state introdotte e del loro ruolo nel supporto.
Nella parte relativa alla
descriverò come le
parti dialoghino fra di loro per offrire connettività a livello
utente.
Il paragrafo
spiega i meccanismi che vengono
innescati quando avviene un guasto di rete e delle
perturbazioni di questi sul sistema.
La sezione
illustra quali sono le politiche
per offrire un servizio di bilanciamento del carico in modo
da rendere il sistema bilanciato in modo equo.
Infine descriverò una
di esempio che utilizza
1. Introduzione
queste
caratteristiche
per
offrire
un
servizio
di lavagna
La capacità di comunicare è una delle facoltà che rende
gli essere umani unici nel loro genere, con l'avvento delle condivisa fra un numero di utenti arbitrario e i effettuati
sia a livello di supporto che di applicazione.
tecnologie informatiche e della rete questa capacità ha
assunto caratteristiche sempre più accentuate, tanto che,
è possibile comunicare con un altro individuo e per fino 2. Architettura
Il sistema di supporto è composto principalmente da:
con più individui contemporaneamente, situati al lato
Mediator
opposto del mondo.
Queste tecnologie telecomunicative sono, tuttora, in via di Collaboration
sviluppo e così anche il software di supporto che rende la MessageQueue
Message
comunicazione fruibile per ogni tipologia di utente.
UserID
Esistono dei software specializzati in determinati ambiti
comunicativi e la loro architettura logica si basa su scelte
di progetto idonee per soddisfare obiettivi presupposti 2.1 Mediatore
Il mediatore costituisce il cuore del supporto e il suo scopo
alla creazione dello stesso progetto.
è quello di mediare la comunicazione fra gli utenti e
Il framework che ho sviluppato segue questa linea di
mantenere aggiornata la lista di quelli attualmente collegati.
principio e anche se in stato primordiale rispetto ai
supporti esistenti, certamente più robusti, è stato un buon Il mediatore svolge la funzione di Broker e quindi offre
inizio per prendere coscienza delle variabili incognite della primitive di comunicazione quali l'invio di messaggi da un
comunicazione in rete.
utente all'altro e la possibilità di effettuare un broadcast a
1
tutti gli utenti (discusse nel dettaglio nella sezione
comunicazione).
Il sistema proposto è un framework per lo sv iluppo di
applicazioni in rete in un ambiente collaborativ o per
utenti che v ogliono comunicare fra loro.
Lo scopo del progetto è quello di rendere lo sv iluppo
di applicazioni in rete, in questo ambiente, più
semplice cercando di aggirare le problematiche di
lav orare a liv ello più basso, eliminare i problemi di
sincronizzazione, offrire primitiv e di comunicazione a
più alto liv ello di astrazione, rendere il serv izio
architettura
affidabile introducendo politiche di qualità di serv izio
e replicazione.
Il framework è stato implementato in Jav a Rmi che
comunicazione
offre la comunicazione in rete tramite l'uso di Prox y
ma lascia in sospeso questioni come la trasparenza di
locazione e l'ampliamento del classico modello
replicazione
client/serv er.
Jav a Rmi è comunque una scelta v alida per la
creazione di un supporto come quello che ho
qualità di serv izio
descritto.
applicazione
test
Il mediatore svolge la funzione di Broker e quindi offre
primitive di comunicazione quali l'invio di messaggi da un
utente all'altro e la possibilità di effettuare un broadcast a
tutti gli utenti (discusse nel dettaglio nella sezione
comunicazione).
Essendo un oggetto che deve essere conosciuto dagli
utenti il mediatore è un oggetto remotizzabile e
naturalmente permette la registrazione, la cancellazione di
un utente e il prelievo della lista utenti.
Il mediatore si registra al RMIRegistry locale per offrire
connettività alle collaborazioni e svolge le lookup sui
registri degli altri mediatori in lista (vedi sezione
replicazione) tramite la
.
L'associazione utente/collaborazione è unica e viene
mantenuta dal mediatore.
La
svolge una lookup sui registry in lista disponibili
alla ricerca di mediatori per la connettività (vedi sezione
replicazione).
connect
connect
2.4 Messaggio
2.2 Utente
Figura Collaborazione
Il messaggio è un oggetto serializzabile e incapsula il
mittente, il destinatario, un etichetta, i dati e un identificativo
mentre non esistono messaggi tipati.
Nel caso di una broadcast il destinatario è assente.
L'identificativo viene assegnato dalla collaborazione in
modo incrementale ogni qualvolta si effettua una
send/broadcast.
Figura Mediator
Un utente è un oggetto serializzabile che possiede delle
proprietà che possono essergli assegnate in modo
arbitrario, utile nel caso di assegnazione di un nome, una
password o una qualunque altra proprietà che lo
caratterizza. Importante è la proprietà ID che è un
identificativo assegnato dal mediatore stesso all'atto della
registrazione e l'hash costituito dalla combinazione di ID,
nome e mediatore.
Figura Messaggio
2.3 Collaborazione
2.5 MessageQueue
Figura Utente
Un utente è sempre parte di una collaborazione il cui
scopo è quello di permettere l'invio di messaggi e la
ricezione di messaggi destinati all'utente stesso.
La collaborazione rappresenta l'interfaccia fra
l'applicazione utente e il mediatore in modo da rendere
più trasparente questa comunicazione.
Inoltre è necessario estendere la collaborazione per
creare applicazioni personalizzate secondo il tipo di
messaggi scelti per lo scambio di informazioni.
L'associazione utente/collaborazione è unica e viene
mantenuta dal mediatore.
La coda dei messaggi permette l'inserimento, il prelievo e
la rimozione di un messaggio.Questa classe viene utilizzata
dal mediatore per contenere i messaggi da smistare.
I messaggi sono ordinati secondo una coda FIFO, quindi,
un eventuale ordinamento coerente dovrà essere
implementato a livello applicativo, così come eventuali
politiche di ritrasmissione dei messaggi non ricevuti.
2
3.1 Send
Nel caso di una
il mediatore cerca la collaborazione a
cui è associato l'utente destinatario e se lo trova in lista
chiama la
della collaborazione corrispondente.In
caso contrario comunica con gli altri mediatori a cui è
connesso(vedi sezione replicazione) per la ricerca
dell'utente se anche questa non va a buon fine si richiama la
send su tutti gli altri mediatori che ripetono a loro volta la
stessa operazione.
La
è sincrona e il suo valore di ritorno dipende dal
valore di ritorno della
corrispondente se l'utente
viene trovato, in caso contrario il valore di ritorno è false.
La
è asincrona e deposita semplicemente il
messaggio nella coda del mediatore.
Successivamente il MessageConsumer recupererà il
messaggio dalla coda e lo passerà al mediatore per lo
smistamento.
send
notify
Figura CodaMessaggi
2.5 Architettura generale
send
notify
firesend
3. Comunicazione
Figura Send
3.2 Broadcast
Il modello di comunicazione è a scambio di messaggi e le
primitive di comunicazione offerte all'applicazione sono:
send (Message)
firesend (Message)
broadcast (Message)
firebroadcast (Message)
notify (Message)
Nel caso di un
il mediatore chiama la
di
tutte le collaborazione a cui sono associati gli utenti e
comunica con tutti gli altri mediatori conosciuti (vedi sezione
replicazione) chiamando la
su di essi, che
svolgono quindi la medesima operazione.
La
è sincrona e il suo valore di ritorno dipende
dal valore di ritorno delle
corrispondenti, in dettaglio
restituisce un valore positivo se tutte le
hanno
Quando una
o una
viene effettuata su ritornato un valore positivo, in caso contrario il valore di
una collaborazione, questa chiama la rispettiva primitiva ritorno è false.
del mediatore che si occupa dello smistamento.
La
è asincrona e deposita semplicemente il
Il routing a livello di messaggio tra i mediatori segue uno messaggio nella coda del mediatore.
schema a flooding finchè non viene ricevuto il messaggio Successivamente il MessageConsumer recupererà il
da tutti gli utenti (caso broadcast) o dall'utente interessato messaggio dalla coda e lo passerà al mediatore per lo
(caso send).
smistamento.
Il meccanismo che permette la ricezione di un messaggio
tramite la
è la callBack che il mediatore può
svolgere perché possiede un istanza di ogni
collaborazione attiva.
broadcast
notify
broadcast
broadcast
notify
notify
send
broadcast
firebroadcast
notify
3.1 Send
3
<IP> è l'indirizzo IP della macchina
<PORTA> è la porta servita dal RmiRegistry
<MEDIATOR> è il nome logico del servizio mediatore
Figura Broadcast
4. Replicazione
La replicazione nel supporto è implementata solo per i
mediatori, i quali sono collegati fra di loro in una rete
Mesh, più o meno fitta, secondo il grado di conoscenza
che un mediatore ha degli altri mediatori.
All'avvio di un mediatore, questo cerca di collegarsi agli
altri mediatori in lista per la creazione del cluster.
Il grado di replicazione e di tolleranza ai guasti dipende,
quindi, dal numero di mediatori presenti nel cluster e
visibili da una collaborazione.
La tipologia di replicazione è attiva ma non esiste un
gestore delle copie per la scelta di mantenere l'architettura
più distribuita possibile, questo però incide sulla
trasparenza di locazione.
4.1 Aggiornamento lista
Figura scambio lista mediatori
Esistono dei meccanismi di riconoscimento di caduta di un
mediatore o di una collaborazione.
4.1 Guasto mediatore
Il meccanismo di controllo da parte di una collaborazione è
di HearthBeat con un operazione di Check di intervallo di
tempo regolabile e in caso di risposta negativa parte il
meccanismo di Recovering.
Il recovering della connessione di una collaborazione al
mediatore avviene semplicemente collegando la
collaborazione a un altro mediatore in lista.
In questo modo una collaborazione è sempre collegata ad
un mediatore se, almeno uno di essi in lista alla
collaborazione, è presente.
E' stata implementata un aggiornamento della lista dei
mediatori che viene effettuata ogni volta che si ha una
connessione disponibile a un mediatore ricevendo la lista
tramite la chiamata
e aggiornando il file
con i nuovi indirizzi ricevuti.
Tramite questa tecnica si ha una distribuzione di
conoscenza della locazione dei mediatori aumentando la
probabilità di collegamento.
Lo stesso aggiornamento della lista si ha anche lato
mediatore ogni volta che viene effettuata la
,
questo aggiornamento recupera la lista da tutti i mediatori
conosciuti e presenti al momento, tramite la chiamata
aggiornando il file
del mediatore.
La lista dei mediatori è quindi distribuita e viene
aggiornata di tanto in tanto da parte dei mediatori (10
Figura ricollegamento collaborazione
minuti) in modo da evitare il partizionamento del cluster in
sottocluster divisi.
Il controllo fra i mediatori avviene ad ogni operazione di
Il formato di un indirizzo è:
send/broadcast e si aggiorna la lista locale dei mediatori
rmi://<IP>:<PORTA>/<MEDIATOR>
eliminando quelli guasti.
<IP> è l'indirizzo IP della macchina
4
GetMediatorList
ListaMediatori.tx t
connect
GetMediatorList
ListaMediatori.tx t
Figura eliminazione mediatore
Facendo un esempio per reti di tipo LAN il Round Trip
Time è una scelta discutibile perché, in generale, il tempo di
risposta è più o meno simile.
Al contrario in reti di tipo WAN questa stima della qualità
di servizio è abbastanza appropriata.
Il numero di utenti è generalmente applicabile a tutti gli
scenari anche se in una rete WAN si può avere il problema
di scegliere un mediatore che fisicamente è molto lontano.
Poiché queste 2 stime possono variare col tempo
l'applicazione può scegliere se la collaborazione deve
cercare di tanto in tanto un mediatore migliore per
ricollegarsi se la scelta ricade su un diverso mediatore in
lista.
Questo permette una maggior dinamicità nella qualità del
servizio.
4.2 Guasto collaborazione
Nel caso di guasto di una collaborazione, essa viene
eliminata, insieme all'utente associato dalla lista del
mediatore in modo da liberare le risorse, il check avviene
in questo caso prima di chiamare la
sulla
collaborazione .
notify
6. Applicazione
Figura QoS
L'applicazione di esempio sviluppata è una lavagna
condivisa fra utenti che possono disegnare con un colore
scelto casualmente e cancellare la lavagna.
Figura eliminazione collaborazione
I messaggi scambiati sono:
tag:"start"
data: Point
tag:"drag"
data: Point
tag:"end"
data:Point
tag:"clear"
data:
assente
La classe DrawCollaboration estende la classe
RMICollaboration e ridefinisce il metodo
La qualità di servizio è implementata nella ricerca del
per applicare le azioni corrispondenti alla ricezione di un
mediatore più idoneo, quando una collaborazione vuole messaggio.
collegarsi.
Nel caso del messaggio "start" si inserisce il punto.
La scelta avviene secondo 2 meccanismi:
Nel caso di un messaggio "drag" o "end" si disegna una
1. Numero di utenti presenti
linea dall'ultimo punto dell'utente mittente.
2. Round Trip Time
Se si riceve un messaggio "clear" la lavagna viene
cancellata.
Il primo meccanismo consiste nello scegliere il mediatore A ogni ricezione di un messaggio viene aggiornata una
con il minor numero di utenti collegati attualmente.
struttura dati per il mantenimento dell'ultimo messaggio
Il secondo meccanismo sceglie il mediatore che ha un
ricevuto dal mittente in modo da evitare duplicati e
tempo di ritorno di risposta minore.
ricordare l'ultimo punto disegnato.
Sostanzialmente ho implementato queste 2 scelte
La classe GUIApplication rappresenta la veste grafica
applicabili secondo lo scenario di rete e l'applicazione che dell'applicazione e agisce alla pressione del pulsante Clear e
si dispone.
agli eventi del mouse se avvengono nell'area di disegno.
5 In entrambi i casi avviene un aggiornamento del disegno e
una broadcast del messaggio corrispondente alla
collaborazione che comunicherà con il supporto per lo
smistamento del messaggio a tutti gli altri utenti.
5. Qualità di servizio
notify(Message)
In entrambi i casi avviene un aggiornamento del disegno e
una broadcast del messaggio corrispondente alla
collaborazione che comunicherà con il supporto per lo
smistamento del messaggio a tutti gli altri utenti.
La primitiva utilizzata è la broadcast sincrona ma per
migliorare le prestazioni si potrebbe utilizzare quella
asincrona e implementare una coda locale per la ricezione
della giusta sequenza dei messaggi con ritrasmissione di
quelli non recapitati.
7. Test
I test sono stati prima svolti localmente in modo da
verificare la presenza di problemi di programmazione logica
e successivamente si è svolto un test distribuito.
Durante lo sviluppo del supporto ho creato i test JUnit in
modo da avere dei feedback su ciò che stavo sviluppando.
Poi ho testato l'applicazione con un solo mediatore e
diverse collaborazioni in modo da verificare una prima
versione di collaborazione.
Infine ho testato l'applicazione con più mediatori collegati
fra di loro e l'effettivo riconoscimento di caduta di un nodo
simulata attraverso una variabile booleana di TestFault
presente nella collaborazione e nel mediatore.
Il test distribuito è stato creato in una rete locale con 2
postazioni ognuna con un mediatore e un client in
esecuzione.
Il development dell'applicazione è semplice basta
modificare il file ListaMediatori.txt manualmente in modo
che ci sia connettività a livello applicativo tra le 2
collaborazioni.
Quindi almeno un mediatore attivo e conoscenza da parte
delle collaborazioni del mediatore.
Figura Sistema
Riguardo il controllo della presenza del mediatore il check
è stato fissato a 0,5 secondi mentre per la qualità di
servizio il tempo di ricerca è di 10 minuti.
Quindi, per creare una applicazione che utilizzi il supporto
presentato basta estendere la classe RMICollaboration e
decidere la tipologia di messaggi da scambiare.
Per quanto riguarda gli slot di tempo di reconnettività si
può cambiare in funzione del tipo di applicazione o delle
scelte sull'affidabilità e della performance della stessa.
6.1 Development
Sono stati creati 2 file JAR: uno per il mediatore
(collaboration.jar) e uno per l'applicazione (client.jar).con
il rispettivo script di esecuzione.
L'applicazione ha bisogno di almeno un mediatore
raggiungibile per l'esecuzione.
Una volta scelta la/le macchina/e che formano la
backbone della rete collaborativa si deve aggiornare il file
ListaMediatori.txt del supporto, secondo la conoscenza
che si ha della rete collaborativa.
Lo stesso aggiornamento deve essere fatto
sull'applicazione per una miglior scelta di connettività.
Una volta avviato un mediatore esso cerca di collegarsi
agli altri per il clustering fino a un minuto poi ogni 10
minuti.
Figura applicazione in macchina Piero
6
Passo 3
Looking up rmi://192.168.1.33:1099/TheMediator for
clustering
Mediatore rmi://192.168.1.33:1099/TheMediator non
disponibile
Looking up rmi://192.168.1.34:1099/TheMediator for
clustering
Got mediator
Proxy[IRMIMediator,RemoteObjectInvocationHandler[Un
icastRef [liveRef: [endpoint:[192.168.1.34:49354]
(remote),objID:[170f669:1176d50a056:O7fff,
7818742598804724483]]]]]
Registering member 0 as Piero
Passo 8
Removing Piero
Passo 9
Figura applicazione in macchina Vincenzo
Le operazioni svolte sono riportate di seguito:
1. Avviare il mediatore su macchina Piero
2. Avviare il mediatore su macchina Vincenzo
3. Attendere un minuto in modo che i 2 mediatori si
connettano fra loro
4. Avviare il client su macchina Vincenzo
5. Avviare il client su macchina Piero
6. Disegnare su macchina Vincenzo gli occhi e la bocca
7. Disegnare su macchina Piero i capelli
8. Chiudere il client su macchina Piero
9. Chiudere il mediatore su macchina Piero
10. Disegnare su macchina Vincenzo un punto
11. Chiudere il client su macchina Vincenzo
12. Chiudere il mediatore su macchina Vincenzo
7.1 Log MediatoreVincenzo
Passo 2
Registering RMIMediator as "TheMediator"
Created mediator, binding...
Remote mediator ready...
Looking up rmi://192.168.1.34:1099/TheMediator for
clustering
Got mediator
Proxy[IRMIMediator,RemoteObjectInvocationHandler[
UnicastRef [liveRef: [endpoint:[192.168.1.34:49354]
(remote),objID:[170f669:1176d50a056:O7fff,
7818742598804724483]]]]]
Passo 3
Looking up rmi://192.168.1.33:1099/TheMediator for
clustering
Mediatore rmi://192.168.1.33:1099/TheMediator non
disponibile
Registering member 0 as Vincenzo
Passo 10
Mediator
Proxy[IRMIMediator,RemoteObjectInvocationHandler[Un
icastRef [liveRef: [endpoint:[192.168.1.34:49354]
(remote),objID:[170f669:1176d50a056:O7fff,
7818742598804724483]]]]] is KO:removing it
Passo 11
Removing Vincenzo
7.2 Log MediatorePiero
Passo 1
Registering RMIMediator as "TheMediator"
Created mediator, binding...
Remote mediator ready...
Looking up rmi://192.168.1.34:1099/TheMediator for
clustering
Mediatore rmi://192.168.1.34:1099/TheMediator non
disponibile
Looking up rmi://192.168.1.33:1099/TheMediator for
clustering
Mediatore rmi://192.168.1.33:1099/TheMediator non
disponibile
Passo 3
Looking up rmi://192.168.1.34:1099/TheMediator for
clustering
Mediatore rmi://192.168.1.34:1099/TheMediator non
disponibile
Looking up rmi://192.168.1.33:1099/TheMediator for
clustering
Got mediator
Proxy[IRMIMediator,RemoteObjectInvocationHandler[Un
7 icastRef [liveRef: [endpoint:[192.168.1.33:35669]
(remote),objID:[O711db294:1176d524734:O7fff,
5380343055211056190]]]]]
L'affidabilità del sistema e la qualità di servizio sono
Got mediator
caratteristiche importanti che andrebbero migliorate per
Proxy[IRMIMediator,RemoteObjectInvocationHandler[Un aumentare la scalabilità del sistema.
I test effettuati hanno comunque dimostrato una buona
icastRef [liveRef: [endpoint:[192.168.1.33:35669]
resistenza ai guasti.
(remote),objID:[O711db294:1176d524734:O7fff,
5380343055211056190]]]]]
Passo 4
Registering member 0 as Vincenzo
7.3 Log ClientVincenzo
Passo 4
Looking:rmi://192.168.1.34:1099/TheMediator for QoS
Looking:rmi://192.168.1.33:1099/TheMediator for QoS
Looking up rmi://192.168.1.34:1099/TheMediator
Got mediator
Proxy[IRMIMediator,RemoteObjectInvocationHandler[
UnicastRef [liveRef: [endpoint:[192.168.1.34:49354]
(remote),objID:[170f669:1176d50a056:O7fff,
7818742598804724483]]]]]
Passo 9
Looking:rmi://192.168.1.34:1099/TheMediator for QoS
Trying another mediator
Looking:rmi://192.168.1.33:1099/TheMediator for QoS
Looking up rmi://192.168.1.33:1099/TheMediator
Got mediator
Proxy[IRMIMediator,RemoteObjectInvocationHandler[
UnicastRef [liveRef: [endpoint:[192.168.1.33:35669]
(remote),objID:[O711db294:1176d524734:O7fff,
5380343055211056190]]]]]
7.4 Log ClientPiero
Passo 5
9. Possibili sviluppi
Il supporto creato ha ancora molti limiti, per prima cosa si
potrebbero implementare nuove primitive di comunicazione
che utilizzino Poll Object per il recupero dei valori di
ritorno.
Un ampliamento semantico si potrebbe realizzare con l'invio
di messaggi a gruppi differenziati secondo un meccanismo
di qualità dei messaggi o dell'applicazione utilizzata con
l'ausilio di messaggi tipati e un gestore di coda orientato alla
qualità del servizio sui messaggi.
L'affidabilità si può migliorare tramite la permanenza dei
messaggi per un periodo di tempo limitato in modo da poter
offrire il ripristino dei messaggi non ricevuti all'atto del
ricollegamento di un utente.
Lo stesso meccanismo si può utilizzare per disaccoppiare
temporalmente gli utenti di una collaborazione per
applicazioni come il newsgrouping.
Un altro possibile miglioramento è nel discovering di nuovi
mediatori, dato che si è scelto un approccio distribuito al
problema, si potrebbe incrementare lo scambio delle liste
dei mediatori introducendo gli stessi utenti nel
aggiornamento della lista, oppure, in caso di mancanza di
mediatori utilizzare un recupero basato su un Manager,
servizio di Naming o un sito Web che aumenti la
trasparenza di locazione.
Looking:rmi://192.168.1.34:1099/TheMediator for QoS
Looking:rmi://192.168.1.33:1099/TheMediator for QoS 10. Bibliografia
Looking up rmi://192.168.1.33:1099/TheMediator
[1] O'Reilly Java RMI
Got mediator
Proxy[IRMIMediator,RemoteObjectInvocationHandler[
[2] Java RMI: Remote Method Invocation by
UnicastRef [liveRef: [endpoint:[192.168.1.33:35669]
Troy Bryan Downing
(remote),objID:[O711db294:1176d524734:O7fff,
5380343055211056190]]]]]
[3] Slide Reti di calcolatori LS
(http://wwwOlia.deis.unibo.it/Courses/RetiLS/Lucidi.h
8. Conclusioni
tml)
Il framework sviluppato permette una facile
implementazione di applicazioni che si basano su gruppi di
utenti che vogliono collaborare per scambiarsi
informazioni.
Fra queste applicazioni vi sono esempi come l'instant
messaging, sistemi p2p per lo scambio di documenti,
musica o video, sviluppo di software in ambito
opensource e molti altri.
L'affidabilità del sistema e la qualità di servizio sono
caratteristiche importanti che andrebbero migliorate per
aumentare la scalabilità del sistema.
8