Supporto alla comunicazione di gruppo
context aware per membri disconnessi.
Architettura e assunzioni
•
•
•
•
•
•
Reti ad hoc di computer mobili
Località con controllori
Possibilità di disconnessione
Concetto di gruppo
Movimenti standardizzati
Località fisse
Scenario: MANET
• Necessità di un framework per
– Comunicare
– Gestire le località
– Gestire i gruppi
AGA
AGAPE:
Allocation and Group Aware Pervasive Environment
• Middleware per la gestione dei gruppi
•
•
•
•
Supporto per la comunicazione
Gestione di località tramite LME
Profilazione (Profiling)
Creazione automatica di reti disconnesse
Cosa manca ?
• Supporto alla “comunicazione
disconnessa”
– Comunicazione interlocalità
– Comunicazione intralocalità
• Supporto al message storing
• TTL e Timestamp nei messaggi
Soluzione : estensione
APPLICAZIONE
C.M.
I.R.S.
M.R.
Active Object
Active Object
Passive Object
AGAPE
Java Virtual Machine
HW - Network - OS
Context Manager
•Oggetto attivo
APPLICAZIONE
•Differenti implementazioni
–LME
–ME
C.M.
I.R.S.
M.R.
•Accumulo informazioniAGAPE
sul movimento
•Analisi probabilistica delle future
destinazioni
Java Virtual Machine
•Interazione con IRS per politiche di routing
HW - Network - OS
Interlocation Routing Service
•Oggetto attivo
APPLICAZIONE
•Blocco riservato al routing vero e proprio
C.M.
I.R.S.
M.R.
•Analisi dei messaggi da inoltrare
–Destinatario singolo o gruppo
AGAPE
–Timestamp
–Località di destinazione
•Analisi dei nodiJava
della
località
Virtual
Machine controllata
–Ricerca di un vettore
HW - Network - OS
–Ricerca di nuovi nodi da processare
Message Repository
APPLICAZIONE
•Oggetto passivo
•FornisceC.M.
supporto al I.R.S.
Message StoringM.R.
•Funzioni per la gestione
–Inserimento
–Eliminazione
–Timestamp
AGAPE
Java Virtual Machine
•Capacità limitata dalle risorse del
Dispositivo HW - Network - OS
Esempio: Lato ME
History Register
loc 1
Place (LID)
Next Locality History (LID)
Locality 3 (3)
5
5
6
Locality 5 (5)
3
5
6
Locality 6 (6)
3
5
6
Locality 1 (1)
2
5
6
1
3
loc 2
Esempio: Lato LME
GHR
History Register ME1
Place (LID)
Next Locality History (LID)
Locality 3 (3)
5
5
6
Locality 1 (1)
2
3
2
5
6
History Register ME2
Place (LID)
Next Locality History (LID)
Locality 3 (3)
5
5
6
Locality 1 (1)
2
3
2
5
6
History Register ME3
Place (LID)
Next Locality History (LID)
Locality 3 (3)
5
5
6
Locality 1 (1)
2
3
2
5
6
010010001110101001
Politiche di Routing
•Ogni ME accumula info sul movimento
•Creazione di una lista dei movimenti (History
Register)
•Per ogni località entry con le località di
destinazione
History Register
Place (LID)
Locality 0 (0)
Locality 1 (1)
Locality 2 (2)
Locality 3 (3)
1
0
1
1
3
0
3
1
Next Locality History (LID)
2
2
3
2
1
2
2
0
3
0
0
2
3
3
1
3
3
1
2
2
1
1
0
1
2
3
1
1
2
3
0
1
Caratteristiche della Soluzione
•Routing dinamico basato su tabelle
•Controllo sulla crescita delle tabelle (drop
in caso di uscita)
•Buon funzionamento sulla base delle
assunzioni fatte
•Possibilità di estensione: metodi
–makeDecision
–FindForwardingHost
Limitazioni
•Assunzioni limitative
–Necessari movimenti abitudinari
–Località che non possono muoversi
–Alta replicazione dei messaggi
Sviluppi futuri
•Introduzione del concetto di contatto
–Fra differenti host
–Con timestamp
–Con abitudini
•Possibilità di maggiore efficienza
–Con comunicazione fra diversi LME
–Con liste più dettagliate
–Limitando la crescita delle copie dei messaggi
Grazie per
l’attenzione