Differenze

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

--- lpr-b:lpr-b-09:esercizi [16/11/2009 alle 23:14 (16 anni fa)] – Andrea Corradini
+++ lpr-b:lpr-b-09:esercizi [08/12/2009 alle 12:45 (16 anni fa)] (versione attuale) – Andrea Corradini
@@ Linea 266: / Linea 266: @@
   * Confrontare il file originale spedito dal mittente con quello ricevuto dal destinatario e scritto nel file system.
   * Usare la classe [[http://www.di.unipi.it/~andrea/Didattica/LPR08/Soluzioni/UnreliableDatagramSocket.java|UnreliableDatagramSocket]] per controllare che i pacchetti persi vengano reinviati correttamente.
+===== Il Protocollo TCP =====
+** Inviare gli esercizi svolti a acorradi@cli.di.unipi.it con Subject "[LPR-B] Esercitazione 7" **
+=== Esercizio 1: Compressione di file ===
+Progettare un'applicazione client/server in cui il server fornisca un servizio di compressione di dati.
+Il client legge chunks di bytes da un file e li spedisce al server che provvede alla loro compressione. Il server restituisce  i bytes in formato compresso al client che provvede a creare un file con lo stesso nome del
+file originario e con estensione **gz**, che contiene i dati ricevuti dal server.
+La comunicazione tra client e server utilizza il protocollo TCP. Per la compressione si può utilizzare la classe JAVA ''GZIPOutputStream''.
+Individuare le condizioni necessarie affinchè  il programma scritto generi una situazione di deadlock e verificare che tale situazione si verifica realmente quando tali condizioni sono verificate.
+**Suggerimento:** Scrivere il server in modo che riceva i byte e li rispedisca nello stesso loop. Scrivere una prima versione del client che prima invia tutto il file al server e solo alla fine riceve il file compresso dal server. Verificare che per file grandi questa soluzione va in deadlock, e scrivere in un commento perché. Scrivere una seconda versione del client che, usando ancora un solo thread,  non abbia questo problema, intercalando l'invio di chunks del file al server con la ricezione di pezzi del file compresso.
+=== Esercizio 2: Compressione di file, estensioni ===
+Si realizzi il client con due thread, uno per la lettura del file originale e l'invio al server, l'altro per la lettura dei dati compressi dal server e la scrittura nel file .gz (si curi,
+ove necessario, la sincronizzazione fra i due e la gestione degli errori)
+Si realizzi il server in modo da poter gestire in maniera efficiente connessioni multiple da parte di più client – si ipotizzi anche che il numero di richieste di servizio possa
+essere elevato
+Quali costrutti per il multithreading sono maggiormente indicati in ciascuno dei due casi di cui sopra?
+**Suggerimento:** Scrivere il server in modo che riceva i byte e li rispedisca nello stesso loop. Scrivere una prima versione del client che prima invia tutto il file al server e solo alla fine riceve il file compresso dal server. Verificare che per file grandi questa soluzione va in deadlock, e scrivere in un commento perché. Scrivere una seconda versione del client che non abbia questo problema.
+=== Esercizio 3: Interazione con server predefiniti ===
+Utilizzando come protocollo HTTP (come visto nel corso di Reti) sulla porta 80, e come host un web server (per esempio, ''www.cli.di.unipi.it'' o ''www.di.unipi.it''),
+scrivere un semplice client HTTP in grado di effettuare una breve sequenza di richieste al server, stampando i risultati. Per testare il protocollo si può usare il comando ''telnet <webServer> 80'', che apre una connessione TCP attraverso la quale si possono scambiare stringhe.
+===== Protocollo TCP e Multicast =====
+** Inviare gli esercizi svolti a acorradi@cli.di.unipi.it con Subject "[LPR-B] Esercitazione 8" **
+=== Esercizio 1: Asta Elettronica ===
+Sviluppare un programma client server per il supporto di un'asta elettronica.
+Ogni client possiede un budget massimo **B** da investire.
+Il client può richiedere al server il valore **V** della migliore offerta
+pervenuta fino ad un certo istante e decidere se abbandonare l'asta,
+oppure rilanciare. Se il valore ricevuto dal server supera **B**,l'utente
+abbandona l'asta, dopo aver avvertito il server. Altrimenti, il client rilancia,
+inviando al server un valore maggiore di **V**.
+Il server invia ai client che lo richiedono il valore della migliore offerta
+ricevuta fino ad un certo momento e riceve dai client le richieste di
+rilancio. Per ogni richiesta di rilancio, il server notifica al client se tale
+offerta può essere accettata (nessuno ha offerto di più nel frattempo),
+oppure è rifiutata.
+Il server deve attivare un thread diverso per ogni client che intende
+partecipare all'asta.
+La comunicazione tra clients e server deve avvenire mediante socket
+TCP. Sviluppare due diverse versioni del programma che utilizzino,
+rispettivamente una codifica testuale dei messaggi spediti tra client e
+server oppure la serializzazione offerta da JAVA in modo da scambiare
+oggetti tramite la connessione TCP
+=== Esercizio 2: TimeServer Multicast ===
+Definire un server **TimeServer**, che invia su un gruppo di multicast
+**dategroup**, ad intervalli regolari, la data e l’ora.  L’attesa tra un invio ed il
+successivo può essere simulata mediante il metodo  **sleep( )**. L’indirizzo IP
+di **dategroup** viene introdotta linea di comando.
+Definire quindi un client **TimeClient** che si unisce a **dategroup** e riceve, per
+dieci volte consecutive, data ed ora, le visualizza, quindi termina.
+=== Esercizio 3: Streaming Audio ===
+La pagina ''http://en.wikipedia.org/wiki/WAV'' contiene alcuni file di esempio di file
+audio nel popolare formato WAV (audio non compresso)
+  * Questi dati possono generalmente essere riprodotti, su macchine UNIX, semplicemente scrivendo il loro contenuto su ''/dev/dsp'' o ''/dev/audio''
+    * Attenzione: su alcune installazioni, il dispositivo ''/dev/dsp'' è permanentemente occupato da un demone per il mixing audio come ''esd'', ''alsa'', ''pulseaudio'' ecc. Può essere necessario uccidere tale demone perché la riproduzione abbia luogo.
+  * Si scriva un server streaming audio che, ricevuta sulla riga di comando l'URL di un file WAV, lo scarichi dal web e trasmetta il contenuto, con adeguata temporizzazione, a un gruppo multicast il cui indirizzo è pure fornito sulla riga di comando
+  * Si scriva poi un client streaming audio che, ricevuto sulla riga di comando l'indirizzo IP di un gruppo, si aggiunga ad esso e riproduca sulla macchina locale l'audio
+Non ci si allarmi se l'audio suona “strano”, stiamo trascurando una quantità di parametri...
+===== Remote Method Invocation =====
+** Inviare gli esercizi svolti a acorradi@cli.di.unipi.it con Subject "[LPR-B] Esercitazione 9" **
+=== Esercizio 1: Gestione elezione ===
+Sviluppare una applicazione RMI per la gestione di un’elezione. Il server esporta un insieme di metodi:
+  * ''public void vota (String nome)'': Accetta come parametro il nome del candidato. Non restituisce alcun valore. Registra il voto di un candidato in una struttura dati opportunamente scelta.
+  * ''public int risultato (String nome)'': Accetta come parametro il nome di un candidato e restituisce i voti accumulati da tale candidato fino a quel momento.
+  * un metodo che consenta di ottenere i nomi di tutti i candidati, con i rispettivi voti, ordinati rispetto ai voti ottenuti.
+Il client invoca un certo numero di volte i metodi del server su opportuni argomenti (eventualmente forniti interattivamente dall'utente), stampando i risultati ottenuti.
+Testare che il sistema funzioni con server e client sullo stesso host e su host diversi. Nel secondo caso, provare due versioni: con il registry sull'host del server (come negli esempi visti), e con il registry sull'host del client.
+=== Esercizio 2: Passaggio di parametri con RMI ===
+Scrivere opportune classi e interfacce per verificare che nel caso di valori di tipo riferimento (oggetti e array), una invocazione di metodo remota passa al metodo chiamante una copia dell'oggetto passato come parametro, diversamente da quanto accade nel caso di una invocazione locale. Mostrare che invece, se il parametro è un oggetto remoto, allora viene passato un riferimento all'oggetto e non una sua copia.
+===== RMI e Callback =====
+=== Esercizio 1: Gestione elezione ===
+Modificare l’Esercizio 1 dell'esercitazione precedente in modo che il server notifichi ogni nuovo voto ricevuto a tutti i clients che hanno votato fino a quel momento. La registrazione dei clients sul server avviene nel momento del voto.
+=== Esercizio 2: Forum ===
+Si vuole implementare un sistema che implementi un servizio per la gestione di forum in rete. Un forum è caratterizzato da un argomento su cui diversi utenti, iscritti al forum, possono scambiarsi opinioni via rete.
+Il sistema deve prevedere un server RMI che fornisca le seguenti funzionalità:
+  -  apertura di un nuovo forum, di cui è specificato l'argomento (esempio: giardinaggio)‏
+  -  registrazione ad un forum, di cui è specificato l'argomento
+  -  inserimento di un nuovo messaggio indirizzato ad un forum identificato dall'argomento (es: è tempo di piantare le viole, indirizzato al forum giardinaggio)‏; il messaggio deve essere inviato agli utenti iscritti al forum
+  - reperimento dell'ultimo messaggio inviato ad un forum di cui è specificato l'argomento.
+Quindi il messaggio può essere richiesto esplicitamente dal client oppure può essere notificato ad un client precedentemente registrato.