Architettura e protocolli di distribuzione dello stato in videogiochi Multiplayer distribuiti
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Relazione esame Reti di Calcolatori LS AA 2004-2005
Michele Pace matr. 193279
Architettura e protocolli di distribuzione dello stato in
videogiochi Multiplayer distribuiti
Breve introduzione:
I videogiochi online hanno subito nell’ ultimo decennio un’ accelerazione grandiosa, portando l’
esperienza di gioco da single-player in cui un giocatore interagisce con un ambiente simulato locale
e con entità governate dal computer mediante algoritmi di IA, ad esperienze di gioco in cui decine,
centinaia e a volte anche migliaia di giocatori interagiscono in una simulazione complessa.
Il principale ostacolo nell’ interazione real-time è l’impossibilità intrinseca di Internet di fornire
garanzie sulla bassa latenza della trasmissione di informazioni. La combinazione delle necessità di
bassa latenza e assoluta consistenza necessaria nei giochi online è difficile da ottenere perché i
messaggi possono essere ritardati indefinitamente dalla rete o possono essere persi.
In questo progetto ci si vuole concentrare sulla struttura e sui requisiti di un sistema di
comunicazione game-oriented con forti requisiti di consistenza, in cui tutti i partecipanti possano
condividere una visione comune di un mondo complesso.
L’ applicazione sviluppata consiste nel progetto di uno strato di rete basato su API e oggetti COM
facenti parte della piattaforma DirectPlay, a sua volta componente di Microsoft® DirectX®.
Una volta ottenuto uno strato in grado di fornire servizi di scambi di messaggi,servizi base di QoS e
controllo, si vuole implementare un protocollo di comunicazione in grado di dare agli utenti la
sensazione quanto più possibile realistica di immersione in un ambiente 3D simulato.
Stato dell’ arte
Segue una brevissima descrizione di alcuni dei più recenti giochi online e loro caratteristiche per descrivere i risultati
ottenuti da alcune compagnie di videogame nel tentativo di sviluppare Massive Multiplayer Online Games :
CounterStrike.
Uno dei primi MMOG di grande successo, disegnato originariamente dai giocatori stessi è arrivato a contare
anche fino a 35000 server in grado di far giocare centinaia di migliaia di giocatori.
World of Warcraft.
E’ il più recente MMORPG, rilasciato il 23 Novembre. 200.000 sottoscrizioni sono state effettuate solo il primo giorno di gioco. Everquest 2 Uno dei primi giochi online, arriva a sopportare anche migliaia di connessioni su un unico server. Vista Generale I videogiochi commerciali sono costruiti prinipalmente con architetture C\S, o, meno frequentemente con architetture Peer-to-Peer. Le architetture C\S permettono alle compagnie di videogiochi di avere un forte controllo sullo stato del gioco e sono relativamente semplici da implementare, mentre architetture Peer-to-Peer permettono di ottenere minori latenze e di eliminare i colli di bottiglia sui server. Lo sfruttamento della banda e il carico della CPU sono generalmente portati verso il loro limite superiore sul lato server, e sono determinanti anche sul lato client. Nel caso del carico CPU questo è vero anche nei giochi non online. MMOG: Analisi. L’ obiettivo principale in un MMOG (Massive Multiplayer Online Game) è il compromesso tra la qualità delle interazioni necessarie al gioco e la natura della rete che le deve supportare, ovvero Internet. La gestione dello stato del gioco, come detto, deve essere distribuita tra i client per consentire una buona qualità della sensazione di immersione nella simulazione, mentre la forza opposta che agisce sul problema, ovvero l’ architettura della rete, fa si che sia praticamente impossibile ottenere una consistenza assoluta quando il numero di client aumenta fortemente. Nondimeno la costruzione di un contesto di gioco mondiale risulta immediatamente infattibile considerando che anche se i segnali viaggiassero direttamente dalla
sorgente alla destinazione alla velocità della luce e senza overhead, una comunicazione tra, ad esempio,
Parigi e Melbourne sarebbe comunque più lenta della capacità di reazione umana. Diventa quindi
indispensabile l’ architettura della rete di gioco e il suo partizionamento in sottoaree.
Fig 1: Una possibile architettura che prevede lo smistamento
Delle connessioni su nodi di gioco e la possibilità di avere gestioni accessorie
Come il monitoraggio o la gestione dei pagamenti.
Tipologia di gioco Analisi dei ritardi
50 ms Non si nota
Simulazione corsa auto 100 ms Si nota ma accettabile
oltre Non accettabile
Da 0 a 500 ms Accettabile
Gioco di strategia Oltre Non accettabile
Sparatutto in prima persona Oltre 150 Non accettabile
Tab. 1: confronto tra i tempi accettabili in varie tipologie di giochi
come base per impostare politiche di QoS.
Architettura delle reti
Vediamo di esaminare i tradeoffs delle architetture che in questi anni sono state utilizzate per videogiochi
online: Client-Server, Peer-to-Peer e Mirrored Server.
I gradi di variazione nelle architetture possibili sono quelle di:
• Richiesta di banda
• Grado di controllo centralizzato sullo stato del gioco
• Grado di consistenza richiesto.
La scelta dell’ architettura dipende dalle caratteristiche del gioco: in videogiochi che richiedono basse o
bassissime latenze e il mantenimento di un altissimo grado di consistenza si assiste allo sbilanciamento verso
un architettura C\S, viceversa in videogiochi di strategia o giochi di ruolo o simulatori di volo è possibile
verificare la presenza di soluzioni basate sul P2P.
Architettura Client Server
L’ architettura client server, come detto è stata molto popolare, in quanto consente un controllo centralizzato
dello stato del gioco da parte di chi mette a disposizione il server di gioco. L’ architettura P2P mostra invece
una latenza inferiore e meno consumo di banda.
Fig.4: Architettura Client\Server
Nell’ architettura Client\Server i clients (giocatori) inviano informazioni sulle loro azioni, il server calcola e
aggiorna lo stato del gioco e invia le informazioni ai clients.
Al crescere della complessità del gioco e del mondo virtuale in cui i giocatori interagiscono l’ architettura
client server “pura” si sposta verso un’ architettura Client\Server Cluster in cui lo stato del gioco è condiviso
tra una serie di cluster interconnessi.
Quest’ ultima scelta nell’ organizzazione del gioco è quella più diffusa attualmente.
Fig 2. Delega a server diversi di parti del “mondo di gioco” per
ottenere bilanciamento di carico.
Fig 3. Distribuzione dei giocatori in un ipotetico momento di gioco.
Una architettura di questo tipo comporta:
+ Facilità nella gestione della consistenza e della sincronizzazione
+ Possibilità di controllo centralizzato del cheating.
+ Minima comunicazione tra i client
- Possibili colli di bottiglia nel server
- E’ necessario pianificare e progettare il gioco in funzione della gestione C\S
- Singolo punto di fallimento: se il server va giù nessuno gioca più.
Architettura Peer to Peer
Nell’ architettura peer-to-peer viceversa non c’è un repository centrale dello stato del gioco ma ogni client lo
calcola e lo aggiorna attraverso i messaggi che riceve dagli altri client.
Un vantaggio immediatamente riscontrabile in questa architettura è la diminuzione della latenza dei
messaggi: i messaggi non sono inviati ad un server lontano per poi essere mandati ad un altro client, ma
raggiungono l’ altro client immediatamente.
A fronte di questo vantaggio si riscontra immediatamente che il problema si è spostato sul fronte della
gestione dello stato del gioco: siccome ogni peer mantine la propria copia dello stato del gioco, messaggi
persi o messaggi che devono essere ancora recapitati comportano inevitabilmente inconsistenze.
Il consumo di banda delle due architetture è equivalente: nelle architetture peer-to-peer ogni host nel caso
peggiore deve notificare tutti gli altri N partecipanti, ricevendo poi N messaggi dagli altri partecipanti.
Questo provoca sulla rete la presenza di N^2 messaggi. Il server nel caso C\S deve notificare tutti i
partecipanti dopo l’ arrivo di un messaggio che modifica lo stato del gioco. Quindi, teoreticamente anche in
questo caso la presenza dei messaggi sulla rete sarebbe N^2, dovendo notificare il cambio di stato del gioco
ad ogni partecipante a seguito di ognuno degli N messaggi ricevuti.
Tuttavia le cose non stanno del tutto così: tipicamente durante il gioco un partecipante è interessato al
comportamento di solo una parte degli altri partecipanti e quindi solo ad una parte dello stato complessivo
del gioco. In un architettura C\S questo si traduce nell’ invio da parte del server della notifica del
cambiamento di stato ad un client solo se il client è effettivamente interessato alla notifica, così come nel
caso P2P in cui un host contatta solo i pari che sono rilevanti per la visione che ha dello stato del gioco.
Il consumo di banda in entrambi questi ultimi casi è pari ad N*c.
Fig.5: Architettura Peer-to-Peer
Architettura Mirrored-Server
Come molto spesso avviene, quando esistono due soluzioni diverse ad uno stesso problema, ognuna con
pregi e difetti, si cerca una soluzione “di mezzo”, avente caratteristiche delle due soluzioni e cercando di
mitigare i difetti di entrambe.
Nel caso in analisi la soluzione di questo tipo è detta architettura Mirrored-Server, nella quale i server di
gioco sono distribuiti in Internet e i clients sono collegati al server topologicamente loro più vicino.
Come nel modello C\S questa architettura può essere posta sotto un controllo amministrativo forte, e come
nella soluzione a peer-to-peer i messaggi non devono pagare il costo di passare attraverso un unico server
centrale per poi essere instradati ad altri clients.
L’ utente entra nel gioco accedendo al server a lui più vicino (ingress mirror) e per tutto il tempo del gioco
invierà i messaggi a questo server, che li invierà poi agli altri server per mantenere aggiornate le loro copie di
gioco i quali manderanno gli aggiornamenti dello stato del gioco ai loro clients.
Fig.6 Mirrored Architecture: Il mondo è replicato in ogni server (mirror), I mirror mantengono
sincronizzato lo stato e i giocatori si vedono attraverso i mirror.
Descrizione del progetto.
Fig. 7
Realizzazione di uno strato software basato sulle API di basso livello DirectPlay in grado di fornire servizi di
QoS intesi come qualità della simulazione, in grado di mantenere lo stato distribuito della simulazione, di
offrire garanzie di tolleranza ai guasti e replicazione.
Lo strato deve anche poter offrire meccanismi per l’ implementazione di politiche in grado di preservare i
server coinvolti nella simulazione da congestioni o situazioni di carico eccessivo.
Si vuole anche ottenere un coordinamento forte dello stato dei server attraverso un punto di controllo
centrale in grado di poter guidare il funzionamento del sistema attraverso politiche e in grado di ottenere dati
da monitoring del funzionamento del sistema.
Alcune scelte di progetto derivano da considerazioni precedenti.
DirectPlay
Microsoft DirectPlay è uno strato indipendente dal supporto che si pone al di sopra dei protocolli di
rete. (IPX, TCP/IP ecc). Una volta stabilita una connessione si possono mandare messaggi ai
partecipanti alla sessione con differenti politiche.
Con il termine “indipendente dal supporto” si intende la possibilità di poter gestire e usare sessioni
di gioco sia basandosi su reti TCP/IP, reti IPX come anche connessioni locali punto punto ottenute
ad esempio attraverso la connessione di modem e cavi seriali.
DirectPlay costituisce inoltre uno strato progettato per poter utilizzare protocolli diversi una volta
che questi raggiungano la diffusione o l’ importanza tale da rendere vantaggioso il loro inserimento
nel supporto; ad esempio Ipv6, protocolli di multicast o di QoS.
DirectPlay fornisce nella versione utilizzata i seguenti servizi:
• Creazione di sessioni Client/Server e Peer to Peer
• Migrazione dell’ host nei sistemi Peer to Peer.
• Invio di messaggi Garantiti e non-Garantiti
I messaggi garantiti verranno reinviati ai client fino a che non sono ricevuti.
• Invio sequenziale e non sequenziale:
I messaggi sequenziali sono spediti all’ applicazione remota nell’ ordine in cui sono inviati.
• Frammentazione e riassemblamento dei messaggi
• Gestione del tasso di invio dei messaggi per evitare congestione
• Priorità dei Messaggi
• Statistiche di connessione (latenza di round trip latency, perdita di pacchetti ecc)
Microsoft DirectPlay consiste di una collezione di oggetti COM, ognuno dei quali espone una o più
interfacce che rendono possibile il controllo di tutte le parti necessarie.
Progetto
Il supporto di comunicazione dell’ applicazione di divide in due parti: la gestione della
comunicazione tra Client (applicazione che esegue la simulazione 3d) e Server (applicazione che
gestisce una simulazione), e la gestione della comunicazione tra Server e MasterServer
(applicazione che colleziona in un insieme logico i server che stanno funzionanado e offrono
ognuno un ambiente simulato, e che li coordina e li gestisce). Il ruolo e il funzionamento del
MasterServer verrà chiarito in seguito.
Gestione della comunicazione Client-Server
Scelte Progettuali:
Lo scopo del progetto è quello di ottenere una simulazione in cui client remoti possano interagire tra
loro e con un ambiente virtuale.
Fig. 8
Il modello scelto è quello Client-Server con server collaborativi ognuno dei quali si occupa di una
parte del mondo di gioco.
La progettazione del Client di gioco è stata suddivisa a livelli con competenze specifiche e sempre
di più basso livello fino ad arrivare alla base che contiene le chiamate agli oggetti COM DirectPlay
e che si occupa di cercare sessioni, stabilire connessioni ed implementare le politiche di invio dei
messaggi: (relyable, unrelyable).
Salendo, DP8Client maschera le funzioni del supporto in chiamate più generali (recupero delle
informazioni sulle sessioni trovate, aggiunta del client ad una sessione ecc) e GameClient è la classe
a cui il gioco comunica i cambiamenti da notificare al server e da cui riceve lo stato attuale della
simulazione.
Analogamente per quanto riguarda il
server:
Fig. 10
Fig. 9
Protocollo
Si esamina ora il protocollo di comunicazione tra i client e i server e come viene utilizzato per
mantenere aggiornato lo stato della simulazione.
Alla connessione di un client il server invia un pacchetto di configurazione
PACKETTYPE_SERVER_CONFIG col quale comunica al client le impostazioni di connessione che ha
stabilito per lui.
Il server risponde con l’ identificativo della propria versione e se la versione è supportata dal
server, questi invia una risposta affermativa in PACKETTYPE_SERVER_ACKVERSION con cui comunica
che il client è stato accettato. Il gioco può iniziare./////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
// PROTOCOLLO Definizione dei tipi di pacchetti usati nella comunicazione tra il client e il server
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
// HANDSHAKE
// Il server invia questo pacchetto alla ricezione di una richiesta di connessione da parte di un client: primo pacchetto inviato
PACKETTYPE_SERVER_CONFIG,
// Il client risponde con questo pacchetto al PACKETTYPE_SERVER_CONFIG
PACKETTYPE_CLIENT_VERSION,
// Il server risponde al PACKETTYPE_CLIENT_VERSION con questo pacchetto, dopo di che il gioco può iniziare
PACKETTYPE_SERVER_ACKVERSION,
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
Fig. 11 Tipi di pacchetti inviati come handshake tra client e server.
Stabilita la connessione il client entra a far parte della simulazione il suo stato deve essere
comunicato agli altri e le azioni degli gli devono essere notificate.
Non si specifica in dettaglio in questa sede i pacchetti usati per la comunicazione dello stato,
vengono riportati solo i loro identificativi.
// GIOCO
PACKETTYPE_SERVER_WORLDSTATUS,
// pacchetto inviato al server quando un client si muove
PACKETTYPE_CLIENT_MOVE,
PACKETTYPE_CLIENT_ANIMATION,
PACKETTYPE_JOIN_CLIENT,
// Ack del server al client per notificare la ricezione di un pacchetto PACKETTYPE_CLIENT_MOVE
PACKETTYPE_SERVER_ACKMOVE,
// Pacchetto contenente un messaggio per i client (chat) che viene inviato al server
PACKETTYPE_CLIENT_CHATMSG,
// Pacchetto di inoltro di un messaggio arrivato da un client agli altri client
PACKETTYPE_SERVER_MSGDELIVERY,
PACKETTYPE_SERVER_SUBSTITUTE
Meccanismi di controllo del carico a supporto di QoS
Nell’ applicazione considerata la misura più significativa di QoS è la frequenza a cui i client
ricevono le informazioni di un qualche cambiamento dello stato della simulazione.
Questa misura è direttamente legata al carico del server che mantiene lo stato di gioco e al numero
dei client connessi che, unito alla frequenza dell’ invio dei loro cambiamenti, determinano il grado
di carico nel server.
Nel progetto si è voluto fornire dei meccanismi (non politiche) per fare in modo che un server possa
dinamicamente variare dei parametri nei client a lui connessi in modo che in condizioni di caricoeccessivo sia possibile diminuire la frequenza degli aggiornamenti e degli invii di dati da parte dei
clients, ottenendo un aggiornamento più lento dello stato del gioco ma un minore carico sul server.
Alla connessione di un client e ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
potenzialmente in un qualsiasi altro // Struttura che contiene informazioni su come configurare la conversazione
momento durante la connessione il // tra il client e il server. Il server la invia al client
server invia un pacchetto contenente /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
delle direttive che il client dovrà struct ClientNetConfig
osservare per comunicare con il server. {
Il server specifica in particolare l’ DWORD dwThreadWait;
intervallo a cui il client dovrà mandare WORD UpdateMessages_rate;
notifiche sul suo comportamento, WORD wTimeout;
(UpdateMessages_rate), la percentuale
BYTE ubReliableRate;
di messaggi che verranno mandati in
};
modo reliable (0 a default), il timeout
dopo il quale un messaggio che è nella
coda di invio viene scartato.
Con la possibilità di modificare questi parametri il server dispone di un meccanismo per “allentare”
dinamicamente la pressione dei client. Come detto si tratta solo di un meccanismo implementato, al
di sopra del quale dovranno essere decise le politiche con cui utilizzarlo.
L’ utilizzo di ClientNetConfig costituisce un azione sia statica che dinamica (sia preventiva che
adattativa) per ottenere forme di bilanciamento.
MasterServer, modello di replicazione e meccanismo di tolleranza ai
guasti.
Finora sono stati considerati solo i rapporti tra una serie di client che operano in un ambiente
simulato messo a disposizione da un server.
Nella definizione del progetto si vuole avere qualche grado di tolleranza ai guasti e soprattutto si
vuole disporre di un punto di coordinamento di tutti i server che gestiscono una simulazione.
In altre parole, ogni server mantiene lo stato di una parte della mappa che costituisce il mondo di
gioco, questo però non significa che il mondo di gioco sia completamente contenuto in un unico
server. Al contrario più server possono cooperare ognuno mantenendo una sezione sufficientemente
grande del mondo di gioco complessivo.
Tutti i server cooperano sono sotto l’ amministrazione di un autorità centrale che costituisce un
punto di controllo dell’ intera simulazione e che opera monitorando il comportamento dei server
impartendo politiche (ancora una volta sono stati implementati solo meccanismi con cui, in futuro,
implementare politiche).
Questo punto di coordinamento centrale, detto MasterServer mantiene la lista di tutti i server che
partecipano ad una simulazione e gestisce il trasferimento della responsabilità del mantenimento di
una parte della simulazione ad altri server nel caso di caduta di un server.Protocollo di comunicazione tra Server e MasterServer
Si esamina ora il protocollo di comunicazione tra un server e un MasterServer.
Le informazioni costituenti la comunicazione tra server e MasterServer riguardano le statistiche di
funzionamento di un server e l’ informazione su quale server sarà il sostituto in caso di
malfunzionamento.
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
// Definizione dei tipi di pacchetti usati nella comunicazione tra i server e il Masterserver
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
enum
{
// HANDSHAKE Il MasterServer invia questo pacchetto alla ricezione di una richiesta di connessione da parte di un server:
PACKETTYPE_MASTERSERVER_CONFIG,
// Il server risponde con questo pacchetto al PACKETTYPE_MASTERSERVER_CONFIG
PACKETTYPE_SERVER_VERSION,
// Il master server risponde al PACKETTYPE_CLIENT_VERSION con questo pacchetto
PACKETTYPE_MASTERSERVER_ACKVERSION,
/////////////////////////////////////////////////////////////////////////////////////////////////////////PACKETTYPE_SERVER_HEARTBEAT, PACKETTYPE_MASTERSERVER_SUBSTITUTE }; Anche in questo caso non vengono riportati in dettaglio in questa sede i pacchetti usati per la comunicazione ma solo solo i loro identificativi. MasterServer Il MasterServer è l’entità che, se presente, controlla un insieme di Server e ne raccoglie statistiche di funzionamento con minima intrusione. Il suo compito è quello di fornire un punto di controllo centralizzato di un insieme di server che mantengono una simulazione. Il MasterServer non è accessibile ai client per i quali non è in alcun modo possibile sapere se il server che mantiene la simulazione in cui stanno agendo è confederato ad altri server e sotto l’ autorità di un MasterServer oppure agisce in isolamento. Dal MasterServer dipende anche la gestione della politica di Faul Tolerance. Monitoring dello stato dei server. E’ stato detto precedentemente come ogni server dispoga dei meccanismi per far variare ai propri client parametri di comunicazione ed alleggerire il proprio carico quando si avvicina verso una soglia di congestione. Il MasterServer come centro di controllo deve poter avere informazioni fresche sullo stato dei server in modo da poter esercitare politiche “dall’ alto” in grado anche di oscurare decisioni prese individualmente da ogni singolo server. Quando un Server entra sotto l’ autorità di un MasterServer con il pacchtto di HeartBeat vengono inviate anche una serie di statistiche sul funzionamento del singolo server che costituiscono i dati su cui il MasterServer potrà prendere decisioni e decidere politiche. Ancora una volta nel progetto non sono state implementate politiche perché la scelta di quali comportamenti attuare a fronte di determinate situazioni non può essere fatta in modo completo senza delle simulazioni o delle analisi di traffico e di congestione del sistema. Si è quindi preferito costruire i meccanismi e raccogliere i dati, lasciando poi l’ implementazione delle politiche a eventuali sviluppi futuri.
Modello di replicazione e fault tolerance. Cosa succede se un Server si guasta o smette di funzionare? Se il server agisce da solo ovviamente non è possibile prevedere forme di coordinamento e di tolleranza al guasto, con la ovvia conclusione che per i client connessi a quel server la simulazione si interrompe bruscamente. In un ambito confederato, in cui più server sono sotto il controllo di un MasterServer è possibile gestire forme di replicazione in modo che, se un server cade, un altro server viene ad assumere la responsabilità del mantenimento della simulazione anche del server che è caduto. Il modello che è stato introdotto nel progetto permette di perseguire avaiability, ovvero possibilità di ottenere comunque una risposta anche se i livelli di efficienza calano poiché un server deve mantenere due simulazioni contemporaneamente. Si mira quindi a liveness del servizio. Il modello di replicazione è a copie fredde: lo stato non viene mantenuto sincronizzato sulle copie ma quando si verifica un guasto lo stato viene ricostruito sul server eletto ad avere la responsabilità del mantenimento di una simulazione attraverso una fase di inizializzazione che si è verificata comunque molto breve ed accettabile.
Quando un server si pone sotto l’ autorità di un MasterServe gli viene assegnata la responsabilità della gestione della simulazione di un altro server, qualora questo dovesse cadere, e contemporaneamente viene trovato un server che dovrà sostituirlo qualora si verificasse un guasto. Conclusioni e Test Il progetto è stato svolto nel tentativo di applicare considerazioni e metodi analizzati nel corso ai fini di costruire un sistema distribuito sufficientemente funzionale. L’ accento è stato posto su aspetti di QoS e di tolleranza ai guasti, l’ architettura utilizzata è quella client-server perché è stata ritenuta la più adatta al tipo di sistema che si voleva costruire. Il sistema è stato testato su una LAN in una sessione di 5 giocatori e non si sono riscontrati problemi di utilizzo o di ritardi. Il sistema è stato testato su connessione Internet, con due computer ognuno dei quali ospitava due sessioni di gioco. Una linea a 56kb e una linea ADSL. Anche in quasto caso (che si è consapevoli essere molto limitato) non si sono riscontrate latenze fastidiose per la simulazione.
Bibliografia Rick Lambright: Distributing Object State for Networked Games Using Object View. Gamasutra 2002. Paul Bettner e Mark Terrano: 1500 Archer on a 28.8. Network Programming in Age Of Empires Yahn Bernier: Half-Life and Team Fortress Networking: Cloosing the Loop on Scalable Network Gaming Backend Service. Kim Pallister Dean Macrì: Building Scalable 3D Games for PC Appendice In appendice riporto un breve riassunto delle note prese durante lo studio dell’ architettura distribuita del videogioco Quake. Caso di studio: Architettura distribuita di Quake. Quake usa una architettura centralizzata di tipo Client-Server, in cui il server è responsabile del calcolo dello stato del gioco e della distribuzione delle informazioni ai clients. Il client agisce come un mero osservatore e riproduttore dello stato del gioco, raccogliendo gli input dell’ utente e mandandoli al server. In questo modello i problemi di consistenza non esistono, essendo il server l’ unico responsabile del calcolo dello stato del gioco, ma appare evidente come il problema della latenza possa farsi sentire, dovendo il client attendere come minimo un tempo di round-trip prima di vedere le proprie azioni riflesse nel mondo virtuale. Il lavoro del server è, d’altro canto quello di tenere traccia di tutti gli oggetti dinamici: avatars, mostri, missili ecc e decidere se un giocatore è colpito, ucciso, oppure si sta muovendo o agendo secondo specifiche leggi fisiche. Le operazioni di rendering e i calcoli di collision detectioning vengono effettuati sul client, ma se prescindiamo da questi aspetti e ci concentriamo solo sull’ architettura di rete, il client è molto più semplice rispetto al server. Master Server Quake supporta inoltre la presenza di un master server che tiene traccia di tutti I server di gioco presenti su Internet. Compito del master server è quello di mandare periodicamente i cosiddetti “heartbeats” al server di gioco per verificare se è ancora attivo. Messaggi Praticamente tutti i messaggi sono scambiati tra il client e il server in modo unreliable. Ci sono poi alcuni messaggi che sono scambiati in modo affidabile. Messaggi dal Client al Server Durante il gioco il client manda in modo non affidabile i seguenti comandi al server:
• Il personaggio si è mosso
• Il personaggio ha cambiato orientazione
• Sono stati premuti dei pulsanti
• Il tempo intercorso tra questo messaggio e l’ ultimo che è stato mandato
Ogni pacchetto del client inoltre contiene gli ultimi 3 messaggi inviati per sopperire ad eventuali perdite.Puoi anche leggere
