Le caratteristiche suddette rendono questo sistema simile a Solipsis e VON, in modo particolare per l'assenza di un punto di raccolta delle informazione di posi- zione delle entità e per la caratteristica di auto-organizzazione delle entità stesse. Tuttavia Solipsis e Von si basano su concetti matematici e geometrici ben de niti che permettono maggiore chiarezza nella determinazione di situazioni irregolari nella overlay network e quindi un recupero delle situazioni di ine cienza.
1.7 Sistemi client-server ibridi
L'architettura proposta da federated peer-to-peer [10] è basata sulla divisione del mondo virtuale creato dal gioco (o dalla simulazione) in aree di dimensione limitata, corrispondenti alle diverse aree di interesse che si individuano. Ogni area di interesse è indipendente dalle altre e costituisce un'applicazione a se, dunque sono necessari meccanismi di comunicazione per permettere alle diverse entità di collaborare.
In confronto con l'architettura client-server, dove i costi predominanti sono dovuti alla elaborazione dello stato dell'applicazione, l'applicazione di questo modello ai sistemi distribuiti comporta costi dovuti principalmente alle frequenti comunicazioni tra i nodi.
La progettazione del sistema è basata sul concetto di interest management: si inviano pacchetti solo al sottoinsieme di clienti per i quali le informazioni che si stanno inviando sono davvero rilevanti.
Un client si iscrive ad una area di interesse per ricevere le informazioni inviate dalle altre entità che appartengono a quell'area. I clienti possono sottoscriversi ad una o più aree di interesse.
Multicast Re ector L'implementazione del multicast è realizzata attraverso la tecnica dei multicast re ectors: entità in grado di mantenere la lista dei client sot- toscritti ad una certa area di interesse e di disseminare i pacchetti tra essi.
tutti i client di una certa area. Quando un client sottoscrive un certo peer group esprime l'interesse nel ricevere tutti gli aggiornamenti che riguardano quel gruppo.
Control Server I control server rappresentano entità alle quali è a dato il compi- to di mantenere la corretta corrispondenza tra aree di interesse e multicast re ector; essi devono anche gestire casi come il fallimento di alcuni multicast re ector oppure la creazione di un nuovo mapping per ottenere un bilanciamento del carico adeguato. Inoltre i control server devono informare i client sottoscritti alle aree che sono state interessate dai suddetti cambiamenti e fornire le informazioni per eseguire la con- nessione ai nuovi multicast re ector.
I control server hanno anche il compito di mantenere la struttura dell'applicazione: partizione del mondo virtuale in aree di interesse, autenticazione dei client, account utenti e altri dati dell'applicazione.
I control server intervengono solo in poche fasi e la parte centrale delle elabora- zioni speci che dell'applicazione sono eseguite dagli utenti stessi. Questo permette al provider dell'applicazione di ridurre in maniera drastica i costi perché sono i client stessi ad eseguire la logica dell'applicazione.
Struttura del mondo virtuale In mondo virtuale dell'applicazione è diviso in aree di interesse; come detto sopra questa ripartizione è mantenuta dai control server. Ogni locazione dello spazio virtuale è rappresentata da un numero intero positivo; quando necessario, sarà il client ha eseguire la conversione di questo numero con il corrispondente valore della locazione (ad esempio un punto in tre dimensione nello spazio virtuale).
Avvio del client La fase di join di un peer prevede che il peer stesso contatti un control server, informandolo dell'area di interesse nella quale vuole inserirsi. Il control server mantiene il mapping tra i re ector e le aree di interesse, dunque in base alle informazioni speci cate dal peer determina i re ector ai quali esso deve sottoscriversi.
Tra co di rete La latenza di trasmissione dei pacchetti tra i client dell'applicazio- ne è un parametro fondamentale infatti un pacchetto che arriva in ritardo potrebbe
1.7. SISTEMI CLIENT-SERVER IBRIDI 31 essere non più utile. Protocolli di rete come TCP che assicurano la trasmissione a dabile dei pacchetti introducono una forte latenza che potrebbe rendere l'appli- cazione impraticabile e dunque non è applicabile in questo contesto.
Tuttavia ci sono casi in cui per mantenere la correttezza dell'applicazione occorre la trasmissione a dabile: in questo caso si utilizza il protocollo Shaker. A dierenza del TCP che garantisce sempre il trasporto a dabile Shaker ritrasmette i pacchetti solo quando entrambi sender e receiver lo ritengono necessario.
Implementazione Il multicast re ector è una entità capace di mantenere un peer group di client; il suo compito principale è inviare in broadcast a tutti i client del gruppo i messaggi che riceve. Ogni multicast re ector può gestire diversi peer group: per distinguere i gruppi basta assegnare ad ognuno di essi una porta diversa. Un'area di interesse può essere coperta da un singolo peer group oppure da molti peer group, anche gestiti da diversi multicast re ector. Vedremo nei paragra successivi un meccanismo per permettere le comunicazioni tra i peer group che coprono la stessa area di interesse.
Comunicazioni tra i peer Il peer che vuole comunicare con i gli altri peer dell'a- rea di interesse invia un pacchetto IP unicast al multicast re ector di competenza; i re ector non supportano IP multicast in quanto ritenuto inappropriato per gestire numerosi gruppi di piccole dimensioni e molto dinamici per le frequenti connessioni e disconnessioni. Il re ector genera tanti pacchetti IP unicast per quanti sono i peer appartenenti al peer group.
Inoltre i multicast re ector supportano il protocollo Shaker: serializzano i pacchetti con una numerazione progressiva e buerizzano i pacchetti no a raggiungere una soglia stabilita per permettere la ritrasmissione.
Sottoscrizione a un gruppo: livelli di a nità L'appartenenza di un peer a un gruppo è espressa da un valore che di a nità che determina il livello di partecipa- zione che il client desidera avere in un certo gruppo. Il livello di a nità rappresenta una sorta di ltro che permette a un peer di ricevere solo le informazioni che cor- rispondono al livello prescelto. Più alto è il livello di a nità e di conseguenza più numerose saranno le informazioni che il client riceverà.
Per il gruppo che rappresenta l'area della locazione di un certo peer, esso stesso avrà interesse a ricevere tutte le informazioni quindi si sottoscriverà a questo gruppo con un alto valore di a nità; per le locazioni con nanti con la sua posizione invece si sottoscriverà con un valore più basso.
Invio di pacchetti con livello di a nità Come detto precedentemente un peer esegue la sottoscrizione ad un gruppo con un certo livello di a nità; per esempio supponiamo che la scala di a nità sia compresa tra 1 e 5 e che il peer P1 sia sottoscritto al gruppo G con a nità 3. Il peer P1 può inviare un pacchetto al peer group G con un livello di a nità uguale o inferiore al livello di a nità con il quale il peer è sottoscritto al gruppo, in questo esempio P1 può inviare il pacchetto con a nità 1, 2 oppure 3; supponiamo che invii con a nità pari a 3. Il pacchetto sarà ricevuto da tutti i peer sottoscritti al gruppo G con a nità almeno 3 (maggiore o uguale 3).
Quando un peer invia pacchetti con un elevato valore di a nità signi ca che l'informazione è destinata a un ristretto numero di peer; come visto nell'esempio, solo i peer sottoscritti al gruppo con a nità maggiore o uguale a 3 riceveranno il pacchetto.
I peer devono sottoscriversi ai multicast re ectors per poter inviare i pacchetti. I multicast re ectors di uno stesso gruppo e con stesso valore di a nità si sottoscrivono a vicenda, mentre quelli con valore di a nità più alto si sottoscrivono a esattamente uno di livello più basso.
Inoltro dei pacchetti da parte dei multicast re ector Un multicast re ector inoltra un pacchetto a un altro multicast re ector solo se il pacchetto proviene da un host; infatti se non fosse così si potrebbe veri care che un re ector riceva un pacchetto più volte. Un re ector può facilmente sapere se un pacchetto proviene da un host oppure da un altro re ector esaminando se il numero di sequenza è impostato o meno.
Conclusioni Il sistema preso in esame in questa sezione rappresenta una soluzione ibrida tra l'architettura client-server e un sistema peer-to-peer. L'aspetto centra-
1.8. SISTEMI P2P IBRIDI 33