Differenze

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

--- lpr-b:lpr-b-09:progetto4 [16/12/2010 alle 10:25 (14 anni fa)] – creata Andrea Corradini
+++ lpr-b:lpr-b-09:progetto4 [30/12/2010 alle 22:42 (14 anni fa)] (versione attuale) – [FAQ] Andrea Corradini
@@ 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 e il path di una directory contenente file musicali; ogni gruppo multicast 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 vengono forniti, come parametri di riga di comando, **l'indirizzo IP di un gruppo multicast, la porta da usare per il 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, letta dalla directory indicata, attraverso una serie di messaggi **disponibile**.
@@ Linea 157: / Linea 157: @@
 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).
 ===== Requisiti generali e modalità di consegna =====
@@ Linea 170: / Linea 167: @@
 L'esame orale del corso, che comprende la discussione del progetto, sarà individuale: ciascuno studente
 è responsabile dell'intero progetto consegnato.
+Per motivi organizzativi, gli studenti che intendono sottomettere il progetto sono invitati
+a comunicarlo al docente (<[email protected]>).via email entro il **10 gennaio 2011**: questa comunicazione non è obbligatoria ma molto gradita.
 Per poter essere valutato, il codice del client sviluppato nel progetto deve essere in grado di
@@ Linea 175: / Linea 175: @@
 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.
+di 3-5 pagine che descrive l'organizzazione del codice e da un manuale d'uso che descrive come
+lanciare il programma.
-Codice, relazione e manuale d'uso devono essere inviati per posta elettronica al docente del
+Codice, relazione e manuale d'uso devono essere inviati per posta elettronica al Prof. Corradini (<[email protected]>) **entro le ore 24 di Lunedì 31 gennaio 2011**. Progetti inviati dopo tale scadenza non
-corso **entro data da decidere**. Progetti inviati dopo tale scadenza non
+verranno ammessi, e lo studente dovrà mutuare il corso di LPR dal modulo di Laboratorio del
-verranno ammessi, e lo studente dovrà svolgere un nuovo progetto che verrà pubblicato successivamente.
+corso di RCL, che verrà erogato nel secondo semestre dell'A.A. 2010/11.
-I progetti sottomessi verranno testati durante un evento pubblico; i dettagli verranno forniti in seguito.
+Le modalità di valutazione dei progetti sottomessi e le istruzioni per gli orali verranno pubblicate
+nei primi giorni di febbraio 2010.
 ===== FAQ =====
+  * [23 dicembre 2010] Su segnalazione di alcuni studenti, che ringraziamo, è stata aggiunta tra i parametri forniti al programma da linea di comando anche la porta multicast, che è necessaria.
+[Q] //Le connessioni TCP per i dati di controllo devono restare sempre aperte o devono essere chiuse e riaperte per inviare il comando PLAY?//
+[A] Il testo non specifica se la connessione deve essere unica, o riaperta di volta in volta per ogni PLAY. Considerando che il numero di clienti sul gruppo multicast sarà limitato, non appare critico "risparmiare" sul numero di connessioni; d'altra parte, il costo di stabilire e abbattere una connessione ad ogni comando non è giustificato da vantaggi in altre aree, quindi tenere la connessione aperta appare la soluzione migliore (idealmente, si potrebbe tentare di ri-aprirla nel caso la connessione venga interrotta in seguito ad errori).
+[Q] //Come fa il server a sapere quando il client ha finito di inviare la lista delle canzoni?//
+[A] Non esiste un messaggio di "termine lista"; il protocollo prevede infatti il caso in cui ulteriori canzoni possono essere aggiunte in un secondo momento. Questo potrebbe essere il caso, per esempio, di un client che usi i meccanismi di notifica del S.O. per accorgersi di quando un nuovo file è stato aggiunto alla directory indicata, e aggiornare così l'elenco mantenuto dal server. Tuttavia, il progetto non richiede di implementare tali meccanismi (così come non prevede un messaggio di rimozione dalla lista nel caso un file venga cancellato dalla directory mentre il juke-box è in esecuzione). Quindi, benché il nostro particolare client invii la lista solo all'inizio, il protocollo è progettato per essere usato anche da clienti più dinamici. Si noti che anche questa seconda caratteristica concorre a mantenere la connessione TCP sempre aperta, come già detto sopra.
+[Q] //Gli indirizzi internet e le word (usate per gli interi per lunghezze, id dei brani, etc.) vanno spedite in big endian o little endian?//
+[A] L'ordine da utilizzare è il big-endian, che è l'ordine naturale usato da Java e da praticamente tutti i protocolli standard di Internet (si veda [[http://en.wikipedia.org/wiki/Endianness#Endianness_in_networking]]).