Scaricare la presentazione
La presentazione è in caricamento. Aspetta per favore
PubblicatoFausto Palmieri Modificato 9 anni fa
1
Proxy-based infrastructure for LBS availability Bucco Nicola matr.0000232254
2
Location Based Service AREA NOTA AL LBS SISTEMA LBS UTENTE MOBILE POSIZIONE INFORMAZIONI LB Informazioni basate sulla locazione dell’utente mobile
3
Schema generale CLIENT PROXY LBS Sistema basato su: Client Proxy LBS Dati Wireless-link Wired-link
4
Specifiche generali VMT Organizzazione area museo Registrazione Client Priorità Client Vincoli Tecnologici: Ekahau
5
Specifiche Proxy VMT Replicazione Coordinamento Availability del servizio Persistenza delle informazioni Bilanciamento del carico QoS
6
Visione generale
7
Gestione della replicazione e del bilanciamento del carico Ring logico -> Schema dinamico Coordinamento delle repliche tramite Token Bilanciamento del carico Localmente scalabile Token I Token R R4 R1 R2 R3
8
Configurazione iniziale del sistema File di configurazione per ogni Replica IdBrokerR:IP:Porta IdBrokerI:IP:Porta IdNodo:IP:Porta IdPrecedente:IP:Porta IdSuccessivo:IP:Porta IdSecondoSucc:IP:Porta Macroarea Semplicità nella gestione dell’aggiunta e della rimozione di repliche
9
Gestione della persistenza Scelta uso DB MySql DB per ogni replica PRO: Fault Tolerance CONTRO: Sincronizzazione SOLUZIONE: Stato parziale dei Client DB(R3) R4 R1 R2 R3 DB(R4)DB(R2) DB(R1)
10
Struttura interna di una replica ThreadGestioneServer ThreadGestioneClient MAILBOX ThreadClient ThreadAnarchico ThreadRegistrazione ThreadSuddivisione ThreadTimeout - Utilizzo di Thread paralleli per realizzare le diverse funzionalità
11
Gestione della availability Ipotesi di guasto singolo e corretto funzionamento della rete Due procedure successive per gestire i guasti e garantire tempi di risposta limitati: Procedura di recovery Procedura di suddivisione dei client
12
Procedura di recovery -1 1.Individuazione del guasto: Timeout, caduta connessione 2.Invio messaggio AvvioRipristino da parte di chi ha rilevato il guasto 3.Nodo precedente a quello caduto riceve AvvioRipristino e diviene Gestore R1 R5 R4R3 R2
13
Procedura di recovery - 2 4.Gestore invia MessaggioRecovery per aggiornare le connessioni e individuare la presenza del Token 5.Al ritorno del messaggio al gestore, eventuale rigenerazione dei Token
14
Procedura di suddivisione dei client 1.Gestore preleva dal proprio DB le informazioni sui client del nodo caduto e le inserisce nel messaggio Suddivisione 2.Invia messaggio Suddivisione 3.Chi lo riceve: –estrae il primo client rimuovendolo dal messaggio –lo prende in gestione comunicandolo agli altri –Inoltra il messaggio se ci sono ancora client da gestire
15
Conclusioni Peculiarità del sistema: Organizzazione delle repliche secondo il modello TokenRing Replicazione delle informazioni dei client sui db di ciascun replica Procedura di recovery rapida e fortemente orientata alla availability
Presentazioni simili
© 2024 SlidePlayer.it Inc.
All rights reserved.