Aprile 2004Reti di Calcolatori LS – Servizio di Annunci Distribuito1 Reti di Calcolatori LS...

Aprile 2004 Reti di Calcolatori LS – Servizio di Annunci Distribuito 1

Reti di Calcolatori LS

REALIZZAZIONE DI UN SERVIZIO

DI ANNUNCI DISTRIBUITO

Studente: Ludovisi CesidioMatricola: 0000169645


INTRODUZIONE

Lo scopo del progetto è quello di realizzare un servizio di annunci distribuito che consenta ad un cliente di:

• inserire un nuovo annuncio

• trovare annunci di interesse

Abstract: • descrizione generale del progetto

• maggiore approfondimento sulla parte implementativa

Obiettivi: • decentralizzazione della architettura

• dinamicità della architettura

• gestione della fault tollerance

• gestione Qos

• efficienza del servizio


DESCRIZIONE DEL SISTEMA

Il sistema è composto da un certo numero di nodi che formano il core del servizio

Il servizio consiste nel gestire un insieme di annunci in modo distribuito

Quindi un utente può:• inserire un annuncio su un nodo (asincrono)

• trovare annunci di interesse su un nodo (sincrono bloccante - callback)

• trovare annunci di interesse su l’insieme dei nodi (sincrono bloccante - callback)

Inoltre si svolge la gestione dinamica del binding di nuovi nodi:• bind di un nuovo nodo (sincrono bloccante)

• unbind di un nodo (asincrono)


ARCHITETTURA LOGICA

Nodo 2

Nodo 1 Nodo N

CORE del Servizio

MASTERSLAVE

server_ID 1

server_ID 2

server_ID N

AnnouncementService

BindingSevice

2LevelRegistry1LevelRegistry

NODO iDB DB


ANNOUNCEMENT SERVICE

Servizio Locale (lettura - inserimento)

Nodo 2

Nodo 1 Nodo N

1) readLocal / insert

DataBaseNodo 2

2) read / write

bloccante – callback - asincrono

CALLBACK

Cliente i

host Nodo2

port registry2 Nodo2


ANNOUNCEMENT SERVICE

Nodo 2

Nodo 1 Nodo N

1) readAll

2) readLocal 3) readLocal

DataBaseNodo 2

4) read

5) announcements

Servizio Distribuito (lettura)

bloccante - callback

CALLBACK

Cliente i

host Nodo2

port registry2 Nodo2


BINDING SERVICE (1/2)

Nodo 2

Nodo 1 Nodo N

registry1 level

registry1 level

registry1 level

1) bindAll

2) update

3) update

8) bindLocal

7) update ?

4) bindLocal

9) update

11) update ?

5) update

10) verify

6) verify

New Nodo

registry1 level host NodoN

port registry2 NodoN


BINDING SERVICE (2/2)

Nodo 2

Nodo 1 Nodo N

registry1 level

registry1 level

registry1 level

New Nodo

registry1 level


GESTIONE QoS

thmax

thmin

Pay

Pay

Pay

Free

Free

Freethmax

thmin

Pay

Pay

Pay

Free

Free

FreeEmpty

Full

PAYQUEUE

Servizio Locale

(lettura - inserimento)

Servizio Distribuito

(lettura)

QoS:

• differenziazione del servizio

• azioni preventiva per evitare congestione

n°

ute

nti

con

tem

por

anei

n°

ute

nti

con

tem

por

anei


GESTIONE FAULT TOLLERANCEIpotesi:

• guasto singolo

• probabilità di guasto bassa durante il recovery

MEMORIA STABILE

OGGETTO SERVER

REGISTRY • organizzazione gerarchica• replicazione

• Master / Slave• modello a copia fredda• timestamp condiviso

• gestione della consistenza delle copie• scrittura:

• prima su copia 1 poi su copia 2• lettura:

• lettura da copia 1 lettura da copia 2• confronto ricovery se necessario

Gestione Fault Tollerance su tre livelli:


IMPLEMENTAZIONE DEL SISTEMA (1/5)

Scelte Realizzative:

• uso di Java RMI

• database realizzati mediante file XML

• configurazione dei server mediante file XML

• programmazione concorrente attraverso Thread

Considerazioni Introduttive sulla Implementazione:

• attenzione concentrata su protocolli e politiche di gestione

• rilassati vincoli di efficienza:

uso di SAX per il parsering dei file XML


IMPLEMENTAZIONE DEL SISTEMA (2/5)Setting

AnnouncementServerApplication

AnnouncementClientApplication

BindingServerApplication

AnnouncementServer

IAnnouncementClient

IParticipationRequest

AnnouncementMaster

AnnouncementSlave PerticipationRequestImpl

ReadThread

MemoryManager

BindThread

UnbindThread

MasterCheckTimestamp

CheckThreadMaster

CheckThreadSlave

AnnouncementClientImpl

ClientThread

IAnnouncementServer

AnnouncementServerImpl

Announcement

lancia

lancia

lancia

usa

callbackgestisce

masterCheck

updateTimestamp

crea

crea

lancia

lancia

Java Package:announcement.executionannouncement.applicationannouncement.application.rmiInterfaceannouncement.application.implementationannouncement.application.thread



AnnouncementServerImpl

nClient : IntegernQueueClient : Integersetting : Setting

insert(announcement : Announcement, key : String)readAll(category : String, subject : String, key : String) : Announcement[]readAll(category : String, subject : String, key : String, client : IAnnouncementClient)readLocal(category : String, subject : String, key : String) : Announcement[]readLocal(category : String, subject : String, key : String, client : IAnnouncementClient)beginForLocal(pay : Boolean)endForLocal(pay : Boolean)beginForRemote(pay : Boolean)endForRemote(pay : Boolean)

ParticipationRequestImpl

setting : Setting

bindAll(newHost : String, newRegistryPort1 : String, newRegistryPort2 : String, newName : String) : BooleanbindLocal(newHost : String, newRegistryPort1 : String, newRegistryPort2 : String, newName : String) : BooleanunbindAll(oldHost : String, oldRegistryPort1 : String, oldRegistryPort2 : String, oldName : String)unbindLocal(oldHost : String, oldRegistryPort1 : String, oldRegistryPort2 : String, oldName : String)updateFirstLevelRegistry(myHost : String, myRegistryPort1 : String)

AnnouncementClientImpl

callback(announcements : Announcement[])

componenti

che implementano

le interfacce RMI remote

Osservazioni:

• Qos gestita attraverso i metodi di prologo ed epilogo

• parallelismo realizzato attraverso le classi: ReadThread, BindThread, UnbindTread

• gestione della “Memoria Stabile” attraverso il componente MemoryManager (read, write)



CheckThreadMasterCheckThreadSlave

AnnouncementMaster

setting : Settingtimestamp : MasterChackTimestampannouncementServer : AnnouncementServerImplbindingServer : ParticipationRequestImpl

insert()readAll()readLocal()bindAll()bindLocal()unbindAll()unbindLocal()updateFirstLevelRegistry()recovery() : BooleanupdateTimestamp()

AnnouncementSlave

setting : Settingtimestamp : MasterChackTimestampannouncementServer : AnnouncementServerImplbindingServer : ParticipationRequestImpl

insert()readAll()readLocal()bindAll()bindLocal()unbindAll()unbindLocal()updateFirstLevelRegistry()masterCheck() : Boolean

MasterCheckTimestamp

timestamp : Date

update()verify() : DatesetNull()

update verify

Realizzazione del Modello di Replicazione Master / Slave:

masterChech()updateTimestamp()



AnnouncementServer

setting : SettingserverId : String

start()binding(host : String, port : String, action : String)

Realizzazione del gestore del nodo:

Responsabilità del componente:

• parsering del file XML di configurazione del nodo

• inizializzazione dei registry di primo e secondo livello

• creazione dell’oggetto Master e di quello Slave

• creazione dei Thread per la sincronizzazione tra Master e Slave


TEST DEL SISTEMA

Fasi:• creazione dei registry:

rmiRegistry localhost port

• esecuzione dei server dei nodi core del servizio:java announcement.execution.AnnouncementServerApplication serverId

• esecuzione di un nuovo nodo che effettua il binding:java announcement.execution.BindingServerApplication host port serverId action

• esecuzione dei clienti:java announcement.execution.AnnouncementClientApplication host port action pay

ESECUZIONE TEST


CONCLUSIONI

Obiettivi:

•decentralizzazione

•dinamicità

•fault tollerance

Vantaggi:

• scalabilità

• robustezza

Svantaggi:

• costi

• overhead

Bilanciamento:

• semplicità dei protocolli

• non sincronizzazione ridondante

• principio di Minima Intrusione

Java RMI:

• interazione ad alto livello

• supporto per la concorrenza

• supporto per la comunicazione

• naming service• method invocation• interfacce del servizio

Progettazione:

Realizzazione:

Aprile 2004Reti di Calcolatori LS – Servizio di Annunci Distribuito1 Reti di Calcolatori LS...

Documents

Transcript of Aprile 2004Reti di Calcolatori LS – Servizio di Annunci Distribuito1 Reti di Calcolatori LS...