Tesina Applicazioni Telematiche

1. Tesina Applicazioni Telematiche Quiz Multi-utente web-based Studenti: Pasquale Di Rienzo Bartolomeo Ovilio Roberto Pascale

2. Analisi dei requisiti Obiettivo principale di questo progetto è lo sviluppo di un’applicativo (sia client che server) che realizzi un quiz multiutente. Oltre alla funzione di base si vuole offrire anche la possibilità di scambiare flussi multimediali in tempo reale (audio/video, testo). Non meno importante la possibilità di usufruire lato client dell’applicativo su una qualsiasi piattaforma e senza necessità di dover installare alcun programma.

3. Casi d’uso Lato client: Il client deve poter innanzitutto avere la possibilità di registrare un proprio account di gioco presso il server ed effettuare la procedura di login. Inoltre deve poter scegliere un proprio avatar che lo rappresenterà all’interno del gioco (immagine o video dalla web-cam) e deve poter decidere se condividere la propria voce. Una volta autenticato, l’utente dovrà avere la possibilità di scegliere fra più stanze di gioco, e avere la possibilità di scambiare messaggi testuali. Lato server: L’amministratore del gioco dovrà avere la possibilità di configurare a suo piacimento alcune impostazioni di gioco: stanze, scelta numero di rounds, scelta numero di concorrenti per stanza. Inoltre deve avere la possibilità di gestire le impostazioni relative al database contenente le domande: aggiunta/rimozione domande, scelta tra almeno due diversi DBMS.

4. Casi d’uso: schermata iniziale gioco

5. Casi d’uso: dopo il login

6. Casi d’uso: amministratore

7. Tecnologie utilizzate(1/2) • Adobe Flash • Openfire • Red5 Flash Server Protocolli in gioco • HTTP • XMPP • RTMP

8. Tecnologie utilizzate(2/2) Per quanto riguarda il formato di scambio dei messaggi (sia per la chat, sia per il gioco) è stato scelto il protocollo XMPP, per via della sua facile estendibilità e della sua diffusione grazie alla quale è facile reperire tecnologie a suo supporto. Avendo fissato la scelta del protocollo, si è deciso di utilizzare Openfire per sviluppare l’applicativo lato server, che quindi ha assunto la forma di un plugin. Per la realizzazione della parte client dell’applicativo la scelta è ricaduta sulla tecnologia Flash di Adobe, largamente diffusa e ormai supportata da qualsiasi browser, eliminando la necessità di installazione del programma da parte degli utenti. Adobe ci ha anche fornito i mezzi per lo streaming audio/video mediante il protocollo RTMP, divenuto ormai uno standard de facto. Come server di streaming abbiamo optato per il server Red5, presente sotto forma di plugin per il server Openfire (non è stato quindi necessario installare due server diversi sulla stessa macchina).

9. Messaggi scambiati Come accennato è stato necessario estendere XMPP per introdurre messaggi ad hoc per la logica del gioco. Si è agito su due fronti: da una parte si sono usati i messaggi IQ per l’interazione con il server di gioco, dall’altra si è deciso di estendere anche i messaggi di presenza introducendovi informazioni di stato prettamente relative al gioco. Le estensioni definite sono tre: • Game: per i pacchetti IQ, relativi ai messaggi scambiati durante il gioco (invio domanda da parte del server, relativa risposta da parte del client, e richiesta di partecipare a una partita) • GameInfo: per i pacchetti IQ, contenenti informazioni sul numero di stanze e sul numero di giocatori ivi presenti. • GamePresence: per i pacchetti Presence, usati dai giocatori per scambiarsi informazioni di stato: scelta dell’avatar utilizzato, stato di gioco (ready /notready).

10. Esempio:GamePresence

11. Progettazione server-side GameInfo Handler Game Database XMPP Flash Client Game Handler GameMaster

12. Ruoli dei componenti server-side • GameHandler: • Questo componente si occupa di intercettare i pacchetti XMPP inviati dai client relativi al gioco. Al suo interno conserva riferimenti a oggetti di tipo GameMaster, svolgendo la funzione di “dispatcher”: ogni volta che riceve dei msg dai client, per una determinata stanza di gioco, si occuperà di inoltrarli al GameMaster responsabile. Inoltre inizializza la connessione al Database attraverso il componente GameData. • GameMaster: • Rappresenta il gestore della stanza di gioco. Esso viene eseguito come Thread, in modo che più GameMaster (e quindi più stanze di gioco) possono essere attivi contemporaneamente . Racchiude i metodi di gestione della logica del gioco, effettuando interazioni con il componente GameDatabase al fine di ottenere le domande da presentare ai client. • GameDatabase: • E’ il componente che rappresenta il wrapper del database utilizzato per immagazzinare le domande relative al quiz. Mette a disposizione dunque i metodi di connessione/disconnessione al database, e metodi per effettuare interrogazioni su di esso.

13. GameInfoHandler: • Questo componente si occupa di intercettare i messaggi inviati dai client relativi alle richieste di informazioni sul gioco. Tali richieste rappresentano la volontà dei client di sottoscriversi a ricevere aggiornamenti sullo stato delle stanze di gioco (il numero di partecipanti per stanza). • Init: • Questa classe rappresenta il Plugin del gioco . Presenta il metodo “initializePlugin” che viene invocato all’avvio del server. Essa ha il compito di istanziare tutti gli altri componenti. • Altri componenti • Player: • E’ la struttura dati utilizzata per mantenere le informazioni relative ai giocatori (id, username). • Domanda: • E’ la struttura dati utilizzata per mantenere informazioni relative alle domande del quiz. • Result: • E’ la struttura dati utilizzata per mantenere informazioni relative ai messaggi di risposta alle domande del quiz (numero di risposta, tempo impiegato ecc.)

14. Console Amministratore L’aggiunta/rimozione delle stanze è una caratteristica già presente in Openfire, quindi non c’è stato bisogno di implementarla. L’unico accorgimento è quello di creare un servizio apposito chiamato “game”, in modo da separare le normali stanze di chat da quelle adibite al gioco. Per quanto riguarda la configurazione dei parametri (di gioco e del database) si è utilizzata la tecnologia delle JSP per aggiungere sezioni di setting alla console dell’amministratore. Ogni parametro è rappresentato attraverso le variabili d’ambiente di Openfire chiamate JiveGlobals. Grazie ad esse è possibile modificare alcuni aspetti senza dover ricompilare i sorgenti.

15. Progettazione client side • Il lato client è stato scritto in ActionScript, in particolare si sono rivelate utili le API XIFF per quanto riguarda la comunicazione XMPP con il server di gioco. • Il client stabilisce due connessioni persistenti con il server: • Una connessione XMPP sulla quale vengono scambiati i messaggi di gioco. • Una connessione RTMP sulla quale avviene lo scambio di flussi multimediali. • In alcuni scenari (download swf, registrazione ecc.) viene stabilita anche una connessione HTTP . HTTP XMPP(Xiff) RTMP

16. Scenari di interazione Scenario “Registrazione account” L’utente preme il tasto Registra Quando l'utente edita il campo Username, viene inviata una richiesta Http asincrona al server Openfire. Tale richiesta attiva una servlet che controlla se lo username è già stato registrato in precedenza o meno, restituendo l’esito al client.

17. Scenari di interazione Scenario “Login” Scenario considerato : I server accettano con successo le richieste di connessione

18. Scenari di interazione Scenario “Utente vuole partecipare al gioco” In caso di risposta affermativa l’utente invierà un messaggio di presence alla stanza in cui comunicherà il suo nuovo stato di ready a tutti gli altri partecipanti. Se l’utente decide di non voler più partecipare invia un messaggio di tipo “Cancel” (cliccando sull’apposito tasto).

19. Scenari di interazione Scenario “Utente risponde a una domanda” L’utente preme un tasto risposta Alla fine dei round, il server invierà un ulteriore messaggio contenente il vincitore finale (ovvero il giocatore che ha totalizzato il maggior numero di risposte esatte).