Proxy-based infrastructure for LBS availability Bucco Nicola matr

Location Based Service AREA NOTA AL LBS SISTEMA LBS UTENTE MOBILE POSIZIONE INFORMAZIONI LB Informazioni basate sulla locazione dell’utente mobile

Schema generale CLIENT PROXY LBS Sistema basato su: Client Proxy LBS Dati Wireless-link Wired-link

Specifiche generali VMT Organizzazione area museo Registrazione Client Priorità Client Vincoli Tecnologici: Ekahau

Specifiche Proxy VMT Replicazione Coordinamento Availability del servizio Persistenza delle informazioni Bilanciamento del carico QoS

Visione generale

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

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

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)

Struttura interna di una replica ThreadGestioneServer ThreadGestioneClient MAILBOX ThreadClient ThreadAnarchico ThreadRegistrazione ThreadSuddivisione ThreadTimeout - Utilizzo di Thread paralleli per realizzare le diverse funzionalità

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

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

Procedura di recovery Gestore invia MessaggioRecovery per aggiornare le connessioni e individuare la presenza del Token 5.Al ritorno del messaggio al gestore, eventuale rigenerazione dei Token

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

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