Strumenti Utente

Strumenti Sito


lpr-a:progetto

Differenze

Queste sono le differenze tra la revisione selezionata e la versione attuale della pagina.

Link a questa pagina di confronto

Entrambe le parti precedenti la revisione Revisione precedente
lpr-a:progetto [26/01/2010 alle 18:19 (14 anni fa)]
Vincenzo Gervasi Aggiunte FAQ
lpr-a:progetto [26/01/2010 alle 18:26 (14 anni fa)] (versione attuale)
Vincenzo Gervasi Ancora FAQ
Linea 144: Linea 144:
 \\ \\
 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). 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.
  
lpr-a/progetto.1264529965.txt.gz · Ultima modifica: 26/01/2010 alle 18:19 (14 anni fa) da Vincenzo Gervasi