Architettura e protocolli di distribuzione dello stato in videogiochi Multiplayer distribuiti

Transcript

1 Relazione esame Reti di Calcolatori LS AA Michele Pace matr 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 server in grado di far giocare centinaia di migliaia di giocatori. World of Warcraft.

2 E il più recente MMORPG, rilasciato il 23 Novembre 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

3 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 Architettura delle reti Tab. 1: confronto tra i tempi accettabili in varie tipologie di giochi come base per impostare politiche di QoS. 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.

4 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.

5 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.

6 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.

7 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

8 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).

9 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. 9 Fig. 10 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.

10 ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// // 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 carico

11 eccessivo 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 momento durante la connessione il server invia un pacchetto contenente delle direttive che il client dovrà osservare per comunicare con il server. Il server specifica in particolare l intervallo a cui il client dovrà mandare notifiche sul suo comportamento, (UpdateMessages_rate), la percentuale 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. /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// // Struttura che contiene informazioni su come configurare la conversazione // tra il client e il server. Il server la invia al client ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// struct ClientNetConfig { }; DWORD dwthreadwait; WORD UpdateMessages_rate; WORD wtimeout; BYTE ubreliablerate; 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.

12 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, /////////////////////////////////////////////////////////////////////////////////////////////////////////

13 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.

14 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.

15 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.

16 Bibliografia Rick Lambright: Distributing Object State for Networked Games Using Object View. Gamasutra Paul Bettner e Mark Terrano: 1500 Archer on a 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:

17 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.