dell'area
ripartizione dinamica dello spazio in regioni per far fronte all'aumentare del numero di clienti connessi; combinare questo approccio con la progettazione del sistema nel suo complesso comporta delle di coltà dovute principalmente alla ri-allocazione dei nodi coordinatori.
SimMud rappresenta un importante tentativo alla costruzione e gestione di un ambiente virtuale completamente distribuito; tuttavia l'utilizzo di DHT si rivela più adatto in contesti diversi come ad esempio il le sharing. Abbiamo visto che SimMud presenta diversi punti deboli come la presenza di punti di centralizzazione e di coltà nel raggiungere la scalabilità.
1.6 Tecniche di scambio delle liste dei vicini
Negli ambienti virtuali distribuiti la parte più signi cativa dei messaggi scambiati attraverso la rete dai peer riguarda informazioni di aggiornamento delle posizioni all'interno del mondo virtuale. Questi messaggi sono fondamentali per assicurare che ogni peer disponga di informazioni consistenti sul mondo virtuale a cui appartiene. Quando il numero di partecipanti all'applicazione distribuita aumenta la scalabilità è un aspetto molto importante: anche se la dimensione dei singoli messaggi scambiati è modesta i ritardi di trasmissione devono essere contenuti il più possibile.
A questo scopo gli autori di [9] propongono un sistema completamente distribuito per lo scambio e ciente dei messaggi di aggiornamento tra i client dell'applicazione senza introdurre supporti particolari per la comunicazione in multicast e senza a darsi a soluzioni centralizzate caratterizzate da forti investimenti iniziali.
Il sistema proposto è strutturato in maniera completamente decentralizzata; le entità stesse che formano il sistema sono responsabili della formazione e manuten- zione della overlay network. Inoltre viene utilizzato il concetto di area di interesse e di interest management come strumenti di ltraggio dei messaggi; si ricevono in maniera dettagliata i messaggi provenienti da nodi vicini e si ignorano quelli prove-
nienti da nodi troppo lontani per poter in uire sulle scelte della entità.
Ogni entità dell'applicazione mantiene connessioni dirette solo con un sottoinsie- me di altre entità formando in questo modo una overlay network basata sul protocollo IP.
La procedura di connessione proposta è di tipo stateless: i peer al momento della connessione al sistema non dispongono di nessuna informazione riguardante il mondo virtuale che li circonda. I nuovi peer che desiderano entrare nel sistema si connettono al bootstrap server, cioè un server che mantiene solo le informazioni riguardanti entità che sono entrate più di recente.
Lo schema appena descritto si dierenza profondamente dai sistemi centralizzati dove il server mantiene informazioni accurate su tutti i partecipanti all'applicazione, diventando un punto di centralizzazione per l'intero sistema.
Dunque nei sistemi completamente distribuiti non esiste un server che mantiene informazioni di stato aggiornate di tutti i peer; ciò va a discapito della consistenza e integrità della topologia complessiva della overlay network.
Procedura di connessione La fase di connessione di una entità al sistema si basa su informazioni fornite dal bootstrap server: l'entità si connette al server e questo gli comunica le entità che risultano più vicine alla posizione che occupa. L'entità apre delle connessioni dirette con ognuna delle entità comunicate dal server per lo scambio di messaggi di aggiornamento.
Osserviamo che le informazioni fornite dal server potrebbero non essere aggiornate e quindi non più valide a cause delle caratteristiche stesse del bootstrap server. Il sistema prevede quindi una procedura per il ripristino della overlay network a seguito della connessione di un nuovo peer, descritta di seguito.
Ogni entità chiede alle altre entità a cui è connessa la lista dei vicini. Una volta ottenute queste informazioni l'entità dispone di una conoscenza più approfondita dell'ambiente che lo circonda e classi ca le entità vicine in entità attive e entità latenti. La classi cazione può avvenire secondo la metrica che più si adatta all'ap-
1.6. TECNICHE DI SCAMBIO DELLE LISTE DEI VICINI 27 plicazione, ad esempio la distanza euclidea tra entità.
Dopo aver determinato secondo una certa metrica le entità attive ogni entità sta- bilisce una connessione diretta con N di esse e inizia lo scambio di messaggi di aggiornamento delle rispettive posizioni.
Le entità latenti si de niscono come entità che si trovano a una distanza maggiore rispetto alle entità attive e di cui non interessa ottenere informazioni dettagliate; sono accettabili anche informazioni non precise ma solo no a quando rimangono fuori dall'area di interesse. Quando una entità latente è in fase di avvicinamento allora saranno richieste informazioni più precise sulla sua posizione in quanto po- trebbe diventare entità attiva.
Questa tecnica rientra nel concetto più generale e già citato in precedenza in que- sto capitolo di Area di Interesse di un nodo come strumento essenziale per ridurre la comunicazione tra i partecipanti al mondo virtuale e per mantenere la corretta rappresentazione della overlay network.
Gli autori hanno eseguito delle simulazioni del sistema per poi confrontare i risultati con quelli ottenuti con una implementazione centralizzata di tipo client- server dove tutte le entità del mondo virtuale informano il server dei loro spostamenti e il server invia i messaggi alle entità interessate.
I risultati ottenuti dalla simulazione mostrano che il modello a scambio di messaggi e il modello basato su architettura C/S sono qualitativamente molto simili.
Il principale parametro preso in considerazione per il confronto è la consistenza della overlay network nell'area di interesse di ogni entità, calcolata come
C(i) = 1 N n X i=1 P (i) Q(i) dove N è il numero totale di entità del mondo virtuale
P (i) è il numero di entità contenute nella lista di entità attive del nodo i Q(i)è il numero di entità attive per il nodo i.
Con un numero elevato di entità attive, il sistema distribuito raggiunge un livel- lo di consistenza molto elevato, circa 0.9; con un numero basso di entità attive si producono eetti negativi sulla consistenza della rete a causa della formazione di sottoinsiemi di nodi indipendenti.
Al veri carsi di questa situazione ogni nodo può comunicare solo con nodi ap- partenenti al suo stesso sottogruppo.
Le simulazioni eseguite mostrano che con almeno 8 entità attive non si veri ca la formazione di sottogruppi mentre con meno di 8 si assiste alla divisione della overlay network in sottogruppi.
Purtroppo non è possibile imporre ad ogni nodo del sistema un numero ssato di entità attive perché in un ambiente eterogeneo ogni nodo dispone di caratteristiche hardware e connettività alla rete diverse dagli altri nodi. Inoltre l'individuazione della formazione e della presenza di sottogruppi non è banale a causa dell'assenza di una fonte centralizzata di informazioni delle posizioni di tutte le entità. Si cerca di porre rimedio agli eetti negativi derivanti dalla formazione di sottogruppi di nodi attraverso una tecnica chiamata random introduction.
Questa tecnica viene utilizzata per spargere informazioni tra le entità apparte- nenti a gruppi diversi nel tentativo di ristabilire la connessione tra i sottogruppi: a intervalli di tempo regolari ogni entità ei si riconnette al bootstrap server scegliendo
in maniera casuale un insieme di entità E. L'entità ei si connette ad ognuna delle
entità appartenenti ad E e inizia lo scambio di messaggi di aggiornamento sulle re- ciproche posizioni nel mondo virtuale.
Attraverso questa procedura di scelta casuale delle entità è possibile mettere in comunicazione entità appartenenti a diversi sottoinsiemi.
Le simulazioni condotte su questo modello di scambio di messaggi hanno mostrato che la probabilità di riconnessione tra i sottogruppi aumenta all'aumentare della frequenza di accesso al bootstrap server per l'operazione di random introduction. D'altra parte però il frequente accesso delle entità verso bootstrap server comporta per questo un eccessivo carico di richieste e quindi si dovrebbe determinare un intervallo tra gli accessi al server che minimizzi il carico del server e allo stesso
1.7. SISTEMI CLIENT-SERVER IBRIDI 29