Università degli studi di Bologna
Facoltà di Ingegneria
Corso di Ingegneria Informatica
PROTOTIPO DI UN
GIOCO DI STRATEGIA
IN RETE
Progetto per il corso di
Reti di Calcolatori LS
Frof. Antonio Corradi
A.A. 2006/2007
Alberto Buccella
0000197022
Specifiche
Butch è un prototipo di gioco in rete realizzato per
sperimentare e approfondire alcuni protocolli studiati
durante il corso.

Specifiche di Progetto:
 Mettere a disposizione del progettista gli strumenti necessari alla
realizzazione di una piattaforma di gioco.
 Fornire gli strumenti necessari all’utente per poter interagire
con il sistema nei limiti delle azioni che gli competono
 Garantire l’integrità dei dati
 Gestire il recovery del sistema con “Ipotesi di guasto singolo”
Bucth
Il gioco prevede che un utente, una volta scelto il proprio
ruolo (Pizzaiolo, Fornitore o Boss), possa:

effettuare il login e il logout

visualizzare lo stato di citta, strade e giocatori

cambiare il nome delle entità relative al priorio giocatore

fare scambi con altri utenti

fare attacchi ad altri utenti

scambiare messaggi con altri giocatori
Comunicazione con i Server
All’atto dell’iscrizione al sistema l’utente riceverà una
lista contenete tutti gli indirizzi dei server presenti e la
salverà nel file “server”

Possibilità di tentare su tutti i server prima di
comunicare un fallimento

Ogni volta che l’utente effettuerà il login il file verrà
aggiornato

Restituzione trasparente dell’indirizzo del server al
quale è meglio collegarsi

Reindirizzamento
S1
5
S2
3
C
4
1
2
S3
Azione Atomica 1/2
INITIAL
INITIAL
No
Log begin_committ
Log abort
Ready to
committ?
Si
WAIT
Log ready
Azione Atomica 2/2
Yes
Any
Log abort
Abort?
READY
No
Abort
Log committ
Type of
message
Commit
COMMIT
ABORT
Log abort
Log committ
Log
End_of_trans
ABORT
COMMIT
Risposta ai Guasti

Heartbeat
Una volta rilevato il guasto il server master:
Avvisare tutti gli altri che si è entrati in una sezione
critica
 Riorganizzare il file “città” e distribuirlo a tutti gli altri
server
 Attendere tutte le risposte e poi comunicare il
ritorno dello stato a regime a tutti

Risposta ai Guasti
Una volta rilevato il guasto i server non master:

Percorrono il vecchio file “città e per ogni strada:
 se il server relativo alla copia passiva è quello caduto
recupera la nuova destinazione e ricrea la copia
 se il server relativo alla copia attiva è quello caduto
attiva la copia che è presente nel proprio server
Avvisare il server master che ha terminato la fase
di riorganizzazione

Attende il messaggio di fine sezione critica e rientra in
stato di regime

Risposta ai Guasti
Risposta ai Guasti
Vantaggi dovuti alla presenza del file “città”:
possibilità di distribuire il carico in maniera equa politiche
di scelta ad hoc a seconda della situazione

possibilità, a patto che venga realizzato un protocollo di
elezione, si non dover sottostare all’“Ipotesi di singolo
guasto”

Riorganizzazione
Riorganizzazione
Organizzazione iniziale:


città

Giocatori

CopiaGiocatori

Strade

CopiaStrade

server
Aggiungere o togliere strade

Aggiungere o togliere server
Considerazioni Finali
Il sistema è stato testato in locale con una simulazione
che ipotizzava la presenza di 5 server

Il sistema si è dimostrato robusto anche a fronte di guasti
singoli

Possibili evoluzioni:
Il sistema è privo di sicurezze
 Non limitarsi alla realizzazione di uno specifico gioco
permettere al progettista di realizzare qualsiasi tipo di
gioco desideri

FINE