Progettazione e Sviluppo di un Multiplayer Online Game su Reti Peer-to-Peer

More documents

Recommendations

Info

10 CAPITOLO 1. STATO DELL’ARTE Un approccio “ottimistico”, implementato ad esempio della Time-Warp Synchronization, prevede invece un’ esecuzione degli eventi immediata: questi infatti saranno processati appena giunti a destinazione. Il vincolo temporale atto a garantire la consistenza, che nell’approccio “conservativo” è realizzato mediante fasi ed intervalli di tempo “bloccanti”, è qui invece rappresentato dal processo di “Roll-back”. Ad ogni evento viene infatti assegnato un Time- Stamp: quando un Peer riceve un evento contrassegnato da un TimeStamp meno recente rispetto a quello attuale, vengono prima cancellati tutti gli effetti scaturiti da eventi già processati riportanti un TimeStamp più recente, poi eseguito l’evento in questione, ed infine ri-processati quest’ultimi. Alcuni eventi possono però essere “correlati” tra loro: l’esistenza -o la non esistenzadi un evento “chiave” all’interno di una “Correlation chain” può alterare o compromettere il significato e la validità degli eventi ad esso correlati: in altre parole, compromettere la consistenza dello stato di gioco (Figura 1.6). Questo tipo di sincronizzazioni permette di avere una maggiore reattività di interazione rispetto a quelle basate sull’approccio “conservativo”, ma, per garantire l’esistenza di una base dati sufficientemente ampia da permettere il recovery degli stati precedenti in fase di rollback, richiede tendenzialmente una quantità di memoria più elevata. Per limitare questo problema, si può intervenire eliminando gli eventi obsoleti, cioè quegli eventi, non correlati, ridondanti e sostituibili quindi da eventi più recenti che, partendo dal medesimo stato iniziale, portano al medesimo stato finale.
1.3. SINCRONIZZAZIONE TEMPORALE 11 Figura 1.4: LockStep Synchronization. In questo sistema di sincronizzazione, l’esecuzione degli eventi è volutamente ritardata. Un Peer non processerà nessun evento fino a quando tutti gli altri Peer appartenenti alla Membership non saranno “pronti” per passare allo step successivo, ovvero fintanto che non riceverà le loro intenzioni, sottoforma di evento. Lo si può associare ad un sistema a turni, nel quale ogni attore è obbligato ad eseguire la propria mossa (eventualmente nulla) prima di passare al turno successivo. Per evitare che un Peer malevolo possa modificare le proprie azioni in conseguenza alla ricezione degli eventi appartenenti agli altri Peer, ogni step viene diviso in due fasi: nella prima ogni Peer annuncia una propria “intenzione”, inviando, ad esempio, l’Hash dell’azione voluta a tutti gli altri Peer appartenenti alla Membership. L’“intenzione” non identifica un’azione, nel senso che dal suo valore non è possibile ricavare tramite inferenza la semantica dell’azione stessa. E’ solo nella seconda fase, infatti, che ogni Peer è tenuto a rivelare la propria azione, inviando, agli altri Peer, il relativo evento. Questo infine sarà eseguito solo se, applicando la funzione inversa a quella utilizzata per ricavare l’“intenzione”, il valore risultate sarà equivalente all’azione stessa. Rispetto alla Bucket Synchronization, questo sistema da un lato argina il problema del Look Ahead Cheat (5.1), ma dall’altro risulta essere più sensibile alle variazioni di latezna (Jitter), poiché ogni step, ed ogni singola fase è individuata da un periodo di tempo variabile.
Page 1: Alma Mater Studiorum Università de
Page 4 and 5: ii
Page 6 and 7: iv INDICE 3.2 Layer NET . . . . . .
Page 8 and 9: vi CAPITOLO 0. INTRODUZIONE portabi
Page 10 and 11: viii CAPITOLO 0. INTRODUZIONE Figur
Page 12 and 13: 2 CAPITOLO 1. STATO DELL’ARTE con
Page 14 and 15: 4 CAPITOLO 1. STATO DELL’ARTE men
Page 16 and 17: 6 CAPITOLO 1. STATO DELL’ARTE Fig
Page 18 and 19: 8 CAPITOLO 1. STATO DELL’ARTE Fig
Page 22 and 23: 12 CAPITOLO 1. STATO DELL’ARTE Fi
Page 24 and 25: 14 CAPITOLO 1. STATO DELL’ARTE 1.
Page 26 and 27: 16 CAPITOLO 1. STATO DELL’ARTE Sm
Page 28 and 29: 18 CAPITOLO 2. ARCHITETTURA SOFTWAR
Page 70 and 71:
60 CAPITOLO 2. ARCHITETTURA SOFTWAR
Page 72 and 73:
Page 74 and 75:
Page 76 and 77:
Page 78 and 79:
68 CAPITOLO 3. IMPLEMENTAZIONE poss
Page 80 and 81:
70 CAPITOLO 3. IMPLEMENTAZIONE Figu
Page 82 and 83:
72 CAPITOLO 3. IMPLEMENTAZIONE •
Page 84 and 85:
74 CAPITOLO 3. IMPLEMENTAZIONE leva
Page 86 and 87:
76 CAPITOLO 3. IMPLEMENTAZIONE guit
Page 88 and 89:
78 CAPITOLO 3. IMPLEMENTAZIONE Infi
Page 90 and 91:
80 CAPITOLO 3. IMPLEMENTAZIONE 3.3.
Page 92 and 93:
82 CAPITOLO 3. IMPLEMENTAZIONE Come
Page 94 and 95:
84 CAPITOLO 3. IMPLEMENTAZIONE •
Page 96 and 97:
Page 98 and 99:
Page 100 and 101:
90 CAPITOLO 3. IMPLEMENTAZIONE zion
Page 102 and 103:
92 CAPITOLO 3. IMPLEMENTAZIONE
Page 104 and 105:
94 CAPITOLO 4. ANALISI DELLE PRESTA
Page 106 and 107:
Page 108 and 109:
Page 110 and 111:
100 CAPITOLO 5. SVILUPPI FUTURI Un
Page 112 and 113:
102 CAPITOLO 5. SVILUPPI FUTURI Tal
Page 114 and 115:
104 CAPITOLO 5. SVILUPPI FUTURI sen
Page 116 and 117:
106 CAPITOLO 5. SVILUPPI FUTURI Fig
Page 118 and 119:
108 CAPITOLO 5. SVILUPPI FUTURI (Fi
Page 120 and 121:
110 CAPITOLO 5. SVILUPPI FUTURI Fig
Page 122 and 123:
112 CAPITOLO 5. SVILUPPI FUTURI ste
Page 124 and 125:
114 CAPITOLO 5. SVILUPPI FUTURI car
Page 126 and 127:
116 CAPITOLO 5. SVILUPPI FUTURI
Page 128 and 129:
118 CAPITOLO 6. CONCLUSIONI focus s
Page 130 and 131:
120 CAPITOLO 6. CONCLUSIONI
Page 132 and 133:
122 BIBLIOGRAFIA [Yong-Tae 2008] YO
Page 134 and 135:
124 BIBLIOGRAFIA
show all

Progettazione e Sviluppo di un Multiplayer Online Game su Reti Peer-to-Peer

Create successful ePaper yourself

Delete template?

Save as template?