Differenze

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

--- lpr-b:lpr-b-08:esercizi [26/10/2008 alle 18:03 (17 anni fa)] – Andrea Corradini
+++ lpr-b:lpr-b-08:esercizi [03/09/2009 alle 09:10 (16 anni fa)] (versione attuale) – Andrea Corradini
@@ Linea 40: / Linea 40: @@
 Prima della terminazione il thread stampa il valore approssimato di pigreco calcolato fino a quel momento.
-//Soluzione proposta: [[http://www.di.unipi.it/~andrea/Didattica/LPR08/Soluzioni/TaskPi.java|TaskPi.java]]//
@@ Linea 47: / Linea 45: @@
 Modificare il programma dell'esercizio precedente in modo che il valore approssimato di pigreco calcolato dal thread venga stampato dal main.
-//Soluzione proposta: [[http://www.di.unipi.it/~andrea/Didattica/LPR08/Soluzioni/TaskPiStampaMain.java|TaskPiStampaMain.java]]//
 ===== Thread Pooling e Indirizzi IP =====
@@ Linea 58: / Linea 55: @@
   * Per ottimizzare la ricerca, si deve attivare un pool di thread che esegua i task in modo concorrente. Ogni volta che si sottomette al pool di thread un task, si ottiene un oggetto **Future<InetAddress>**, che deve essere aggiunto ad un **ArrayList**.
   * Infine, si scorre l’**ArrayList**, stampando a video gli **InetAddress**.
 === Esercizio 2 ===
@@ Linea 162: / Linea 160: @@
 Per testare il funzionamento del client, può essere utile usare la classe [[http://www.di.unipi.it/~andrea/Didattica/LPR08/Soluzioni/UnreliableDatagramSocket.java|UnreliableDatagramSocket]], che offre le stesse funzionalità di **''DatagramSocket''**, ma perde il pacchetto da inviare con probabilità "**''threshold''**", una quantità compresa tra 0 e 1, modificabile con il metodo **''setThreshold(double)''** e con valore default **''0.1''**.
+===== Il protocollo UDP [2] =====
+** Inviare gli esercizi svolti a [email protected] con Subject "[LPR-B] Esercitazione 6" **
+=== Esercizio 1: Objects to DatagramPackets ===
+Scrivere la classe **Obj2DP** che fornisce due metodi statici:
+    public static Object dp2obj(DatagramPacket dp)
+che restituisce l'oggetto contenuto nel pacchetto passato per argomento, deserializzandolo, e
+    public static DatagramPacket obj2dp(Object obj)
+che restituisce un pacchetto contenente l'oggetto passato per argomento, serializzato, nel payload.
+Semplificare le classi **UDP_SendObject** e **UDP_ReceiveObject** viste a lezione usando i metodi della classe **Obj2DP**, senza più usare le classi **ObjectOutput/InputStream** e **ByteOutput/InputStream**.
+Usare la classe **Obj2DP** per i prossimi esercizi, trasmettendo oggetti serializzati con UDP invece di dati di tipi primitivi.
+=== Esercizio 2: MiniTalk Server e Client con UDP ===
+Si realizzino un Server e un Client UDP che realizzano un semplice Instant Messanger: ogni linea scritta nella shell del Server viene copiata nella shell del Client e viceversa. La trasmissione delle linee inizia dopo una semplice fase di handshaking, descritta di seguito.
+  * Il Server viene lanciato da shell, fornendo il numero di porta su cui ricevere i pacchetti UDP.
+  * Il Client viene lanciato da un'altra shell (eventualmente su un altro computer), fornendo tre dati: host e porta del Server, e numero di porta locale su cui ricevere pacchetti UDP.
+  * Il Client manda una richiesta di connessione al Server, indicando nel messaggio la propria porta. Se non riceve un messaggio di ack entro 3 secondi, riprova a mandare la richiesta altre 5 volte, poi termina. Se invece riceve l'ack, inizia la trasmissione delle linee scritte nella shell locale e la ricezione e stampa delle linee scritte nella shell del Server.
+  * Quando il Server riceve una richiesta di connessione, recupera indirizzo e porta del Client dalla richiesta e manda un messaggio di ack al Client, quindi comincia la trasmissione e ricezione delle stringhe come descritto per il Client.
+  * Il Client decide quando disconnettersi in base a una condizione a vostra scelta (per esempio, allo scadere di un timeout, oppure se la linea da mandare è vuota, oppure se la stringa è “CLOSE”,...). Per disconnettersi, il Client manda una richiesta di disconnessione al Server e aspetta un ack, quindi termina l'esecuzione.
+  * Quando il Server riceve una richiesta di disconnessione interrome la trasmissione delle linee, manda un messaggio di ack, e si rimette in attesa di una richiesta di connessione.
+Il Client e il Server devono scambiarsi unicamente oggetti della classe [[http://www.di.unipi.it/~andrea/Didattica/LPR08/Soluzioni/TalkMsg.java|TalkMsg]], usando i metodi della classe per crearne istanze e per ispezionare i messaggi arrivati.
+=== Esercizio 3: MiniTalk Messanger con UDP ===
+Riusando il più possibile il codice sviluppato per l'esercizio precedente, realizzare un programma Messanger che offre le stesse funzionalità, ma in cui non si distinguono un Server e un Client.
+Due istanze di Messanger devono essere lanciate in due shell diverse, fornendo ad ognuna tre dati: la porta locale, e l'host e la porta dell'altro Messanger. Ideare un opportuno protocollo di handshaking, che permetta di stabilire una connessione (concettuale) tra le due istanze di Messanger.
+I messaggi scambiati devono essere tutti oggetti di una stessa classe. Usare la classe [[http://www.di.unipi.it/~andrea/Didattica/LPR08/Soluzioni/TalkMsg.java|TalkMsg]], oppure estenderla o definirne una analoga se necessario.
+=== Esercizio 4: TFTP con UDP (Trivial File Transfer Protocol) ===
+Questa è la specifica di TFTP da WIKIPEDIA:
+  * L'host A invia un pacchetto RRQ (read request) o WRQ (write request) all'host B, contenente il nome del file e la modalità di trasferimento.
+  * B risponde con un ACK (acknowledgement) packet, che serve anche a dire ad A quale porta sull'host B dovrà usare per i restanti pacchetti.
+  * L'host di origine invia dei pacchetti DATA numerati all'host di destinazione, tutti tranne l'ultimo contenenti un blocco di dati completo. L'host di destinazione risponde con un pacchetto ACK numerato per ogni pacchetto DATA.
+  * Il pacchetto DATA finale deve contenere un blocco di dati non pieno ad indicare che si tratta dell'ultimo. Se la dimensione del file trasferito è un multiplo esatto della dimensione dei blocchi, la sorgente invia un ultimo pacchetto di dati contente 0 byte di dati.
+Realizzare un Server TFTP che implementa il comportamento dell'host B e un Client TFTP che implementa l'host A. In particolare:
+  * Client e Server devono scambiarsi solo oggetti di una classe, TFTPmsg, usati sia per messaggi di servizio (RRQ, WRQ, ACK) che per i pacchetti DATA: definire opportunamente la classe TFTPmsg.
+  *  Per il trasferimento dei file, considerarli come file binari, usando quindi opportuni Output/InputStreams (e non Writer/Reader).
+  * Inviare le porzioni di file in array di byte all'interno di un'istanza di TFTPmsg.
+Per testare il programma:
+  * 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 [email protected] 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 non abbia questo problema.
+=== Esercizio 2: Interazione con server predefiniti ===
+Considerare  un servizio attivo su una porta pubblicata da un Server (per esempio, 23 Telnet, 25 SMTP, 80 HTTP). Definire  un client JAVA che utilizzi tale servizio, dopo aver controllato che sia attivo.
+** Attenzione:** Purtroppo ad un controllo più accurato risulta che tutti questi servizi (e anche altri suggeriti precedentemente) sono disattivati sui computer del Centro di Calcolo. Si consiglia di svolgere l'esercizio usando
+come protocollo HTTP sulla porta 80, e come host un web server (per esempio, ''www.cli.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.
+===== Ancora TCP e Multicast =====
+** Inviare gli esercizi svolti a [email protected] 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.
+===== Esercizi su RMI =====
+** Inviare gli esercizi svolti a [email protected] 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.
+===== Esercizi su RMI Callbacks =====
+=== 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.
+===== Esercizi su Collezioni Sincronizzate e Secure Sockets=====
+=== Esercizio 1: Crawler ===
+Si realizzi un programma **Crawler** che analizza tutti i file presenti
+in una directory specificata e nelle sue sottodirectory, e visualzza tutte le
+righe presenti in tali file che contengono una determinata parola chiave //P//.
+Il programma deve attivare due thread,
+  * un thread produttore che enumera tutti i file e inserisce un riferimento
+ad ogni file individuato in una coda bloccante;
+  * un consumatore che estrae i riferimenti ai file dalla coda e, per ognuno
+di essi, visualizza tutte le righe che contengono la parola chiave //P//.
+I due thread si scambiano i dati mediante una coda bloccante. Scegliere il
+tipo di coda bloccante ritenuto più opportuno.
+=== Esercizio 2: Secure Sockets ===
+Per prima cosa, tramite **keytool** creare le chiavi pubbliche/private con i vostri dati
+(che andranno associate al server nel keystore) ed estrarre il certificato che va importato in
+un truststore (sul client). Usando le chiavi svolgere i seguenti esercizi:
+  - Effettuare una comunicazione sicura su TCP (come nell’esempio del Web Server visto a lezione) modificando uno degli esercizi assegnati nelle lezioni precedenti in maniera da usare socket sicuri invece dei socket TCP;
+  - Modificare l’esercizio sulla votazione RMI proposto per l'Esercitazione del 1/12 in modo che la comunicazione tramite RMI sia sicura.
+In entrambi i casi, dal lato client deve essere presente solo il file con il truststore
+(non il file con le chiavi). Tutte le password usate (per esempio per il trustore/keystore)
+NON devono essere
+inserite nei file sorgenti, ma (per esempio) passate come parametri da riga di comando
+o inserite a runtime.
 ====== ======
 [[start|Torna alla pagina principale di LPR-B-08]]