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 11:07 (14 anni fa)] – [Requisiti generali e modalità di consegna] 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 169: / Linea 169: @@
 Per motivi organizzativi, gli studenti che intendono sottomettere il progetto sono invitati
-a comunicarlo al docente via email entro il **10 gennaio 2010**: questa comunicazione non è obbligatoria ma molto gradita.
+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 178: / Linea 178: @@
 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 le ore 24 di Lunedì 31 gennaio 2010**. Progetti inviati dopo tale scadenza non
 verranno ammessi, e lo studente dovrà mutuare il corso di LPR dal modulo di Laboratorio del
 corso di RCL, che verrà erogato nel secondo semestre dell'A.A. 2010/11.
@@ Linea 187: / Linea 186: @@
 ===== 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]]).