Differenze

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

--- lpr-a:progetto4 [14/12/2010 alle 13:05 (14 anni fa)] – Vincenzo Gervasi
+++ lpr-a:progetto4 [14/12/2010 alle 13:38 (14 anni fa)] (versione attuale) – Vincenzo Gervasi
@@ Linea 11: / Linea 11: @@
 ===== Ciclo di funzionamento =====
-Ogni utente del juke-bok è dotato di un programma, che normalmente funge da client, ma occasionalmente può fungere anche da server. Al programma viene fornito, come parametro di riga di comando, l'indirizzo IP di un gruppo multicast; ogni gruppo avrà un server e un numero qualunque di client.
+Ogni utente del juke-bok è dotato di un programma, che normalmente funge da client, ma occasionalmente può fungere anche da server. Al programma viene fornito, come parametro di riga di comando, l'indirizzo IP di un gruppo multicast e il path di una directory contenente file musicali; ogni gruppo multicast avrà un server e un numero qualunque di client.
 All'avvio, il programma invia sul gruppo una **richiesta di join**. Se non viene ricevuta risposta entro 10 secondi, il programma si auto-nomina server per il gruppo multicast, e prosegue normalmente (dovrà svolgere da ora in poi i compiti di client e server). Se invece riceve una **accettazione** da parte di un server, si predispone a fungere da client per quel server.
-Una volta stabilito il contatto con il server, il client invia la lista della musica che ha a disposizione, attraverso una serie di messaggi **disponibile**.
+Una volta stabilito il contatto con il server, il client invia la lista della musica che ha a disposizione, letta dalla directory indicata, attraverso una serie di messaggi **disponibile**.
 Dopo aver trasmesso la lista al server, il client si pone in attesa di ricevere dal server un comando **play**, che contiene l'indicazione di quale brano (fra quelli disponibili al client) eseguire. L'esecuzione consiste nell'invio dei dati audio sul gruppo multicast, per la riproduzione da parte di tutti i client (incluso quello che li sta inviando), come meglio specificato sotto.
@@ Linea 111: / Linea 111: @@
 ===== Accesso all'audio =====
+La classe principale per l'accesso all'audio in Java è la AudioSystem, che fornisce molti metodi statici. Altre classi utili sono la AudioInputStream (un InputStream specializzato per leggere dati audio), la AudioFormat (che rappresenta un formato audio), la SourceDataLine (che rappresenta una sorgente audio - ovvero, un canale di output dall'applicazione verso l'hardware audio). Allo studente si raccomanda di prendere familiarità con queste classi; qui di seguito è comunque riportato un esempio di utilizzo (che usa un File come sorgente dei dati audio, mentre il progetto dovrà ricevere i dati audio da rete).
 <code java>
+// Crea:
+// un AudioInputStream (in questo caso da un file, ma esiste una variante overloaded che legge i dati audio da un InputStream qualunque),
+// un AudioFormat che rappresenta il formato dei dati audio dell'AudioInputStream
+// una SourceDataLine che rappresenta un canale di output audio pronto a riprodurre dati nell'AudioFormat indicato
 File f = new File("/usr/share/sounds/warning.wav");
 AudioInputStream ais=AudioSystem.getAudioInputStream(f);
 AudioFormat af=ais.getFormat();
 SourceDataLine sdl=AudioSystem.getSourceDataLine(af);
+// Inizializza un buffer di dimensione adeguata a contenere un secondo di audio
 int bufsize=(int) (af.getSampleRate()*af.getFrameSize());
 byte[] buffer = new byte[bufsize];
+// Apre il canale audio e imposta il volume master al massimo
 sdl.open(af);
 if( sdl.isControlSupported( FloatControl.Type.MASTER_GAIN ) ) {
@@ Linea 124: / Linea 136: @@
    volume.setValue( volume.getMaximum() );
 }
+// Avvia la riproduzione dell'audio
 sdl.start();
+// Legge, a blocchi, i dati dall'AudioInputStream e li scrive sul canale audio
 int l=1;
 while (l>=0) {
@@ Linea 131: / Linea 148: @@
    if (l>=0) sdl.write(buffer, 0,l);
 }
+// Aspetta che sia terminata la riproduzione dell'audio, quindi ferma tutto
 sdl.drain();
 sdl.stop();
@@ Linea 136: / Linea 156: @@
 </code>
+Il sottosistema audio di Java è estendibile tramite plug-in per supportare la riproduzione di formati qualunque, ma non sempre sono disponibili i plug-in giusti. Si raccomanda di utilizzare per le prove dei file in formato [[http://it.wikipedia.org/wiki/WAV|WAV]] (o altri formati basati su PCM come .au).
+estra).
-VECCHIO PROGETTO:
-Client e server comunicano tramite un unico canale tramite TCP. Tutte le comunicazioni sono iniziate dal client.
-==== Convenzioni generali ====
-=== Formato ===
-Il protocollo di comunicazione è basato sullo scambio di comandi e risposte di un singolo byte; alcuni comandi considerano il byte suddiviso in campi di bit, a cui sono assegnati specifici significati; in altri casi, i byte vengono interpretati come valori numerici a 8 bit.
-=== Temporizzazione ===
-Ciascun cliente **deve** inviare almeno un messaggio ogni 5 secondi (altrimenti viene dichiarato //morto di sonno// e chiuso). Per prevenire lo spamming, il server **ignora** ogni messaggio che sia ricevuto dopo meno di 50ms dal messaggio precedente dello stesso client. È comunque possibile inviare poi in seguito altri messaggi, sempre rispettando i vincoli temporali di cui sopra. Si noti che se un messaggio ignorato prevedeva una risposta, la risposta non verrà inviata: è quindi opportuno assicurarsi di non inviare messaggi troppo ravvicinati, oppure prendere le dovute cautele per rilevare, con un timeout, il caso in cui una risposta attesa non arrivi in tempo. In condizioni normali, le risposte ai comandi vengono inviate immediatamente dopo la ricezione ed elaborazione del comando da parte del server.
-=== Fairness ===
-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.
-==== Messaggi TCP ====
-I comandi hanno la seguente struttura:
-  * bit 7-6: riservati per future espansioni
-  * bit 5-2: opcode di comando
-  * bit 1-0: codice di direzione
-=== Comandi ===
-^ Comando ^^ Descrizione ^ Risposta ^ Consumo energia ^
-^ Nome ^ Valore ^ ^ ^ ^
-| Comandi con codice di direzione |||||
-^ STEP ^ 1 | Si sposta di un passo verso la //direzione//, se possibile. | - | 1 unità |
-^ LOOK ^ 2 | Guarda verso la //direzione//, fino a incontrare un ostacolo a distanza //d//. | Un byte contenente il tipo di ostacolo, seguito da un byte contenente //d//. | - |
-^ FIRE ^ 3 | Emette un raggio laser lungo la //direzione//, fino a incontrare un ostacolo a distanza //d//. | Un byte con valore NAK se non è stato colpito alcun avversario, o se non si ha energia sufficiente; oppure con valore ACK se è stato colpito un avversario. | //d// unità |
-| Comandi senza codice di direzione |||||
-^ GPS ^ 5 | Restituisce la propria posizione corrente. | Un byte contenente la posizione //x//, un byte contenente la posizione //y//. | - |
-^ BATTERY ^ 6 | Restituisce la carica corrente della batteria. | Un byte contenente la carica corrente; 255=massima, 0=esaurita. | - |
-^ SCORE ^ 7 | Restituisce il punteggio corrente. | Un byte contenente il punteggio corrente. | - |
-^ TELEPORT ^ 8 | Teletrasporta il robot in un punto casuale della mappa. | - | 10 unità |
-^ REGISTER ^ 9 | Registra il client sul server; questo comando deve essere inviato prima di ogni altro comando, e il byte di comando deve essere seguito da una stringa ASCII NUL-terminated contenente il nome del robot, che deve essere unico. Il comando è illegale se inviato successivamente alla prima registrazione. | Un byte ACK se la registrazione è stata accettata, o NAK se è stata rifiutata. | - |
-Per il comando GPS, il sistema di coordinate utilizzato è quello consueto (in Informatica), con (0,0) nell'angolo in alto a sinistra, e coordinate crescenti verso destra e verso il basso.
-=== Altre costanti ===
-^ Costante ^ Valore numerico ^ Descrizione ^
-|Direzioni|||
-^ N ^ 0 | nord (verso l'alto) |
-^ E ^ 1 | est (verso destra) |
-^ S ^ 2 | sud (verso il basso) |
-^ W ^ 3 | ovest (verso sinistra) |
-|Codici di conferma|||
-^ ACK ^ 1 | conferma; vero; esito positivo |
-^ NAK ^ 0 | diniego; falso; esito negativo |
-|Oggetti di mappa|||
-^ ROBOT ^ 82 | un robot |
-^ WALL ^ 88 | un muro interno |
-^ OUTSIDE ^ 0 | fuori mappa (un muro esterno) |
-==== Gestione della batteria ====
-Se il robot non dispone di energia sufficiente a eseguire un comando, l'azione corrispondente non viene eseguita (ma, se prevista, viene inviata una risposta come di consueto). La batteria viene ricaricata dalle celle fotovoltaiche al ritmo di 2 unità ogni secondo. La carica massima della batteria è di 255 unità, e i robot entrano in gioco con la batteria carica al massimo.
-==== Comunicazioni intra-client ====
-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.
-==== Trattamento degli errori e terminazione ====
-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).
-Il timeout di una comunicazione è considerato un errore, così come l'invio di comando invalidi. Lo "spamming" non è invece considerato un errore, ma i comandi in eccesso vengono scartati. Quando un robot viene distrutto, il client relativo viene sconnesso; questo caso non è considerato un errore (ma essere distrutti non fa piacere a nessuno).
-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 =====
 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).
+progetto svolto al docente in forma elettronica.
 Il progetto deve essere sottomesso individualmente, ma può essere
 svolto da un gruppo di due studenti al massimo: in questo caso nel
@@ Linea 225: / Linea 172: @@
 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 (l'esatto numero verrà comunicato dopo l'iscrizione degli studenti alla gara finale) eseguite su host diversi o anche sullo stesso host. Il progetto deve funzionare correttamente sulle
+interagire senza errori con altri client e server (che rispettino il protocollo indicato sopra).
-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
+di 3-5 pagine che descrive l'organizzazione del codice.
-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 lunedì 21 Giugno 2010**. Progetti inviati dopo tale scadenza non
+corso **entro data da decidere**. 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; i dettagli verranno forniti in seguito.
-===== Suggerimenti finali =====
-L'implementazione del cliente di esempio (che sarebbe già sufficiente ai fini dell'esame, tranne che per la mancanza di coordinamento) consta di circa 100 righe di codice Java (di cui circa 60 significative); 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 del protocollo inter-client;
-  * l'efficienza della soluzione (sia in termini di uso delle risorse che di efficacia della strategia complessiva della squadra);
-  * 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.
-Per lanciare più istanze del client in maniera rapida, si può usare un comando di shell di questo tipo:
-''for i in 1 2 3; do java -jar Laprore-Client2.jar Test-$i & done''
-o un suo equivalente su altri sistemi operativi.
 ===== FAQ =====
-**Come è definita una "squadra"?**
-\\
-Non esiste sul server il concetto di squadra; dal punto di vista del server, si tratta di robot singoli. Ai fini dell'esame, una "squadra" è l'insieme delle istanze di un client lanciate dallo stesso studente (sulla stessa macchina o anche, potenzialmente, su macchine diverse). Sta allo studente implementare una qualche strategia di comunicazione per consentire il loro coordinamento (per esempio, per riconoscersi l'un l'altro ed evitare di distruggersi a vicenda).
-**Il server mi restituisce a volte -1 in risposta al comando BATTERY, è un errore del server?**
-\\
-No, il valore restituito è del tutto corretto. Si raccomanda di verificare la propria interpretazione del valore, perché...
-//En este mundo traidor, nada es verdad, ni mentira: todo es según el color del cristal con que se mira//.