Questa pagina descrive il I Progetto di LPR 2009/10 .

Il progetto consiste nella scrittura di un client (giocatore) per un server dato (che gestisce il gioco). Il codice del server è disponibile per essere scaricato; è possibile che vengano rilasciate versioni successive (con modifiche minori, quali fine-tuning di alcuni parametri) in seguito.

Versione iniziale (17 dicembre 2009): Server di gioco, Client di esempio

I file necessitano di Java Virtual Machine installata sulla macchina. Essi possono essere usati sia da GUI (con un doppio click sull'icona) che da riga di comando.

Aprendo il server si aprirà il pannello che rappresenta il campo di gioco, con tutti i parametri impostati al loro valore di default (vedi la prossima sezione). Il server è ora disponibile ad accettare connessioni dai client; chiudendo la finestra, si termina l'applicazione. Il pannello a destra elenca le squadre registrate; per ciascuna squadra viene riportato il nome (troncato ai primi 8 caratteri), il numero di giocatori attivi, e il punteggio corrente (dato dal numero di unità raccolte). Il client può essere lanciato fino a cinque volte; ad ogni esecuzione, verrà registrato un nuovo giocatore sul server (registrazioni successive verranno rifiutate). Per default, le opzioni del client coincidono con quelle del server, e la squadra ha il nome “Test”. Con la chiusura del server, terminano (con un errore) tutti i client collegati fino a quel momento.

Il server può essere lanciato con il comando

java -jar Laprore-Server.jar portaTCP gruppoMC portaMC

in cui:

• portaTCP è la porta su cui il server si pone in ascolto per le connessioni TCP provenienti dai client (per default: 4000)
• gruppoMC è il gruppo multicast su cui il server notificherà l'arrivo di nuovi obiettivi (per default: 226.0.0.0)
• portaMC è la porta multicast su cui il server notificherà l'arrivo di nuovi obiettivi (per default: 4001)

Il client può essere lanciato con il comando

java -jar Laprore-Client.jar squadra host portaTCP

in cui:

• squadra è il nome scelto per la propria squadra (per default: Test)
• host è l'indirizzo della macchina su cui gira il server (per default: localhost)
• portaTCP è la porta, sull'host, su cui il server è in ascolto (per default: 4000)

Tutti i parametri (sia del server che del client) sono opzionali, ma se presenti devono essere indicati in ordine. Per esempio, è possibile indicare sul client il nome della squadra, omettendo host e porta.

Il protocollo di comunicazione è diviso in quattro parti: comunicazioni TCP dal client al server; comunicazioni TCP dal server al client; comunicazioni Multicast UDP dal server ai client; comunicazioni intra-client. Di queste, solo le prime due sono obbligatorie perché il client possa funzionare; le secondo due sono però utili per aumentarne l'efficienza e per implementare strategie di gioco più sofisticate. Ciascuna parte è descritta nel seguito.

Tutti i messaggi scambiati fra client e server seguono un formato uniforme, così composto: un byte di comando, seguito da due byte per la lunghezza dei dati, seguiti dai dati (se presenti). Tutti i valori numerici single-byte sono espressi come interi con segno su 8 bit; tutti i valori numerici multi-byte sono espressi come interi con segno su 16 bit in formato big-endian. Tutti i pacchetti scambiati sono di dimensioni assai minori della MTU tipica su reti TCP/IP (1460 byte); è quindi possibile assumere che non si avrà frammentazione dei pacchetti stessi.

Ciascun cliente deve inviare almeno un messaggio ogni 1000ms (altrimenti viene dichiarato morto di sonno e chiuso), e non più di un messaggio ogni 100ms (altrimenti viene dichiarato spammer e chiuso). È possibile usare il messaggio PING almeno una volta per secondo per segnalare che il cliente è ancora vivo, se non si ritiene più utile qualche altro messaggio.

Tentativi di sabotare il server o il protocollo sono lodevoli, ma considerati illegali ai fini dell'esame. È possibile contattare il docente per verificare la “legalità” di una tecnica non ortodossa che si intende usare. È altresì considerato illegale usare nella propria implementazione classi del server o del client di esempio, estratte dal codice fornito.

Si noti che non esistono messaggi per avvisare della scomparsa di un target.

Il protocollo, i formati, e il tipo di comunicazione (tipicamente: TCP, UDP, Multicast o RMI) fra client sono interamente a discrezione dello studente, che dovrà darne documentazione nella relazione. In ogni caso, i vari clienti devono essere istanze dello stesso eseguibile, eseguite su JVM distinte e potenzialmente su macchine diverse. Non è ammessa la comunicazione fra client che utilizzi tecniche diverse dalla comunicazione via rete.

Se il server riconosce un errore nel comportamento del client, la comunicazione viene interrotta (il giocatore rimane registrato ma viene “espulso” dal gioco). Il server segnala tali errori emettendo una eccezione (con l'indicazione del giocatore che ha causato l'errore e del tipo di errore). In caso di errori da parte di un client la squadra continua il gioco con i giocatori rimanenti. Il gioco non prevede la possibilità di de-registrare un giocatore, né un esplicito “fine partita”; ogni esecuzione del server corrisponde a una partita, che può essere interrotta in qualunque momento interrompendo il server (da tastiera con Ctrl-C o chiudendo la sua finestra).

Ogni studente che vuole sostenere l'esame di LPR deve consegnare il progetto svolto al docente del corso di appartenenza (Prof. Gervasi per il Corso A, Prof. Corradini per il Corso B). Il progetto deve essere sottomesso individualmente, ma può essere svolto da un gruppo di due studenti al massimo: in questo caso nel progetto va indicato esplicitamente il collega con cui si è collaborato. L'esame orale del corso, che comprende la discussione del progetto, sarà individuale: ciascuno studente è responsabile dell'intero progetto consegnato.

Per poter essere valutato, il codice del client sviluppato nel progetto deve essere in grado di interagire senza errori con il server pubblicato in questa pagina, in una o più istanze (fino a 5) eseguite su host diversi o anche sullo stesso host. Il progetto deve funzionare correttamente sulle macchine del CLI, dove verrà testato.

Il codice del progetto deve essere ben commentato e deve essere accompagnato da una relazione di 3-5 pagine che descrive l'organizzazione del codice, le strategie realizzate per il funzionamento del singolo client e per la collaborazione tra più client, e le politiche di sincronizzazione tra thread utilizzate. Inoltre occorre produrre un breve manuale d'uso che descrive i comandi necessari per avviare le varie istanze del client, sia su uno stesso host che su host diversi.

Codice, relazione e manuale d'uso devono essere inviati per posta elettronica al docente del corso entro le ore 24 di domenica 31 gennaio 2010. Progetti inviati dopo tale scadenza non verranno ammessi, e lo studente dovrà svolgere un nuovo progetto che verrà pubblicato successivamente.

I progetti sottomessi verranno testati durante un evento pubblico il 5 Febbraio 2010 alle 14:00, durante il quale ogni studente lancerà cinque istanze del proprio client che competeranno con tutti gli altri (eventualmente, con un meccanismo a gironi) su di un unico server attivato dai docenti.

L'implementazione del cliente di esempio (che sarebbe già sufficiente ai fini dell'esame) consta di poco meno di 70 righe di codice Java; si consiglia agli studenti di iniziare con un'implementazione semplice, e poi eventualmente dedicarsi al miglioramento dell'efficienza e delle strategie. Si noti che ai fini della valutazione verranno considerati primariamente:

• la correttezza dell'uso delle tecniche di multithreading e di comunicazione di rete;
• il design e l'implementazione dell'eventuale protocollo inter-client;
• l'efficienza della soluzione (sia in termini di uso delle risorse che di efficacia della strategia di raccolta);
• la qualità complessiva di scrittura del codice e della relazione.

Nella parte orale verranno invece verificate le conoscenze teoriche su tutti gli argomenti trattati nel corso.

Si raccomanda di verificare in anticipo il funzionamento dei client sulle macchine del Centro di Calcolo (Laboratori H-Lab e M-Lab), su cui verrà svolto il “torneo” finale dopo la data di consegna. Si raccomanda altresì di contattare i docenti, a ricevimento o per email, prima della consegna in caso di dubbi sull'interpretazione del testo.

È nota la frequenza con cui il server genera i targets e quindi invia messaggi di tipo TARGETS in multicast?
No; i target sono comunque generati a intervalli casuali, per cui al limite si potrebbe sapere la frequenza media. Ma quest'ultima è a sua volta determinata dal numero di squadre che stanno giocando in quel momento, quindi… in pratica, sono davvero a caso.

Il client con un messaggio di tipo MOVE, chiede al server di portare il giocatore alle coordinate, è possibile sapere la velocità di movimento del giocatore (sarebbe utile per fare dei calcoli)?
Al momento è circa di 8-10 unità/secondo, ma anche in questo caso non si tratta di una garanzia (anche perché dipende da quando lo scheduler di Java decide di mettere in esecuzione il thread del server che controlla i movimenti, e su questo non abbiamo alcun controllo). In generale, poiché Java come linguaggio, la JVM e i kernel di Linux e Windows non forniscono alcuna garanzia sulle prestazione real-time, a nostra volta non possiamo darne. È però possibile prendere delle misure in corso di esecuzione (aggiornandole magari man mano) e poi usarle per i propri scopi “previsionali”.
Per chi fosse interessato, esiste un progetto per fornire prestazioni real-time con Java, chiamato Sun Java Real-Time System.

Posso sabotare i miei concorrenti inviando falsi messaggi sul gruppo broadcast del server?
Si; allo stesso modo, i docenti provvederanno a sabotare la tua laurea inviando falsi statini in Segreteria con voti sotto il 18.

Come devo gestire il caso in cui altri giocatori inviino messaggi nel gruppo broadcast che uso per far comunicare fra di loro i miei agenti?
Prima della gara procederemo a una fase di “DNS manuale” in cui ad ogni studente verrà assegnato, per scopi privati, un gruppo broadcast separato. I client che usino questo tipo di comunicazione devono accettare su riga di comando l'indirizzo IP da usare a tale scopo. È illegale inviare pacchetti broadcast su qualunque gruppo, tranne quello assegnato. In particolare, non si possono inviare pacchetti broadcast sul gruppo usato dal server (vedi FAQ precedente).

Posso consegnare più eseguibili diversi (uno per ogni giocatore/uno o più per scopi di coordinamento)?
No; la modalità di consegna prevede un solo eseguibile. Nulla vieta che questo eseguibile abbia poi comportamenti diversi a seconda dei casi (l'ID unico assegnato dal server a ogni giocatore può essere usato per discriminare questi comportamenti). Allo stesso modo, non è possibile mandare in esecuzione altri processi, distinti dall'unico eseguibile di cui sopra. L'unica eccezione ammessa è il processo rmiregistry per i progetti che ne necessitino.

Ma come faccio a essere sicuro che i pacchetti che mando arrivino al server coi tempi “giusti”? Io li invio coi tempi giusti, però…
Non puoi. È nella natura della programmazione di rete il fatto che, nella maggior parte dei casi, non è possibile dare garanzie statiche sui tempi di consegna dei pacchetti (e anche laddove la rete lo consentirebbe, le incertezze sullo scheduler dei thread in Java non consentono di sapere quando il pacchetto verrà effettivamente letto dal server). Il problema, di suo, è insolubile e ineliminabile: è però possibile prendere tutta una serie di provvedimenti per alleviarlo, e ci si attende che i tuoi client non siano dichiarati nè spammy, nè morti di sonno.