Proxy-Based Infrastructure
for LBS Tailoring
Reti di Calcolatori LS – Prof. A. Corradi
Gruppo:
Roberto Amici
Alessandro Antonelli
Luca Pistolesi
Presentazione di:
Roberto Amici
Location-Based Services
●
●
●
Client mobili (collegamenti wireless)
Informazioni legate alla specifica locazione da cui il client le
richiede
Cambi di posizione del client implicano modifiche al
contenuto informativo fornito dal server
Proxy-Based Tailoring
Crescente eterogeneità dei dispositivi client
Necessità di servizi
personalizzati
Tailoring: adattamento dei
servizi in base alle capacità e
alle preferenze del client
Uso di un proxy per adattare i contenuti informativi
forniti dai server
Scenario Applicativo
Realizzazione di un servizio di Virtual Museum Tour
(visita ad un museo supportata da servizi multimediali
fruibili tramite un dispositivo portatile: pda, laptop,
notebook)
Fornitura di informazioni relative alle opere vicine alla
posizione attuale del client
Adattamento del servizio in base alle capacità del dispositivo
ed alle preferenze dell'utente
Regole di adattamento aggiornabili runtime
Suddivisione del museo in macroaree servite da un proxy
ciascuna
Elementi del sistema
Client
PNS
Proxy
Registry
Server
Meccanismi, non politiche
Idea di base: separazione dell'infrastruttura di gestione
dalla fornitura dei contenuti
Possibilità di inserire ed eliminare servizi a tempo di
esecuzione
Sistema di tailoring modulare ed estendibile
Coordinamento per la gestione dei server disponibili
Necessità di informazioni per poter integrare i nuovi servizi nel
sistema
Tailoring statico e dinamico
Statico: decisione del miglior match tra le capacità/preferenze
dell'utente e le risorse disponibili per la locazione corrente
Dinamico: adattamento del flusso informativo in erogazione per
venire incontro a necessità dinamiche dell'utente
Server
Entità che fornisce i servizi
Deve esporre un'interfaccia di integrazione con il sistema
VMT
Potenzialmente legacy: bisognerà costruire un wrapper che
fornisca la possibilità di integrazione
Regole e metaregole
File jar per l'adattamento
runtime del servizio
Registry
Entità di coordinamento e gestione dinamica
Visione globale dello stato del sistema
Aggiunta, rimozione e modifica di server/servizi
Attivazione e disattivazione di proxy
Location-awareness: mette in corrispondenza le risorse fornite dai
server con l'effettiva disposizione geografica delle opere all'interno
del museo
Espone un WebService per la registrazione/attivazione (sia
per i server che per i proxy)
Comunicazione Registry-Proxy in formato proprietario
tcp/ip (nessuna necessità di standardizzazione) per
notificare i proxy di modifiche alle risorse o ai servizi
Proxy
Elemento di base dell'infrastruttura
Comunicazione con i client (Java RMI)
Tailoring: regole fornite dai server (motore di inferenza:
DROOLS)
Adattamento ed inoltro dei servizi dai server verso i client
Gestione delle richieste multiple (possibilità di sfruttare flussi
condivisi: multicasting)
Stima dello stato di carico della rete e conseguente gestione della
banda da assegnare ai singoli client
Gestione differenziata per utenti paganti e non
Struttura interna pipelined: throughtput parzialmente
limitato dal numero di stadi della pipeline ma gestione più
semplice delle strutture dati condivise
DataFlow
Client: recupero della
propria posizione tramite
GPS
Client: interrogazione del
servizio di nomi (PNS)
Client: notifica di cambio
posizione al server rmi del
proxy
Proxy: tailoring,
predisposizione delle
strutture per il forwarding e
richiesta del servizio al
server
Server: fornitura del servizio
Testing
Ambiente di test:
Simulazione di un numero variabile di client e server di
risoluzione dei nomi da un pc dedicato (notebook Intel centrino,
Windows XP, scheda wireless 802.11g)
Proxy e Registry su una macchina apposita (notebook Intel
centrino duo, Linux, scheda ethernet 100Mbs, wireless 802.11g);
Server web tomcat come container per il web service di
accettazione richieste del registry
Server (Legacy+Wrapper) su notebook Intel Pentium IV, Windows
XP, scheda ethernet 100Mbs – Server Web tomcat come container
per i web service di gestione del server
Rete wireless di facoltà
Simulazioni:
Arrivo a flusso continuo di utenti
Worst case test: arrivo contemporaneo di n utenti
Testing - Risultati
Tempi di registrazione al sistema di un client presso il
proxy locale al piano di riferimento
1080
1060
Caso di utenti con arrivo
intervallato: prestazioni
sostanzialmente
indipendenti dal numero
di client.
1040
Millisecondi
1020
1000
980
960
940
920
900
16
#Client
Worst case scenario:
Utenti con arrivo
contemporaneo:
peggioramento delle
prestazioni
64
128
30000
27500
25000
22500
20000
Millisecondi
4
17500
15000
12500
10000
7500
5000
2500
0
4
16
32
#Client
64
96
128
Testing - Risultati
Tempi di risposta del proxy su notifiche di cambiamento
di posizione del client
725
700
675
Caso di utenti con arrivo
intervallato: leggero
degrado delle prestazioni
Millisecondi
650
625
600
575
550
525
500
4
16
#Client
64
128
20000
Worst case scenario –
Arrivo contemporaneo:
aumento rilevante dei
tempi di attesa
17500
Millisecondi
15000
12500
10000
7500
5000
2500
0
4
16
32
#Client
64
96
128
Conclusioni
Tempi di risposta accettabili in condizioni di utilizzo
normale, problemi invece con arrivo contemporaneo di
molti client
Non testata la funzionalità di raggruppamento dei client in
multicast, migliora le prestazioni in caso di arrivi contemporanei
Ottima flessibilità per quanto riguarda il riuso e le
possibilità operative fornite dall'infrastruttura, grazie alla
gestione modulare del modulo di tailoring e adattamento
Estensioni
Availability e fault tolerance non prese in considerazione, ma
aspetti imprescindibili di un progetto completo
Layer di presentazione: l'implementazione attuale è fornita solo di
un semplice sistema per il testing