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

More documents

Recommendations

Info

12 CAPITOLO 1. STATO DELL’ARTE Figura 1.5: Bucket Synchronization: nella Bucket Synchronization il tempo viene idealmente suddiviso in intervalli, “Bucket Intervals” (rettangoli grigi), di N millisecondi (rettangolo verde), calcolati in base al Peer più lento. Viene inoltre definito un TimeSpan, “Delay” (rettangolo rosso), calcolato in base alla latenza più alta presente all’interno della Membership. Ogni Peer assegna ad ogni singolo intervallo un “Bucket”, cioè un Buffer destinato a mantenere gli eventi in attesa di essere effettivamente eseguiti. Nell’intervallo I1, il Peer A genera un evento e lo invia di conseguenza agli altri Peer appartenenti alla Membership (Peer B). Localmente, però, tale evento non viene eseguito come conseguenza diretta della sua generazione: Verrà invece eseguito in I3, poiché quest’ultimo rappresenta il primo intervallo di tempo successivo all’istante individuato dalla somma temporale tra il momento di generazione ed il periodo di “Delay”. Il Peer B, riceve l’evento in I2 ma, utilizzando il medesimo calcolo, sa che dovrà eseguirlo in I3. In entrambi i Peer, quindi, l’evento in questione verrà memorizzato nel Bucket relativo all’intervallo I3, e quindi eseguito a tempo debito.
1.3. SINCRONIZZAZIONE TEMPORALE 13 Figura 1.6: Time-Warp Synchronization: ogni evento è temporizzato tramite un TimeStamp e viene eseguito direttamente al momento della sua ricezione. Dal punto di vista del Peer B, la situazione mostrata in figura si configura nel modo seguente: Il Peer A genera un evento in TS 0, mentre il Peer C genera un evento in TS 2. In TS 4 l’evento di A giunge a B, e viene immediatamente eseguito, mentre l’evento di C tarda ad arrivare. In TS 7 il Peer A invia un secondo evento che giunge a B in TS 8. Solo in TS 12 il Peer B riceve l’evento inviato da C in T 2. Il Peer B, però ha già eseguito il secondo evento proveniente da A (TS 7), quindi è costretto ad eseguire un Roll-back, poiché l’evento inviato dal Peer C deve essere eseguito prima, in quanto generato ad un TimeStamp precedente. Elimina quindi gli effetti causati dal secondo messaggio di A mediante un “Anti-Message”, notificato di conseguenza agli altri Peer. L’UnDo può essere implementato ad esempio memorizzando lo stato incrementale in una “State queue”.
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 20 and 21: 10 CAPITOLO 1. STATO DELL’ARTE Un
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 72 and 73:
62 CAPITOLO 2. ARCHITETTURA SOFTWAR
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

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?