Architettura e protocolli di distribuzione dello stato in videogiochi Multiplayer distribuiti Michele Pace Esame di Reti di Calcolatori LS Aa 2004-2005.

Presentazione sul tema: "Architettura e protocolli di distribuzione dello stato in videogiochi Multiplayer distribuiti Michele Pace Esame di Reti di Calcolatori LS Aa 2004-2005."— Transcript della presentazione:

1 Architettura e protocolli di distribuzione dello stato in videogiochi Multiplayer distribuiti Michele Pace Esame di Reti di Calcolatori LS Aa 2004-2005

2 MMOG Il principale ostacolo nell interazione real-time è limpossibilità intrinseca di Internet di fornire garanzie sulla bassa latenza della trasmissione di informazioni. Il principale ostacolo nell interazione real-time è limpossibilità intrinseca di Internet di fornire garanzie sulla bassa latenza della trasmissione di informazioni. I messaggi possono essere ritardati indefinitamente dalla rete o possono anche essere persi. I messaggi possono essere ritardati indefinitamente dalla rete o possono anche essere persi.

3 C\S vs P2P vs Mirrored Server I videogiochi commerciali sono costruiti prinipalmente con architetture C\S, o, meno frequentemente con architetture Peer-to-Peer. 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 Le architetture C\S permettono alle compagnie di videogiochi di avere un forte controllo sullo stato del gioco Architetture Peer-to-Peer permettono di ottenere minori latenze e di eliminare i colli di bottiglia sui server. Architetture Peer-to-Peer permettono di ottenere minori latenze e di eliminare i colli di bottiglia sui server. Tipologia di giocoAnalisi dei ritardi Simulazione corsa auto 50 msNon si nota 100 msSi nota ma accettabile oltreNon accettabile Gioco di strategiaDa 0 a 500 msAccettabile OltreNon accettabile Sparatutto in prima persona Oltre 150Non accettabile Qualità della sensazione di immersione nella simulazione - architettura best-effort di Internet

4 Architettura Client Server Forte controllo centralizzato dello stato del gioco. I giocatori inviano informazioni sulle loro azioni, il server calcola e aggiorna lo stato del gioco e invia le informazioni ai clients.

5 Partizionamento del mondo di gioco Organizzazione del gioco più diffusa attualmente. Al crescere della complessità del mondo virtuale l architettura virtuale l architettura client server pura si sposta verso un architettura Client\Server Cluster in cui lo stato del gioco è condiviso tra una serie di computer interconnessi.

6 Architettura Peer to Peer Ogni client calcola lo stato del gioco attraverso i messaggi che riceve dagli altri client. Minor latenza dei messaggi, nessun collo di bottiglia sul server ma problemi nel Mantenimento della consistenza.

7 Architettura Mirrored Server Mirror 1Mirror 2 Connessione ad alta velocità

8 Progetto Realizzazione di uno strato software basato sulle API di basso livello DirectPlay Servizi di QoS (qualità della simulazione)Servizi di QoS (qualità della simulazione) Mantenimento dello stato distribuito della simulazioneMantenimento dello stato distribuito della simulazione Tolleranza ai guasti e replicazione.Tolleranza ai guasti e replicazione. Meccanismi per l implementazione di politicheMeccanismi per l implementazione di politiche Coordinamento dei serverCoordinamento dei server

9 Gestione C\S

10 Il modello scelto è quello Client-Server con server collaborativi, ognuno dei quali si occupa di una parte del mondo di gioco. Il modello scelto è quello Client-Server con server collaborativi, ognuno dei quali si occupa di una parte del mondo di gioco. Allocazione statica delle risorse. (Server) Allocazione statica delle risorse. (Server) Applicazione non elastica (Real time). Adattativa. (Maggiori latenze possono essere tollerate entro certi limiti con interpolazioni più pesanti.) Applicazione non elastica (Real time). Adattativa. (Maggiori latenze possono essere tollerate entro certi limiti con interpolazioni più pesanti.) Alla connessione di un client e potenzialmente in un qualsiasi altro momento durante la connessione un qualsiasi altro momento durante la connessione il server invia un pacchetto contenente delle il server invia un pacchetto contenente delle direttive che il client dovrà osservare per direttive che il client dovrà osservare per comunicare con il server. comunicare con il server. (Meccanismi, non politiche). ClientNetConfig{ DWORD dwThreadWait; WORD UpdateMessages_rate; WORD wTimeout; BYTE ubReliableRate;} L utilizzo di ClientNetConfig costituisce un azione sia statica che dinamica (sia preventiva che adattativa) per ottenere forme di bilanciamento. L utilizzo di ClientNetConfig costituisce un azione sia statica che dinamica (sia preventiva che adattativa) per ottenere forme di bilanciamento.

11 MasterServer MasterServer: Coordinamento dei serverCoordinamento dei server Punto di controllo centralizzatoPunto di controllo centralizzato Recupero di informazioni sulRecupero di informazioni sul carico e il funzionamento dei carico e il funzionamento dei server. server. Fail-Safe tolleratoFail-Safe tollerato (definizione mutuata da (definizione mutuata da ipotesi di guasto di processori), ipotesi di guasto di processori), Bizantine no.

12 Modello di replicazione e meccanismo di tolleranza ai guasti. Proprietà perseguita: Avaiability Proprietà perseguita: Avaiability. Si cerca di fornire sempre il servizio anche a fronte del degrado dei tempi di risposta. Si mira quindi a liveness del servizio Failover. Migrazione del servizio a fronte di un guasto. Crash del MasterServer tollerato entro tempi ragionevoli. Ricerca del rispetto del Principio di minima intrusione. L heartbeat contiene informazioni sul funzionamento di un server, il Masterserver comunica solo se necessario. Modello di replicazione è a copie fredde: lo stato non viene mantenuto sincronizzato sulle copie. Quando si verifica un guasto lo stato viene ricostruito sul nuovo server attraverso una fase di inizializzazione di durata molto breve.

13 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. 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 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. 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 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 non si sono riscontrate latenze fastidiose per la simulazione. 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 non si sono riscontrate latenze fastidiose per la simulazione.