MMG – Sim
Massive Multiplayer Gaming Simulator
REQUISITI :
- Windows
- Un buon computer
- OpenGL
MODULI IN C :
- MMGIN : Modulo di gestione Input Parametri
- MMGCL : Modulo di gestione Client-side
- MMGSERV : Modulo di gestione Server-side
- MMGDEFS : Definizioni delle strutture, tipi ed operazioni di base
- MMGGR : gestione Grafica OpenGL
- MMGRND : gestione generazione numeri casuali
- MMGISC : gestione routines inter-server (InterServerCommunication)
- MMGDDM : Data Distribution Management locale e inter-server
- MMGGV : definizione delle variabili globali
- MMGWOD : definizione di oggetti, messaggi simulati e altro
- MMGSUPU : gestione SUbscribe/PUblish e operazioni su aree
- MMGAI : Modulo di gestione Intelligenza Artificiale Avatars
- MMGSIM : Controllo Centrale Simulazione
I moduli MMG sono esclusivamente di nostra creazione riga per riga e sono stati compilati con Dev
C++ (Bloodshed Software) sotto Windows XP. Righe di codice totali = 5.450 (circa).
INDICE
-
1.0 - Intro
o 1.1 – Punti focali
o 1.2 – Virtual World Partitioning
o 1.3 – Il Simulatore su Livelli
o 1.4 – Il gioco simulato
-
2.0 – Client
o 2.1 – Intro e Struttura generale
o 2.2 – Interazioni e protocollo conservativo
o 2.3 – Client V-Map
o 2.4 – Ghost Effect
o 2.5 – Protocollo Ottimistico
o 2.6 – Avatar Artificial Intelligence
-
3.0 – Server
o 3.1 – Intro
o 3.2 – FrontEnd Module
o 3.3 – ServerMap Module
 3.3.1 – Generale
 3.3.2 – Struttura
 3.3.3 – Tile SubMap Control
 3.3.4 – Object Locking
 3.3.5 – Tiles
o 3.4 – BackEnd Module & DataDistribution Module
 3.4.1 – Back End Module
 3.4.2 – Data Distribution Module
o 3.5 – Concorrenza Moduli BackEndMod e DDMod
o 3.6 – Data Distribution Management
 3.6.1 – Sottoscrizioni e Pubblicazioni
 3.6.2 – DDM Locale
 3.6.3 – DDM Inter-Server e Comunicazioni
-
4.0 – Migrazioni
o 4.1 – Migrazioni : Ownership Switch
o 4.2 – Protocollo di Migrazione
o 4.3 – Migrazione in dettaglio
o 4.4 – Migration Table
-
5.0 – EnGen : Virtual World Environment Generator
-
6.0 – Simulatore
o 6.1 – Event List
o 6.2 – Struttura di una simulazione MMG-Sim
-
7.0 – Generatore Numeri Casuali e Statistiche Output
o 7.1 – Random Generator
o 7.2 – Statistiche di Output
o 7.3 – Struttura Report
o 7.4 – Parametri Input
-
8.0 – Funzionamento del Simulatore
INTRO
Il simulatore di nostra creazione MMG-Sim è l’implementazione di un gioco multiplayer vero e proprio, dotato di un’
architettura distribuita di supporto. L’esecuzione prevede l’osservazione dell’evoluzione dell’intera realtà simulata
tramite settaggio di parametri di input e conseguente generazione di files di output.
Gli scopi principali del simulatore sono la valutazione di scalabilità e workload, oltre alla valutazione del
comportamento di nuovi meccanismi da noi ideati e sperimentati, come il Tile SubMap Control, Object Locking, CVMap ed altri che saranno presentati in seguito.
1.1 - PUNTI FOCALI
Il Virtual World dinamico da noi implementato è costituito da diversi Servers, ognuno mantenente una propria
partizione. Una volta attivi nella rete simulata, si inseriscono dinamicamente andando ad “agganciarsi” ai Servers già
presenti, in maniera toroidale creando ed espandendo gradualmente un mondo virtuale illimitato.
Il Simulatore prevede inoltre che i Servers entranti, prima dell’attivazione nella rete, accedano a un vero e proprio
database simulato di generazione Environment (con codice parzialmente condiviso) chiamato EnGen (vedere capitolo
EnGen).
1) Alcuni protocolli ed alcuni dettagli implementativi sono stati adattati alle necessità della particolare istanza di gioco
simulato e soprattutto ai limiti fisici del calcolatore.
2) Le entità simulate ( Clients e Servers ) evolvono il proprio stato (variabili locali) tramite Message-Passing.
Il Message-Passing non è simulato in modo astratto, ci sono veri e propri messaggi dotati di diversi tags, che vengono
trasferiti in quantità massive da una coda all’altra e vengono renderizzati o interpretati nella realtà simulata in modo
diverso a seconda della coda (o buffer o canale) e dell’entità in cui essi si trovano.
Per semplicità, la struttura del messaggio simulato è unica in tutta la realtà simulata ed è quindi dotata di Multi-Purpose
Tags.
3) Perché usare più Servers e non un’architettura pienamente centralizzata? Perché non usare il fully peer to peer?
Lo scopo di questa architettura simulata è proprio quello di distribuire il carico di lavoro (workload) tra i Servers
presenti nel Virtual World. La struttura ibrida tra centralizzata e peer to peer è a tutt’oggi la più scalabile e la più usata
per il massive muliplayer gaming:
-
Cresce il numero di Clients  Cresce il workload del (dei) Server(s).
Cresce il numero di Servers  Diminuisce il workload di ogni Server.
1.2 - VIRTUAL WORLD PARTITIONING
Gli approcci di Partitioning del VW al Massive Multiplayer Gaming sono principalmente 3 :
-
Spatial Partitioning
Temporal Partitioning
Functional Partitioning
L’approccio da noi seguito è lo Spatial Partitioning : ogni server gestisce una partizione ben precisa del VW e
soprattutto totalmente indipendente.
Dal documento “A Scalable Architecture for Supporting Interactive Games on the Internet” (Wentong CAI, Percival
XAVIER, Stephen J. TURNER, Bu-Sung LEE) :
“Spatial Partitioning : This is based on partitioning the virtual world into areas that can be processed in parallel and
independently. Therefore, the players in the same part of the Virtual World can interact with each other through the
same server.”
1.3 - IL SIMULATORE SU LIVELLI
Il simulatore MMG-Sim è sviluppato concettualmente su più livelli :
Realtà simulata
- LIVELLO 0 : (entità simulata) Client
- LIVELLO 1 : (entità simulata) Server
- LIVELLO 2 : Rete di comunicazione inter-Server (ISC)
Mondo Reale
- LIVELLO 3 : Simulatore
- LIVELLO 4 : Utente
Alcuni di questi livelli comunicano tra loro, come i clients, i servers e ISC, così come il simulatore e l’utente stesso
(sono disponibili diversi eventi esogeni e periodici di input, con i quali inizializzare la simulazione).
E’ bene notare però che il simulatore vero e proprio si preoccupa unicamente di gestire e simulare la concorrenza degli
eventi generali e la tempistica - il quando - ma ha poco contatto o comunque in maniera parziale con cosa sta accadendo
nella realtà simulata. Le entità simulate inoltre – clients e servers - non hanno concezione del tempo.
Dato il livello di dettaglio raggiunto della realtà simulata, il simulatore MMG-Sim dà la possibilità di un’ulteriore
interfaccia extra dei livelli - non standard :
Realtà simulata
- LIVELLO 0 : (entità simulata) Client / UTENTE
- LIVELLO 1 : (entità simulata) Server
- LIVELLO 2 : Rete di comunicazione inter-Server (ISC)
Mondo Reale
- LIVELLO 3 : Simulatore
- LIVELLO 4 : ( Utente ? )
Questo significa che si dà la possibilità all’utente di essere lui stesso un’entità simulata (client) all’interno della
simulazione e interagire in modo diretto con i livelli superiori.
Questa modalità permette di avere un feedback diretto su ritardi, migrazioni, ecc… ma è (stata) utilissima soprattutto a
scopi di debug e testing dell’architettura simulata con presenza umana.
Più in dettaglio, tramite l’ascolto da tastiera da parte della window, l’utente interagisce direttamente con un determinato
Avatar selezionato (quindi non soggetto a movimenti A.I.) :
Evento Key-Press nella Window  Generazione Evento Sim. CLIENTSENDMSG 
Creazione del messaggio simulato da parte del Simulatore  messaggio accodato nel buffer di
uscita client e spedizione nella realtà simulata.
Ovviamente a scopi statistici se ne sconsiglia l’uso, dato che l’utente “falsa” i risultati direttamente dall’interno della
realtà simulata.
1.4 - IL GIOCO SIMULATO
Il semplice gioco implementato rappresenta un mondo virtuale generato da più servers, che diversi Avatars
(rappresentazioni virtuali dei clients) esplorano tramite movimenti, cercando di raccogliere vari items che
incrementeranno il proprio scoring.
CLIENT
2.1 - INTRO
Il client è sicuramente l’entità principale della realtà simulata dopo il Server. Quest’ultimo non avrebbe nulla da
processare senza le interazioni e i messaggi inviati dal client, rimanendo così inutilizzato (IDLE) nella rete di servers
simulata.
STRUTTURA GENERALE
La struttura Client nel nostro simulatore è particolarmente “leggera”, contiene delle variabili locali come l’ID (indirizzo
di rete), il server a cui è connesso (se lo è), il FrontEnd ID ed infine variabili di gioco (gamestatus) che verranno
modificate tramite messaggi di Update da parte del Server (Es: current position, score, ecc…).
Ogni Client è dotato di un buffer di ingresso per gli Updates, una coda di uscita, più 2 buffers di ingresso Environment
(canali INV ed ENV).
I buffers di entrata, ricevono quasi costantemente messaggi che sono inviati dal server.
Ogni messaggio di tipo environment, viene singolarmente renderizzato tramite una semplice trasformazione di
coordinate relativa alla posizione corrente del client, mentre vengono interpretati in altro modo i messaggi di tipo
Update.
2.2 - INTERAZIONI con Server Update
Protocollo Conservativo
Nel nostro caso, il client interagisce con l’ambiente creato dal Server tramite movimenti. I movimenti sono spediti verso
il Server in forma vettoriale (Es: (-1,0) è uno spostamento a sinistra, (1,0) è uno spostamento a destra).
Una volta giunto il messaggio al Server, questo aggiornerà, in caso di movimento possibile, la propria Position Table
con la nuova posizione dell’avatar in questione, rispondendo al client con le nuove coordinate assolute (non vettoriali).
A questo punto il client aggiornerà le sue variabili di posizione e attiverà lo shift di visuale.
La presenza di una coda di uscita client Q-Out, che simula il canale di comunicazione verso il Server, fa sì che venga
preservato implicitamente l’ordinamento temporale locale delle interazioni generate. Messaggi generati da clients
diversi invece, giungono al Server a seconda del ritardo corrente del client, quindi maggior ritardo significa più
probabilità che il messaggio sia valutato e processato nella coda di ingresso Server dopo altri clients con meno ritardo.
Il client, nel protocollo implementato, non invia updates di posizione ad una data frequenza, ma comunica con il server
soltanto in caso di interazioni - che in qualche modo potrebbero modificare lo stato della mappa (e i movimenti lo
fanno).
E’ presente inoltre, l’unica applicazione Client-side (poco usata e sperimentata) che se attivata, in caso di coda di uscita
(Q-Out) piena, “fonderà” i messaggi di movimento più vecchi:
Es:
(-1,0) e (-1,0)  (-2,0)
(-1,0) e (1,0)  (0,0)  cancellazione (movimento nullo)
Questo per non permetterne la perdita, per quanto possibile. Per l’idea ci siamo ispirati proprio al merging dei
movimenti (eventi) generati dal mouse.
Future Espansioni: Decompressione del movimento Server-side in più messaggi / Algoritmi di calcolo movimenti
intermedi tra i 2 punti A e B.
2.3 - (Mnemonic) CLIENT VISUAL MAP – CV-Map
La visuale mnemonica del client è sicuramente la sua struttura più importante, è ciò che vede il client entro un
determinato raggio ma non sempre contiene uno stato consistente (a differenza della mappa del Server).
Quello che abbiamo “ideato” è una visuale cui il meccanismo ricorda molto la memoria cache (da qui mnemonic),
grazie ad un sistema di shift secondo un certo vettore spostamento <dx,dy> che “conserva” i dati (gli oggetti) già
scaricati di recente.
Accade quindi che una nuova porzione (di cui il client non sa nulla) viene scoperta e che una viene persa. Il client
richiederà solamente questa nuova porzione al Server (nel simulatore chiamata Update Region), riducendo al minimo
indispensabile l’informazione richiesta e quindi il traffico locale. Statistiche alla mano, con un ambiente di complessità
media, si parla in media di circa 5/6 oggetti ENV e circa 2 oggetti INV ricevuti per movimento
(ERANGE = 4, IRANGE = 2). Considerando in questo caso una visuale di [(ERANGE*2)+1]2 oggetti = 9 x 9 = 81, il
rapporto sembra buono.
Questo nel caso in cui il TILESIZE = 1, per TILESIZE maggiori, il meccanismo è un po’ più complesso e si fa uso di
ulteriore “memoria visiva”.
Il raggio di Environment interattivo è stato chiamato IRANGE e quello di Environment ERANGE. Nell’immagine
sopra, il client è sottoscritto ad ambedue i canali INV ed ENV (celeste) e solo ENV (blu).
Oltre ai propri movimenti e le Update Regions scaricate, il client grazie alle sottoscrizioni, riceverà anche eventuali
modifiche dell’ambiente generate da altri avatar o movimenti di avatar stessi.
Si registrano ovvi picchi nei canali Environment ad ogni LOGIN di un client, poiché appena entrato, ha
necessariamente bisogno di richiedere tutta la V-Map.
La mappa del client in ogni caso, come è stato detto, non si limita al
raggio di Environment, ma è più capiente.
Nell’immagine, l’avatar blu è sottoscritto nell’area chiara ad
entrambi i canali (per questo vede tutti i movimenti dell’avatar
verde fino a che non ne uscirà), nell’area meno chiara solamente
all’Environment (ENV) e nell’area scura non è sottoscritto a nulla
(no longer relevant) ma contiene oggetti per via dello shift sopra
citato e rappresenta la Memoria Visiva di un Client, ovvero ciò che
ha visto e che appartiene al passato (non è quindi un’area consistente e aggiornata). Per l’utilità esatta di quest’ area
additiva, vedere Tiles nel documento ServerMap.
I risultati di questi meccanismi, combinati all’uso dei Lock (vedere ServerMap), risultano in una riduzione estrema dei
messaggi necessari alla renderizzazione dell’ambiente, con guadagni enormi sul traffico dei canali locali della
partizione e workload dei canali Environment.
2.4 - EFFETTO GHOST
Il Ghost Effect è un classico esempio di inconsistenza sulla visuale del client: si tratta della duplicazione di un avatar
nel campo visivo del client, pur essendo in un’altra posizione anche molto distante, creando un “ghost” o avatar del
tutto inesistente.
I motivi sono principalmente questi (nel nostro simulatore):
-
Congestione canali Environment : vengono molto ritardati o addirittura persi i messaggi di cancellazione della
posizione precedente dell’avatar).
Perdita del messaggio da parte della rete stessa.
Alcuni casi durante migrazione da una partizione all’altra.
In casi di altissimo workload dei canali Environment, può verificarsi che i ghosts siano più di uno con “effetto scia” da
parte degli avatars nemici. Nel simulatore cambiando alcuni parametri non è difficile ottenere questo effetto.
2.5 - INTERAZIONI con DEAD SERVER RESPONSE PROTOCOL (DSRP)
Protocollo Ottimistico
Questo protocollo non standard del simulatore, può essere attivato tramite i file di input.
Si tratta di una tecnica ideata per questo tipo di gioco (in realtà implementata solo in parte nei giochi reali e solo in
determinate situazioni) e se usata nel modo giusto può dare – entro certi limiti - l’impressionante sensazione al client di
NON avere ritardo.
Rispolverando il protocollo classico (pessimistico) del server implementato nel simulatore, si prevede che il client
debba aspettare il ritorno del messaggio di Movement Update prima di aggiornare la propria posizione e attuare lo shift
della propria visuale.
Con il DSRP invece, il client si muove in ogni caso localmente, aggiornando la nuova posizione e compiendo lo shift,
PRIMA che il messaggio di movimento sia arrivato effettivamente al Server. Nel caso in cui la posizione richiesta era
libera o comunque possibile non c’è problema, ma cosa succede se così non è?
Si era pensato di implementare un’applicazione client-side che riconoscesse localmente che il movimento non è fattibile
(come in moltissimi giochi in rete – Unreal Tournament) ma nel nostro caso c’è un margine di errore per quanto
riguarda la visuale del client (qualche messaggio environment che non è stato renderizzato o è stato perso) che non è
quindi del tutto attendibile. Potrebbe quindi succedere che non sia presente (unrenderized) un oggetto solido a diretto
contatto sulla visuale client, ma che in realtà è presente sul server  il client ha il “permesso locale” di muoversi, ma
sulla ServerMap è rimasto fermo  fuori sincronizzazione.
Quindi l’idea è che il client si muova sempre e comunque, ma con la differenza che quando il movimento è arrivato al
Server, se questo non era possibile, il Server spedisce un messaggio di rollback Move, ovvero un movimento al
contrario rispetto alla richiesta del client che lo farà tornare nella giusta posizione e nello stato consistente.
Se il gioco fosse stato più complesso, con interazioni non passibili di rollback, questo non sarebbe stato possibile, ma
poiché il nostro gioco consiste principalmente in semplici movimenti, non sono pervenuti problemi di questo tipo.
Visivamente parlando accade che il player sembra entrare per un attimo dentro un oggetto solido per poi uscirne,
creando uno strano effetto elastico. La durata di questo effetto dipende dal ritardo del Server.
Ci sono però alcuni svantaggi e problemi:
-
Molti più Ghost-Effects ma diversi : nel protocollo pessimistico erano “dead” (del tutto immobili e inesistenti)
con il DSRP si presenta in addizione un ghost “vivo”, che rispecchia cosa sta realmente accadendo sulla
mappa del Server (sarebbe possibile eliminarlo localmente).
Si creano leggere inconsistenze tra clients nel caso si “vedano”.
Si possono creare anomalie durante una migrazione.
Funziona solo se il client si muove con una relativamente bassa-media velocità, per dare il tempo all’Update
Region di giungere al client (che non vedrà quindi immediatamente). Nei casi di estrema velocità, l’avatar può
“sfondare” un certo orizzonte (precisamente quando il Delta di inconsistenza “geometrica” tra visuale server e
visuale client è superiore al raggio di ENV) e non avere ancora a disposizione gli oggetti solidi di immediata
vicinanza, con probabile overhead di messaggi di rollback move in cascata.
Questo protocollo non default, è stato affiancato come “extra” a quello pessimistico a scopi di testing di protocolli
ottimistici.
2.6 - AVATAR ARTIFICIAL INTELLIGENCE
Nel simulatore è presente un modulo in C (MMGAI) che tramite semplici funzioni, governa la AI degli avatars.
Nei vari risultati, dalle migrazioni, ai Tile-cross, fino al workload del server, si nota come i movimenti (o interazioni) di
un client, abbiano un loro peso.
Ad esempio, quando un client si muove verso un oggetto solido o comunque invalicabile (walls, altri avatars), la sua
interazione (protocollo classico) verrà semplicemente scartata dal server. In ogni caso però, il messaggio è giunto nella
coda di processo ed è stato valutato. Ora immaginando una grande quantità di questi messaggi, il risultato è che solo
poche interazioni hanno effettivamente generato un cambiamento nella mappa del Server, con un carico di lavoro
abbastanza pesante ed inutile.
Nella realtà, un Avatar governato da un’ intelligenza umana eviterà ovviamente di muoversi verso un muro. Per questo
alcuni input del simulatore danno la possibilità di settare valori quali ad esempio la percentuale di
SolidObjectsAvoidance (capacità di evitare collisioni con oggetti solidi) e collectScoreObjects (capacità di dirigersi
verso score-objects), permettendo di incrementare o diminuire “l’intelligenza” dei clients simulati.
SERVER
3.1 - INTRO
Il Server è sicuramente l’entità simulata principale nel nostro simulatore ed anche quella più complessa in assoluto.
Oltre a gestire diverse attività, ha il compito di mantenere aggiornata la partizione, alla quale tutti i clients connessi si
devono attenere.
Il Server simulato è diviso virtualmente in più moduli:
-
FrontEnd Module
ServerMap Module
Data Distribution Module
BackEnd Module
Di questi moduli che compongono la struttura globale del Server, due di essi sono “passivi” e forniscono servizio
implicito e non diretto: la ServerMap e il FrontEnd, mentre gli altri due sono considerati “attivi”, cioè elaborano
messaggi .
3.2 - FRONT END MODULE
Il modulo FrontEnd si occupa di gestire e mantenere informazioni sulle connessioni con i clients.
I messaggi entranti vengono direttamente inviati alla coda principale di processo del BackEnd, mentre quelli uscenti provenienti dal modulo di DataDistribution - ai clients.
Inoltre ha l’importante compito di aggiornare il Forced Delay per sincronizzare l’invio dei messaggi in uscita.
FRONT-END MODULE LOCAL SYNCHRONIZATION (Forced Delay)
Considerando il fatto che i clients presenti in una partizione possono avere ritardi diversi, se il modulo DataDistribution
locale ( Unicast degli updates e Multicast environment ) distribuisse senza sincronizzazione i messaggi, porterebbe i
clients connessi a stati tra loro inconsistenti, nel caso in cui più avatars siano presenti nella stessa area.
Per evitare questo, nel modulo FrontEnd del Server, è presente una variabile, aggiornata al momento opportuno, che
mantiene il ritardo massimo tra i clients presenti nella partizione. Grazie a questa variabile, il FrontEnd sincronizza tutto
il pacchetto corrente di messaggi (sia Updates che Environment) su quel ritardo, consentendone la ricezione simultanea
da parte dell’intera partizione.
Ovviamente questo meccanismo implica una grossa influenza da parte del client con più ritardo (come in molti giochi
multiplayer esistenti).
3.3 - SERVER MAP MODULE
ScreenShot di una partizione del Virtual World.
3.3.1 - GENERALE
La mappa del Server, insieme al modulo BackEnd è forse
la struttura più importante della nostra realtà simulata. In
qualunque momento conserva uno stato consistente di
tutto ciò che sta accadendo nella partizione, ed è la realtà
locale alla quale tutti i clients si devono attenere.
Grazie alla creazione di sotto-strutture come i
TileControl, tutte le sottoscrizioni e intersezioni di ranges
degli avatars sono ad accesso diretto da parte del Server,
quindi 0 algoritmi di calcolo intersezioni Server-Side, 0 Channel-Tables, ecc...
Il tutto al costo di una struttura abbastanza “pesante” della mappa, ma alleggerita dall’uso delle CbitList (liste di
sottoscrizioni client in bits) e merge dei TileControl.
Inoltre non sembrerebbe molto complessa un’ulteriore implementazione di sottoscrizioni di uno stesso Avatar a più aree
diverse dislocate sulla mappa (caso del pluripremiato gioco multiplayer di strategia Age Of Empires II).
3.3.2 - STRUTTURA
MapCell :
Unità atomica della mappa, può contenere un singolo oggetto (campo obj).
L’intera mappa del Server (partizione) è un array[X][Y] di mapcell.
La struttura MapCell contiene:
- Status
- Obj
-
Tile SubMap Control (puntatore a)
Status :
Stato (byte) della MapCell, contenente diversi flags:
-
BIT Lock
BIT Position Preserve (unused)
BIT Published (usato solo per rappresentazione grafica)
Obj :
L’oggetto (signed byte) contenuto nella MapCell. Sono definiti nel modulo MMGwod e sono virtualmente divisi in
“Dynamic” (avatars), “Semi-Static” e “Static” (oggetti che non subiranno modifiche nel tempo - quelli soggetti a Lock).
3.3.3 - Tile SubMap Control (TC)
Il Tile SubMap Control o TC è una struttua di nostra ideazione che contiene liste di sottoscrizioni per ogni canale (nel
simulatore sono ENV e INV).
A livello di codice è stato ottimizzato al limite, usando tipi di dato interpretati come liste di bits.
Es: CBITLIST = unsigned int = 32 bits = 32 Clients supportati, dove il bit i-esimo rappresenta lo stato di sottoscrizione
al canale (ON, OFF) del player i-esimo, con <i> che corrisponde all’ ID locale assegnato dal server (il FrontEnd ID di
un determinato Client).
Es: Se il bit 0 del canale ENV è acceso, significa che il Player locale con FrontEnd ID = 0 è sottoscritto al canale
Environment. Ovviamente se anche il bit 0 del canale INV è acceso, Il player in questione è sottoscritto ad ambedue i
canali.
Il TC è quindi un array[ NUMCHANNELS ] di CBITLIST (NUMCHANNELS = 2).
Es: CBITLIST = unsigned short = 16 bits * NUMCHANNELS = 32 bits per tutte le sottoscrizioni locali al Tile (!!).
ScreenShots con TILESIZE = 1 e TILESIZE = 2 rispettivamente.
Si può notare il “merging” dei TCs nel secondo caso (punte convergenti).
L’Area blu rappresenta la zona di sottoscrizione al canale ENV, mentre quella celeste la zona di sottoscrizione ad entrambi i
canali (ENV e INV).
3.3.4 - Object Locking
Quando un player si muove, in genere si sottoscrive ad una nuova area per un certo canale (nel nostro simulatore la
sottoscrizione di un client viene fatta dal Server stesso, considerata implicita nel movimento dell’Avatar) e richiede una
porzione di mappa al server (nel simulatore è chiamata Update Region – Vedere Client).
Se più richieste di questo tipo sono processate in blocco, e se ci sono intersezioni di ranges tra players, quello che
accade è che l’area di intersezione delle varie Update Regions viene pubblicata più volte. Sapendo che il Multicast si
occuperà della duplicazione di messaggi, queste pubblicazioni multiple sono uno spreco enorme e potrebbero in qualche
caso saturare i canali Environment.
Per questo motivo quando il server riceve una richiesta di Update Region, tutti gli oggetti (static) appartenenti a quella
regione, diventano “locked” (flag di status della MapCell), ovvero il server NON pubblicherà ulteriori richieste per
l’area in questione all’interno del ciclo di message processing. I Lock verranno poi resettati dal modulo di Data
Distribution.
Considerando una zona con molti avatars vicini (ranges intersecati), caso
frequente, gli shared lock sulla ServerMap sono molti e il carico dei canali
di Environment per quel gruppo di players, tende ad approssimarsi a quello
di un singolo player.
Dalle simulazioni effettuate, i Lock danno un ottimo contributo alla
diminuzione di messaggi in queste situazioni.
ScreenShot : Il simulatore è in pausa nel momento in cui più avatars hanno
effettuato una richiesta al Server. I Lock sono evidenziati in bianco.
3.3.5 – Tiles
I Tiles sono raggruppamenti di MapCell (nel nostro caso quadrati, ma nulla vieta possibili modifiche con tiles esagonali
o con altre forme).
Quando il Server inizializza la mappa, un particolare e complesso algoritmo, a seconda del TILESIZE, compie un
“merge” dei puntatori a TileControl, portando più MapCell a fare riferimento allo stesso TC.
TILESIZE 1x1 e 3x3 rispettivamente.
TILESIZE per default è 1, cioè corrisponde alla singola MapCell.
Tile Cross : passaggio di un avatar da un tile all’altro.
Dalle simulazioni compiute, al Crescere del TILESIZE :
VANTAGGI:
-
Meno richieste di Update Region: solamente quando l’avatar si avvicina al bordo del Tile.
-
Molti TileControl in meno, quindi minore memoria utilizzata dal Server per il modulo di gestione mappa.
-
Più intersezioni quindi più Lock.
Cresce molto il Lock-Gain, ovvero la percentuale di guadagno sulle pubblicazioni ottenuto con i Lock, in altre
parole gli oggetti non ri-pubblicati perché “visivamente” condivisi.
SVANTAGGI:
-
Maggior numero di messaggi inviati per ogni richiesta. L’area pubblicata è più grande, si “aggancia” per
estensione ai bordi dei Tiles.
Percentuale di utilizzo dei canali di Environment meno costante, imprevedibile, con picchi (dipende fortemente
dal tipo di movimento di un avatar). TILESIZE basso significa invece più costanza, più “fluidità” dei canali nel
tempo e meno perdite di messaggi.
-
Aumentare la capienza dei canali per non perdere messaggi. In caso di perdita, può verificarsi l’effetto Ghost
nella visuale del client, oltre alle eventuali perdite di oggetti statici.
La capienza della Visuale Mnemonica del client (Client V-Map) deve essere incrementata per contenere i Tiles
oltre il raggio di ENV (ERANGE).
3.4 - Data Distribution Module & Back End Module
3.4.1 - BACK END MODULE
Il modulo BackEnd è il cuore del Server. Ha il compito di processare sia i messaggi nella coda di entrata principale Qin, sia i messaggi provenienti da altri Servers mantenuti in un’altra coda di comunicazione (InterServerCommunication
Queue).
Si può immaginare il BackEnd a diretto contatto con il modulo ServerMap: tutti i messaggi processati nella coda di
entrata locale (interazioni dei clients) modificano direttamente lo stato della partizione (Server Map).
Il BackEnd, a causa dell’elevato carico della coda Q-in, valuta e processa i messaggi in blocchi (mantenendone l’ordine
sequenziale) in quello che viene chiamato ciclo di message processing. Durante questo ciclo, vengono generati vari
messaggi di ritorno che vengono smistati ed inviati nel modulo di DataDistribution :
-
Messaggi di Update nella coda di uscita server Q-Out.
Messaggi di Environment ulteriormente smistati nei 2 canali ENV ed INV: le informazioni contenute in essi
sono complementari e rappresentano l’Environment locale pubblicato.
3.4.2 - DATA DISTRIBUTION MODULE
Nel modulo DDMod, i messaggi di Update vengono inviati ai clients (tramite FrontEnd) con metodo Unicast, mentre
l’ambiente (Environment) diviso in 2 canali ENV ed INV (rispettivamente Environment e Interactive-Environment) con
metodo Multicast.
Il Data Distribution Management (DDM) interno al modulo, insieme al modulo ServerMap, grazie alle sottoscrizioni, si
occuperà poi di decidere il destinatario (Unicast) o i destinatari (Multicast) del messaggio.
(Vedere capitolo Data Distribution Management).
La struttura flessibile dei canali dà la possibilità in futuro di implementare anche più di 2 canali di tipo Environment.
3.5 - CONCORRENZA DEI MODULI DDMod e BackEnd
I 2 moduli DataDistribution e BackEnd lavorano per un certo lasso di tempo in concorrenza.
Pur avendo compiti diversi, il Back End si troverà sempre in stato BUSY:
CICLO DEL SERVER
-
Main Process : processo sequenziale delle 2 code di entrata ISC-Queue IN e Q-IN. Il DDMod è in stato IDLE
poiché l’intensa attività di processo richiede tutte le risorse del Server
Terminata l’attività di processo principale, il modulo di Data Distribution entra in stato BUSY ed inizia le
attività di unicast e multicast. In concorrenza, il modulo BackEnd effettua periodicamente ad intervalli
regolari, un controllo sulla coda di entrata inter-server ed eventuali invii di messaggi ad altri servers tramite
ISC-Queue OUT.
Durante l’attività di distribuzione, si potrebbe pensare di ricominciare direttamente il main process, ma si è preferito
non farlo, in quanto si rischia di saturare i canali Environment e la Q-out, andando a caricare in maniera eccessiva il
modulo di distribuzione. Ovviamente la distribuzione dei carichi di lavoro tra i 2 moduli, dipende dai molti parametri
(come il carico previsto, la larghezza di banda settata, la capienza dei canali, ecc…).
ScreenShot dello stato di un server.
3.6 - DDM : Data Distribution Management
3.6.1 - SOTTOSCRIZIONI e PUBBLICAZIONI
Per come è stata concepita l’intera struttura, le sottoscrizioni vengono effettuate per un certo determinato canale e per
una certa area (regione). La sottoscrizione di un’area da parte di un avatar viene effettuata nel nostro caso dal server
stesso, che aggiornerà (sposterà) la regione in questione ad ogni movimento del Client.
Esempio di sottoscrizione a canali in un gioco reale – Screenshot da Age Of Empires II. Area chiara sottoscritta ad
Interactions ed Environment, area scura solo Environment.
Nel nostro caso, le sottoscrizioni avvengono in modo diretto sul modulo ServerMap tramite i Tile SubMap Control
(vedere ServerMap), non esistono “Extent Tables” a livello server, né tantomeno algoritmi server-side per calcolo
intersezioni ed altro.
Ovviamente si paga in termini di memoria del server, dato che il ServerMap Module occupa oltre il 90% dell’intera
struttura Server, il tutto è stato però ottimizzato usando liste di sottoscrizione con operazioni bit a bit e tecniche di
TileControl merging (vedere ServerMap).
Da questa struttura “pesante” della mappa del Server, che oltre a mantenere lo stato consistente quindi, gestisce anche
una sotto-griglia di Tile Control e sottoscrizioni, il modulo di Data Distribution risulta di una semplicità estrema.
3.6.2 - DDM LOCALE
Il nostro DDM agisce con 2 metodi (Unicast e Multicast) :
UNICAST
Riguarda i messaggi di Update, Accounting, Scoring e tutto ciò che interessa il singolo client per aggiornare le proprie
variabili locali.
Il modulo di distribuzione, a seconda del tag ID (indirizzo di rete simulato del client) contenuto nel messaggio, deciderà
il singolo destinatario effettuando la spedizione tramite FrontEnd.
MULTICAST
Riguarda la spedizione di messaggi Environment generati dal modulo di BackEnd del Server smistati sui 2 canali.
Proprio in questa fase intervengono i Tile SubMap Controls: per ogni singolo messaggio, grazie a velocissime
operazioni bit a bit, il modulo di distribuzione andrà a controllare lo stato di sottoscrizione (ON/OFF) per il determinato
canale - date le coordinate relative alla mappa locale contenute nel messaggio – e di conseguenza spedirà i messaggi a
tutti quelli che sono sottoscritti per quella determinata posizione <x,y> (vedere TileControl).
3.6.3 - DDM INTER-SERVER e Comunicazioni
Per quanto riguarda la distribuzione dei messaggi inter-server, ogni messaggio in attesa di invio nella coda di uscita
ISC-Out contiene all’interno 2 tags, corrispondenti al server di origine ed al server di destinazione. Se un server ha
l’intenzione di spedire a tutti gli altri servers del Virtual World un messaggio di tipo pubblico, il campo di destinazione
di tale messaggio conterrà la costante TOALL, sarà poi l’infrastruttura ISC ad occuparsi dello smistamento molteplice
del messaggio.
Un esempio è l’entrata (attivazione) di un nuovo Server nel Virtual World, evento che interessa tutti i restanti servers (se
ce ne sono).
1) Il Server entrante spedisce nella rete ISC un messaggio pubblico che informa i server già presenti della nuova
attivazione.
2) I Servers riceventi, già presenti nella rete, risponderanno al server di origine con un messaggio di Acknowledge.
3) Ricevuto il messaggio, il Server invocherà la routine di serverLink fornita dalla rete e si aggancerà in modo del
tutto dinamico, espandendo il virtual world.
Nota: Durante questa fase, il server è in stato di linking, ma in teoria nulla vieta che un client richieda in questo
momento una migrazione. Nel caso, il server si troverà costretto a negare il protocollo, dato che non è ancora
“inglobato” nel Virtual World.
Si userà invece l’altro metodo proprio per una migrazione, poiché l’evento in questione interesserà solamente i 2 servers
coinvolti nel protocollo di Ownership Switch di un avatar (vedere capitolo migrazioni).
I Server già collegati, hanno inoltre un meccanismo interno, con il quale durante il processo di BackEnd, si “accorgono”
– a seconda di una tolleranza settata - di avere un alto workload nel FrontEnd (alto numero di connessioni) ed inviano
una query pubblica nella rete per tentare di attivare nuovi servers – magari in stato IDLE, inutilizzati fino ad ora – che
verranno in questo modo “risvegliati” - questo perché ogni server appena attivato, è in stato di attesa (WAIT) per
connessioni client o messaggi provenienti da altri servers.
Varie simulazioni dimostrano infatti che grazie alla struttura toroidale del Virtual World, i clients tendono a distribuirsi
tra i servers attivi.
Nel nostra realtà simulata, nell’architettura distribuita da noi concepita, i server non sono sincronizzati tra loro.
Secondo il nostro tipo di partitioning del VirtualWorld infatti, vengono create partizioni totalmente indipendenti che
lavorano in parallelo, non essendoci aree di overlap (condivise), non è necessario spedire messaggi atti a
sincronizzazione ed “aspettare” altri Servers. Nel nostro caso quindi, tutti i Servers lavorano al massimo delle loro
potenzialità. Lo scopo della nostra architettura infatti è proprio quello di permettere inserimenti dinamici di nuovi
Server senza ostacolare o rallentare gli altri già presenti nel mondo virtuale e ridurre al minimo indispensabile le
comunicazioni inter-server.
Questo sistema permette una modularità del Virtual World praticamente illimitata.
MIGRAZIONI
4.1 - Migrazioni : Ownership Switch
L’architettura client-server che sta alla base del mondo virtuale che siamo andati a simulare implica un problema di non
trascurabile importanza: la scarsa scalabilità di questa architettura con un server centralizzato. Per quanto potente possa
essere la macchina su cui risiede, esiste sempre un limite finito al numero delle connessioni che essa è in grado di
gestire, rendendo complesso l’allargamento del sistema a reti su scala mondiale quali Internet. Esistono vari modi per
aggirare questo problema.
Quella che abbiamo scelto di utilizzare nel nostro progetto prevede che i server siano molteplici e si dividano tra loro i
client in modo tale che quelli che devono interagire più frequentemente tra di loro si servano del medesimo.
Il virtual world è stato quindi suddiviso in partizioni indipendenti ognuna delle quali gestita da un server.
Si riducono così al minimo le comunicazioni tra un server e l’altro. Un esempio è il caso in cui i client mediante dei
movimenti nella mappa accedano in una zona (partizione) gestita da un altro server in quella che si definisce
MIGRAZIONE o Avatar Ownership Switch. Le conseguenze di tale evento sono molteplici e coinvolgono
naturalmente la rete di comunicazione fra i server.
Questa è stata chiamata ISC - Net, che sta per Inter Server Communications.
A differerenza delle comunicazioni tra client e server questa volta lo scambio di messaggi e quindi di informazioni
avviene in modalità peer-to-peer.
In questo schema tutte le macchine condividono la connessione di rete
‘alla pari’ (da cui il nome dello schema). Questo significa che non è prevista una macchina
che funga da nodo centrale per la memorizzazione dei dati che devono essere condivisi, ma le informazioni sullo stato
condiviso sono ‘distribuite’ con modalità varie su tutti i server presenti in rete. La ragione per cui si adotta uno schema
di questo genere è che garantisce scalabilità illimitata al sistema, non richiedendo di doversi appoggiare a nodi centrali.
Inoltre, in questo modo il sistema è più resistente ai guasti di rete, poiché la caduta di un server non pregiudica il
funzionamento dell’intero sistema.
ISC – Inter Server Communications Net
È il mezzo ideato nel nostro simulatore tramite il quale i servers comunicano tra loro. Virtualmente servirebbe per ogni
tipo di comunicazione tra servers. Nel nostro caso è utilizzato per lo scambio di messaggi fra servers nel caso di
migrazioni e ad ogni attivazione di un nuovo server quando tutti quelli presenti nel virtual world si scambiano messaggi
per localizzare la loro posizione e “linkarsi” fra loro (stabilire per ognuno, quale sia il server di destra, quello di sinistra,
sopra e sotto).
Per come è implementata la rete è comunque possibile utilizzarla per l’invio di qualsiasi altro messaggio.
L’ISC, infatti, non ha una sua struttura indipendente, a livello di codice, ma è implementato all’interno di ogni server
con una coda in uscita ed una in entrata.
Questo implica che ogni server conosca gli IDs (indirizzi) dei servers che sono direttamente adiacenti e quindi
comunicanti con esso. Per permettere ciò indipendentemente dal numero di servers e dalla loro distribuzione sull’ intera
mappa generale è stato utilizzato l’algoritmo raffigurato nella seguente figura che viene invocato, come già detto, ad
ogni attivazione di un nuovo server:
4.2- PROTOCOLLO DI MIGRAZIONE AVATAR
L’immagine mostra l’intero protocollo di trasferimento Avatar nei 2 casi:
- Giunge un’interazione di movimento da parte di un client uscente dalla partizione.
- Il server di origine genera il messaggio di Location Request (LocReq) e lo invia al server adiacente (a seconda
del lato).
- Il server di destinazione valuta la richiesta con i dovuti ritardi (il BackEnd potrebbe essere impegnato nel
processo locale o altre attività). Nel caso in cui la posizione richiesta sia disponibile, il server pone
un’immagine virtuale invalicabile dell’avatar nella mapcell in questione e gli garantisce uno slot libero sul
FrontEnd. Una volta fatto ciò, invia il messaggio di OK (LocReqOK) al server origine e spedisce il messaggio
di ITM_SWITCH al client tramite l’indirizzo di rete contenuto nel messaggio.
- In caso di successo, il server origine, tramite migration table, che ha memorizzato il vecchio ID locale
(FrontEnd ID), elimina l’avatar, slot sul FrontEnd e le dovute sottoscrizioni.
4.3 - PROCEDURA DI UNA MIGRAZIONE IN DETTAGLIO
Nel caso in cui un avatar tenti di accedere ad una posizione che è al di fuori della partizione gestita dal server a cui è
attualmente connesso…
…questo se ne accorge tramite un semplice controllo sulla x e sulla y della destinazione del movimento. Quindi manda
una richiesta di locazione LOCATION REQUEST al server che gestisce la partizione adiacente specificando le
coordinate di ingresso e aggiorna la Migration-Table aggiungendo l’ID del client e negando a quest’ultimo qualsiasi
tipo di movimento durante la migrazione
A questo punto il secondo server verifica che la migrazione sia effettivamente attuabile e si comporta di conseguenza:
1_CASO: la posizione (x,y) è già occupata da un oggetto statico o da un avatar -> in questo caso viene inviata
esclusivamente una Request Location Denial al primo Server, il quale toglie l’ID del client dalla Migration-Table
permettendogli di continuare a “giocare” senza naturalmente dare la conferma del suo spostamento.
2_CASO: posizione (x,y) è libera o occupata da un semi static-object (gemma, oro)-> in questo caso il secondo server
invia una request location ok al primo server per avvertirlo dell’avvenuta migrazione e avviando così il processo di
disconnessione (relativa al precedente server).
Il secondo server inoltre invia un messaggio (ITM-SWITCH) per informare il client stesso della necessità di cambiare
server. Questo quindi si sottoscriverà alla nuova area e scaricherà gli oggetti di questa zona per cominciare a
visualizzare sulla propria mappa “la nuova realtà”.
4.4 - Migration-Table
La migration table ha un’importanza rilevante nelle nostre migrazioni. Un array collocato su ciascun server che tiene
memoria dei client che sono in migrazione (migranti) da una specifica partizione. Così i client che tentino di muoversi
quando il loro ID è contenuto nella migration table non potranno farlo. Inoltre è necessaria al server di origine per
mantenere in memoria il vecchio FID (id locale) che userà per cancellare la vecchia posizione in caso di migrazione
successful.
Tutto questo avverrà nel caso in cui la LOCATION REQUEST sia ancora in viaggio fra il “vecchio” e il “nuovo”
server, e non è ancora certo l’esito della migrazione.
EnGen
VIRTUAL WORLD ENVIRONMENT GENERATOR
Poiché la complessità dell’ Environment ha un forte peso sulle statistiche, dalla quantità di messaggi necessari alla
renderizzazione client-side alle migrazioni e molto altro, il Simulatore MMG ne fornisce un generatore di nostra
creazione (File ENGEN.txt) che permette una completa e illimitata parametrizzazione dell’ambiente.
Ogni Server quando entra nel Virtual World, dopo aver allocato la sotto-struttura dei Tile SubMap Control, prima di
attivarsi e rendersi disponibile a connessioni, genera la mappa vera e propria.
Il cosa genera e il come, vengono appunto definiti in EnGen.
Si può pensare a questo file come un database simulato al quale accedono i servers : ogni oggetto in EnGen ha un
codice di generazione e un SID (Server ID) ovvero il Server che ne farà uso.
Più nel particolare, il file è una lista di Object Generation Code aventi questa struttura :
<SID> <object> <clumps><iterations_per_clump> <Horizontal per.><Vertical per.>
<object> : E’ l’oggetto da creare (signed byte – definiti in MMGwod).
<clumps> : Il numero di gruppi creati per il suddetto oggetto.
<iterations_per_clump> : A partire dal punto in cui è stato creato il gruppo, per quante volte viene iterato l’oggetto
(replicato).
<Horizontal Percentage> :
La percentuale con cui l’iterazione viene effettuata sull’asse X.
<Vertical Percentage> :
La percentuale con cui l’iterazione viene effettuata sull’asse Y.
<SID> : E’ il Server che userà quel codice di generazione. Se il SID = 0, la generazione dell’oggetto viene condivisa
(shared) tra tutti i Servers.
Quindi quando un server genererà la mappa, accederà in EnGen a tutti gli object generation codes con il proprio ID più
tutti quelli condivisi.
Ricordiamo in ogni caso che la creazione degli oggetti rispetta un ordine sequenziale.
NOTA : Una troppo elevata complessità può portare nel caso limite in crash il Server quando riceverà il messaggio di
LOGIN da parte del client, non riuscendo a trovare una posizione libera sulla mappa sulla quale posizionare l’avatar.
Esempio Iterazioni :
BLUEWALLS con Vertical Per. = 0 e Horizontal Per. = 70.
WALLS con Vertical Per. = 70 e Horizontal Per. = 0.
Esempio con iterazione per clump = 0 e = 10 rispettivamente.
Ovviamente, il Server a seconda della grandezza della partizione, scalerà i clumps e le iterazioni secondo la seguente
formula:
S = (SX*SY) / (STDSX*STDSY)
S = S – [(S-1)*p]
SX,SY : Size della partizione.
STDSX,STDSY : Size standard della partizione.
P : Percentuale di “forza” della scala.
SIMULATORE
6.1 - EVENT LIST PRINCIPALE
L’Event List del simulatore (EVL) ovviamente si occupa del susseguirsi degli eventi generali e simularne la
concorrenza.
A livello implementativo, abbiamo preferito usare una lista dinamica ordinata piuttosto che il classico array (ogni indice
rappresenta un evento diverso), perché sarebbe dovuto essere a 2 dimensioni (causa ID dell’entità che genera l’evento),
quindi ricerca del minimo (prossimo) evento = Complessità n2.
Con la lista dinamica l’inserimento ( newsimevent() ) di un evento è di complessità lineare e la selezione del prossimo
evento è immediata (primo della lista).
Come già detto, è possibile inizializzare la lista con eventi di inizializzazione, con qualunque tempo di occorrenza.
AVANZAMENTO DEL TEMPO (TimeAdvMode)
Sono stati implementati Event Driven e Time Step (quest’ultimo dà la possibilità durante l’esecuzione di aumentare o
rallentare il tempo fino a fermarlo – Step = 0.0 ). Naturalmente si può stabilire una finestra di tempo di osservazione
simtmwindow per il TimeStep e un numero limite di eventi prefissato per EventDriven, nulla vieta di scambiare i
rispettivi limiti.
6.2 - STRUTTURA DI UNA SIMULAZIONE MMG-Sim
A livello di codice, una simulazione centralizzata con i moduli MMG avrà la seguente semplice forma:
#include "mmgsim.c"
/* inizializza vari parametri */
initeventlist();
TimeAdvMode = EVENTDRIVEN; // o TIMESTEP
/*­­ Inizializza la lista con degli eventi ­­*/
while (simulation­not­over){
lastsimtime = simtime; /* keep last simtime */
Timing(); /* Advance simtime */
EventsHandler(); /* Execute event(s) */
/*­­ Aggiorna statistiche ­­­­­­­­­­­­*/
/*­­ Redraw a video dello stato ­­­­­­*/
sleep(1);
}
endall(); // Funzione di terminazione e Report
La struttura flessibile della Event List a livello implementativo, permette in un futuro di distribuire la simulazione su più
processi e quindi fornendo più Event List.
Statistiche di Output e Generatore Numeri Casuali
7.1 - Generatore Numeri Casuali
Attraverso il modulo MMGRND.C, vengono fornite al simulatore varie primitive per la generazione di numeri casuali.
La funzione principale _rndx() è stata ripresa dal codice della random() presente nella libreria stdlib.h, modificata con
l’aggiunta del parametro seme.
I numeri generati da _rndx() sono distribuiti uniformemente nell’intervallo degli interi (32 Bits).
E’ stato implementato inoltre un generatore congruente - rnd32x() - con coefficiente moltiplicativo _A_ (75) e modulo
2147483647. Tra i due si è scelto quest’ultimo pur essendo di complessità maggiore, poiché la _rndx() dopo alcune
generazioni si stabilizzava.
Sulla base del generatore casuale su interi, vengono fornite routines per il calcolo di :
- Interi casuali discretizzati sull’intervallo 0…n.
- Reali casuali nell’ intervallo 0…n, secondo una definita precisione (fit).
- Interi definiti in un un intervallo definito da un pivot e un range.
- Reali definiti in un un intervallo definito da un pivot e un range.
- percentuali usate in condizioni (sia intere che reali).
- Condizionamento casuale (TRUE or FALSE – Usato nella A.I.).
Ognuna di queste routines, oltre a dei prefissati parametri, prende in pasto anche il seme.
Nel simulatore sono presenti i seguenti semi diversi :
-
General seed = seme generale usato per randomizzare ritardi, varianze, ecc…
AI seed = seme per l’Intelligenza Artificiale degli Avatars.
EnGen seed = seme usato per la randomizzazione della generazione Environment.
Color seed = seme per il random dei colori avatars.
7.2 - Statistiche di Output
Ogni simulazione, per essere significativa, deve restituire in output dei valori di tipo statistico.
Riguardo al nostro simulatore, oltre ai files di Log, viene generato un unico file di uscita comprendente tutti i dati in
uscita.
I valori ottenuti, appartengono ad una delle seguenti categorie:
- Valori Totali
- Valori correnti di certe variabili generali o locali (shot dello stato).
- Valori medi monitorati ed aggiornati durante l’intero arco di tempo di osservazione dell’architettura
distribuita.
Esempio di Valori Totali: TOT migrazioni, richieste di migrazione, oggetti pubblicati, ecc…
Esempio di Valori Correnti: clients migranti, FrontEnd current usage, ecc…
La precisione ed affidabilità dell’ultimo tipo di valori sono massime nel caso di avanzamento Event-Driven e parziali
nel caso di avanzamento Time-Stepped: in questo caso, la precisione dipende molto dal size dello Step e dal grado di
densità degli eventi.
Immagini : Var è una certa variabile monitorata nei 2 tipi di avanzamento.
Valore medio nel tempo = Area (Integrale della funzione) / SimTime.
Inoltre vengono generati 3 files di Log:
- Log comunicazioni inter-server (ISC.txt)
- Log completo e dettagliato realtà simulata (simlog.txt)
- Log Event List del simulatore (simEV.txt)
7.3 - STRUTTURA DEL REPORT (MMGstats.txt)
MMG SIM STATS REPORT
======================
(#) Input Parameters.
(>) Output Parameters.
TOT = Total
AVG = Average
SIMULATION TIME ( v a l o r i d e l t e m p o s i m u l a t o )
…
EVENT LIST ( v a l o r i d e l l ’ e v e n t l i s t p r i n c i p a l e )
> MAX Event List len : 66 Events
> MAX Event List DT : 5.000000
> TOT Events happened : 167934
GLOBAL COMMUNICATIONS ( s t a t i s t i c h e d i c o m u n i c a z i o n e )
> Overall Messages Lost : 0 = 0.00 Kbytes lost.
> TOT inter­Server Messages Transferred : 841 = 5.75 Kbytes
> TOT Local Update Messages sent by Servers : 1011 = 6.91 Kbytes
> TOT Local Env. Messages sent by Servers : 14560 = 99.53 Kbytes
> TOT Local Interact­Env. Messages sent by Servers : 7770 = 53.12 Kbytes
SERVER MAP STATS ( s t a t i s t i c h e g e n e r a l i d e l l e p a r t i z i o n i )
…
TILES AND MOVEMENTS ( s t a t i s t i c h e g e n e r a l i Ti l e s e i n t e r a z i o n i )
…
LOCAL DDM ( s t a t i s t i c h e D D M l o c a l i d e i s e r v e r s )
…
CLIENT STATS ( s t a t i s t i c h e g e n e r a l i c l i e n t s )
…
WORKLOAD STATS ( s t a t i s t i c h e m e d i e e c o r r e n t i d i W o r k l o a d )
…
> SERVER 1 : …
> SERVER 2 : …
> SERVER 3 : …
> SERVER 4 : …
> Ecc…
…
SERVER MODULES WORKLOAD ( s t a t i s t i c h e m e d i e w o r k l o a d m o d u l i d e i s e r v e r s )
> SERVER 1 :
­­> AVG Data Distribution Module Occupation (Per.): 89.1119
­­> AVG Back End Module Occupation (Per.) : 11.3151
­­> AVG Concurrent Occupation (Per.) : 0.4270
> SERVER 2 : …
> SERVER 3 : …
> SERVER 4 : …
> SERVER 5 : …
ecc…
ENVIRONMENT CHANNELS WORKLOAD ( s t a t i s t i c h e m e d i e w o r k l o a d c a n a l i E n v i r o n m e n t )
> SERVER 1 :
­­> # ENV Channel Size : 100 = 0.68 Kbytes.
­­> # INV Channel Size : 60 = 0.41 Kbytes.
­­> # Process Queue­IN Size : 40 = 0.27 Kbytes.
­­> # Update Queue­OUT Size : 20 = 0.14 Kbytes.
­­> ENV Channel Peak usage : 28 Messages (28.0000 Percent)
­­> INV Channel Peak usage : 9 Messages (15.0000 Percent)
­­> AVG Environment Channel usage : 0.46 Messages (0.4569 Percent)
­­> AVG Interact­Env Channel usage : 0.18 Messages (0.3032 Percent)
> SERVER 2 : …
> SERVER 3 : …
ecc…
AVATAR MIGRATIONS ( s t a t i s t i c h e g e n e r a l i m i g r a z i o n i )
> Clients now Migrating : 0
> TOT Migrations Requests (LocReq) : 271
> TOT Successful Migrations : 255
> TOT Migration Denials : 16
> Successful Migrations Percentage : 94.095941
> Denied Migrations Percentage : 5.904059
DELAYS ( v a l o r i c o r r e n t i r i t a r d i c l i e n t s )
Client 1 current Delay : 0.3500
Client 2 current Delay : 0.5000
Client 3 current Delay : 0.0500
ecc…
GAME STATS ( s t a t i s t i c h e d i g a m e ­ s c o r i n g )
7.4 – Parametri
Di fondamentale importanza per una buona riuscita della simulazione e dell’analisi dell’output, è la parametrizzazione;
anche per questo motivo, si è scelto durante lo sviluppo del simulatore, di dare la possibilità all’utente finale di settare
questa per mezzo di semplici files a riconoscimento di stringhe.
In questo modo si può verificare il comportamento dell’architettura simulata e valutare con quali valori è più
performante. Per una questione di semplicità, il simulatore fornisce già impostati una serie di parametri che possono
essere usati per testare il funzionamento generale.
I file di input parametri sono i seguenti:
- inputAI.txt → Parametro che gestisce “l’intelligenza artificiale”
1) AiavoidSolidObjsPercentage: con quale percentuale (%), l’avatar andrà ad evitare gli oggetti solidi
2) AicollectScoreObjPercentage: con quale percentuale (%), l’avatar cercherà di accumulare punteggio
prediligendo il passaggio su caselle occupate da score_object
-
inputBW.txt → Settaggio della larghezza di banda
-
inputdelays.txt → imposta vari ritardi e varianze in input di client, server e rete ISC.
-
inputGenSim.txt → Tramite questo file è possibile settare diversi parametri generali, alcuni dei quali servono
esclusivamente per la visualizazione grafica (Grandezza della finestra variabile a seconda della risulozione
dello schermo, attiva o disabilita la simulazione grafica o solo di alcune parti (come Environment e
pavimentazione mappe), inizializzazione dei semi.
E’ possibile inoltre la scelta dell’avanzamento del tempo Event-Driven, Time-Stepped (con il relativo step se si
viene scelta questa modalità o il numero di eventi massimo che devono avvenire perché la simulazione abbia
termine.
Possibilità di inserire eventi di inizializzazione o esogeni nell’Event List.
Inoltre è presente il parametro che attiva la presenza dell’utente nella realtà simulata.
-
inputMap.txt → L’utilizzo di questo file ci da la possibilità di settare valori di partizione:
1) Border, attiva o disattiva il bordo della partizione ( ovviamente se viene attivato non si darà agli avatars la
possibilità di effettuare delle migrazione).
2) PartitionX e PartitionY, permettono di stabilire la grandezza della mappa orizzontale e verticale.
3) Tilesize, stabilisce la grandezza del Tile (vedi specifiche nella parte ServerMap)
-
inputQueues.txt → tramite questo file si modificano i sizes delle code di Client,Server,Inter-Server
-
InputServer.txt → Settaggio on/off sull’uso da parte del server dei locks (vedi ServerMap), Carico di
processo previsto per Q-in e ISC Q-in, abilita e disabilita il protocollo ottimistico (DSRP)
-
InputClient.txt → Settaggio dei ranges environment e interaction, abilita e disabilita il merging dei
vecchi movimenti, abilita e disabilita la variazione di ritardo del client durante la migrazione.
FUNZIONAMENTO DEL SIMULATORE
La finestra che viene aperta in esecuzione, visualizzerà a seconda delle schermate, lo svolgersi della simulazione.
Le varie schermate, molto user-friendly, rappresentano la faccia grafica che si contrappone in modo costruttivo alla
faccia dei dati numerici e Log generati in uscita.
Il simulatore in ogni caso ha necessariamente bisogno dei files:
- Input---.txt
- ENGEN.txt
SCHERMATA 1 (tasto F1) – Workload di servers e clients
Rappresentazione di un singolo server.
ScreenShot Schermata 1 (tasto F1).
SCHERMATA 2 (tasto F2) – Visualizzazione partizione corrente
SCHERMATA 3 (tasto F3) – Visualizzazione partizione corrente (in dettaglio)
SCHERMATA 4 (tasto F4) – Visualizzazione Client-side
TASTI GENERALI
SHIFT = attiva/disattiva Environment
TAB = attiva/disattiva Pavimentazione
BACKSPACE = cambia Server
SPACE = cambia Client
HOME/END = cambia il size grafico
RETURN = visualizzazione ON/OFF memoria visiva client corrente in modalità F4.
INSERT = visualizza client buffers.
PAUSE = Pausa simulazione.
MOUSE
Tasto Sinistro = Ruota mappa 3D (asse Y)
Tasto Destro = Ruota mappa 3D (asse X)
Scroll up/down = aumenta, diminuisci step in Time-Stepped
NOTE del Simulatore
Il simulatore può sopportare anche carichi molto pesanti di calcoli, con un alto numero di clients e servers inizializzati,
ma è bene prestare attenzione ai files di Log che raggiungono dimensioni dell’ ordine dei 50 Mbytes ed all’ingente
quantità di memoria dinamica che viene allocata dal simulatore.
Particolare attenzione inoltre va data in questi casi limite allo Step-Size, nella modalità di avanzamento del tempo TimeStep, che se allargato in maniera eccessiva può portare ad overhead di calcolo e mandare in crash il simulatore.
Nel caso in cui la grafica OpenGL dia problemi, disattivarla dal file di ingresso “inputGenSim.txt”
Il simulatore MMG-Sim è stato testato su un 1.8 Ghz con 256 Mb di SDRAM e scheda grafica nVidia GeForce4.
Bruno Fanini
Alessandro Leardi
Michele Serra