| Entrambe le parti precedenti la revisione
Revisione precedente
Prossima revisione
|
Revisione precedente
|
lpr-a:progetto [22/12/2009 alle 15:01 (15 anni fa)]
Vincenzo Gervasi |
lpr-a:progetto [26/01/2010 alle 18:26 (14 anni fa)] (versione attuale)
Vincenzo Gervasi Ancora FAQ |
| 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. | 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). | 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). |
| |
| ===== Requisiti generali e modalità di consegna ===== | ===== Requisiti generali e modalità di consegna ===== |
| |
| verranno ammessi, e lo studente dovrà svolgere un nuovo progetto che verrà pubblicato successivamente. | verranno ammessi, e lo studente dovrà svolgere un nuovo progetto che verrà pubblicato successivamente. |
| |
| I progetti sottomessi verranno testati durante un evento pubblico (la cui data verrà pubblicata nel | 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. |
| mese di gennaio 2010) 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. | |
| ===== Suggerimenti finali ===== | ===== Suggerimenti finali ===== |
| |
| 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".\\ | 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 [[http://java.sun.com/javase/technologies/realtime/index.jsp|Sun Java Real-Time System]]. | Per chi fosse interessato, esiste un progetto per fornire prestazioni real-time con Java, chiamato [[http://java.sun.com/javase/technologies/realtime/index.jsp|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. |
| | |
