Sviluppo di un player di Campo
Minato multigiocatore con supporto
di Chat MultiCast
Reti di Calcolatori LS - Fabio Poli 15 Giugno 2006
Funzionalità:
L’applicazione offre due tipi di servizi,
concettualmente separabili tra loro:
• una chat, all’interno della quale
scambiare messaggi, tra tutti i
partecipanti alla sessione;
• un servizio di gestione di partite a Campo
Minato multigiocatore.
2
Reti di Calcolatori LS - Fabio Poli 15 Giugno 2006
Chat: struttura C/S
Protocollo TCP/IP realizzato attraverso Socket Java con connessione.
Server centralizzato, gestore unico della comunicazione.
All’inizio della sessione ogni client si
collega al server e si registra.
Quando vuole comunicare, il client
invia un messaggio al server.
Il Server provvede alla distribuzione
dei messaggi in modalità Broadcast a
tutti i client registrati.
Server con funzionalità di distributore di messaggi.
I Client non si conoscono a vicenda.
3
Reti di Calcolatori LS - Fabio Poli 15 Giugno 2006
MessengerServer
•Il server, al suo avvio, apre un canale di comunicazione, e rimane in
attesa che i client si iscrivano al servizio.
•Attraverso la classe ChatHandler il server crea un nuovo listener per
ogni client che si iscriva al servizio.
•Ogni volta che un Client invia un messaggio, questo viene spedito a
tutti i Client collegati.
Con questo insieme di connessioni punto-a-punto il server simula una
connessione di tipo broadcast con tutti i client connessi, raggiungendo
lo scopo di inviare a tutti ogni messaggio che arrivi al server.
4
Reti di Calcolatori LS - Fabio Poli 15 Giugno 2006
MessengerServer
Ripristino servizio in caso di caduta del Server.
•Server stateless, funzione esclusiva di distributore di pacchetti.
•In caso di caduta, è necessario ripristinare esclusivamente la
connessione coi client.
•Controllo persistenza demandata ai Client.
Problema: accorgersi tempestivamente della caduta del server; i client
devono essere progettati in modo da rendersi conto della chiusura di
connessione
.
vantaggio protocollo TCP
5
Reti di Calcolatori LS - Fabio Poli 15 Giugno 2006
MessengerServer
Controllo persistenza server comunicazione:
•WDogThread
•SpyThread
WDogThread
SpyThread
Incrementa periodicamente un
contatore interno. Se il contatore
raggiunge un valore prefissato,
disabilita il server e ne crea uno
nuovo.
Periodicamente si registra presso
il server per controllarne l’attività.
In caso di registrazione effettuata
con successo, azzera il contatore
di WDogThread.
6
Reti di Calcolatori LS - Fabio Poli 15 Giugno 2006
MessengerClient
7
Reti di Calcolatori LS - Fabio Poli 15 Giugno 2006
MessengerClient:
All’avvio si connette al Server di comunicazione sull’indirizzo IP
passatogli dall’utente (porta impostata di default).
Il client di chat permette:
• l’invio di messaggi testuali tra i vari user;
• La creazione di una partita di Campo Minato tra giocatori
appartenenti alla stessa chat (cioè collegati allo stesso server).
PROBLEMATICHE:
1. Il server di comunicazione è stateless; chi mantiene le
informazioni riguardanti la partita, al momento della creazione e
durante il suo svolgimento?
2. Ogni client deve avere una copia della partita; e la congruenza tra
i dati?
3. Come avviene lo scambio di dati?
.
8
Reti di Calcolatori LS - Fabio Poli 15 Giugno 2006
MessengerClient:
PROTOCOLLO DI COMUNICAZIONE:
I messaggi per il Campo Minato vengono passati sullo stesso canale di
comunicazione utilizzato per la chat.
Garanzia recapito messaggi intrinseca nel TCP.
PRO: utilizzo di una risorsa preesistente (e scarsamente occupata).
CONTRO: necessità di differenziare i messaggi di chat da quelli “di
sistema”.
.
Creazione e gestione di una grammatica per il mascheramento dei
messaggi “di sistema”.
9
Reti di Calcolatori LS - Fabio Poli 15 Giugno 2006
MessengerClient:
CREAZIONE DELLA PARTITA:
Il client di chat (ClientCF ) che avvia la partita crea un processo che si
occuperà delle problematiche tipiche di gestione e sincronizzazione
dell’avvio della partita ( AscoltatoreCM ):
• interrogazione degli altri client;
• ricezione accettazioni;
• avvio partita e sincronizzazione con gli altri Client.
..
MESSAGGI DI CREAZIONE E SINCRONIZZAZIONE:
AscoltatoreCM : ***#PARTITA
ClientCF : @@@#yourName
AscoltatoreCM : ***#yourName#turno
AscoltatoreCM : ***#CREA#yourName1#yourName2#yourName3
Messaggi inviati in BROADCAST : necessità di mascheramento sui
client non interrogati.
10
Reti di Calcolatori LS - Fabio Poli 15 Giugno 2006
MessengerClient:
SVOLGIMENTO DELLA PARTITA:
All’atto della creazione della partita, vengono creati 2 processi, su ogni
Client:
•CMContainer: “contenitore” della GUI e creatore dei messaggi per la
trasmissione delle mosse svolte dall’utente.
• AscoltatoreCM: capta i messaggi inviati dai CMContainer (anche il
proprio ) e aggiorna lo stato della partita.
CMContainer e AscoltatoreCM sono Client del MessengerServer.
Client aggiornati tutti contemporaneamente per mantenere la
congruenza dei dati.
Ogni volta che CMContainer invia un messaggio, viene stabilita una
nuova connessione  miglior ripristino in caso di crash del server.
11
Reti di Calcolatori LS - Fabio Poli 15 Giugno 2006
MessengerClient:
SINCRONIZZAZIONE DURANTE LA PARTITA:
Un solo giocatore alla volta deve aver la possibilità di poter fare la
propria mossa.
Introduzione e gestione del concetto di turno di gioco.
MESSAGGI DURANTE LA PARTITA:
***#BOMBA#x#y#player
***#NOBOMBA#x#y#turno
***#VITTORIA#x#y#player#vict
***#PAREGGIO
Condizioni di gioco normali
Condizioni di fine partita
scatenate dall’ultima bomba
12
Reti di Calcolatori LS - Fabio Poli 15 Giugno 2006
MessengerClient:
INTERFACCIA GRAFICA:
.
E la classe Bomb?
Contiene le informazioni riguardanti la posizione delle bombe.
Possibili molto scelte implementative, realizzata la più semplice,
estendibile.
13
Reti di Calcolatori LS - Fabio Poli 15 Giugno 2006
Scelte progettuali: difetti…
Gestione Socket con connessione TCP richiede un carico maggiore di
una comunicazione senza connessione.
Il basso numero di processi, e il ridoto numero di messaggi scambiati
hanno fatto propendere per questa soluzione.
Problemi legati alla centralità della comunicazione.
Maggior carico lato Client, per le scelte di gestire e memorizzare le
informazioni su ogni client.
Necessità di politiche di sincronizzazione e di controllo di
congruenza dei dati tra i vari client  carico maggiore sui Client.
14
Reti di Calcolatori LS - Fabio Poli 15 Giugno 2006
Scelte progettuali: … e pregi
La scelta delle socket con connessione TCP offre la garanzia che i
messaggi siano sempre recapitati (se il sistema funziona
correttamente).
Un sistema C/S semplifica la gestione della comunicazione.
Il server di comunicazione, essendo stateless, è più facile da
ripristinare ( necessario solo il ripristino della comunicazione).
Mantenendo lo stato su ogni client è facilitata la gestione di eventuali
blocchi o malfunzionamenti (implementati in questa versione solo
risoluzione problemi di connessione).
15
Reti di Calcolatori LS - Fabio Poli 15 Giugno 2006
Conclusioni:
E’ stato realizzato un sistema C/S che deve essere analizzato da due
ottiche diverse:
•Punto di vista della comunicazione: sistema tipicamente C/S.
•Punto di vista logico a livello applicativo: sistema distribuito che
ricorda una struttura P2P, in cui ogni cliente gestisce a turno
l’applicazione, diventando di fatto il server logico dell’applicazione.
16
Reti di Calcolatori LS - Fabio Poli 15 Giugno 2006