Lab. di programmazione di rete - b
 
Progetto
 
Questo è il progetto conclusivo conclusivo del corso.  Potrà essere consegnato entro le date stabilite per ogni appello, fino all'ultimo appello dell'anno accademico. Del progetto potranno essere disponibili versione diverse, nel caso si ritenga opportuno modificare (rendere più chiaro e più preciso) il testo, o nel caso si trovino degli errori. La consegna ad un appello dovrebbe far sempre riferimento all’ultima versione pubblicata precedetemente alla data stabilita per la consegna. La relazione deve riportare il numero di versione del testo considerato.
Il progetto deve essere svolto individualmente. E’ possibile comunque svolgere il progetto in gruppo (2/3 persone) purchè la discussione avvenga singolarmente.
L'esame consistera' nella presentazione del progetto (demo, da effettuare su terminale alfanumerico collegato in remoto con i calcolatori dell'aula H, in Linux), nella discussione delle scelte progettuali ed implementative ed eventualmente nella modifica di alcune parti di codice del progetto stesso.
 
Date per la consegna dei progetti
Le date per la consegna dei progetti per gli appelli estivi sono:
- entro venerdì 14 settembre (sesto appello) con possibilità di proroga alla settimana successiva) Le proroga verrà automaticamente concessa a fronte dell’invio di un messaggio (formattato come nel caso si un messaggio di consegna) entro venerdì 14 contenente l’archivio di quanto prodotto fino a quel punto.
 
Le discussioni si terranno a partire dalla settimana del 24, a seconda del numero delle consegne e del numero di esami di scritti consegnati e orali da fare per il corso di AE1b
 
Calendari per le discussioni
I calendari per le prove verranno pubblicati sulla pagina WEB del corso. Gli studenti avranno la possibilita' di scegliere un orario, fra quelli disponibili, direttamente dalla pagina WEB del corso, appena il calendario degli orari disponibili verra' pubblicato. Normalmente le discussioni avverrano dopo una decina di giorni dalla consegna.
 
Modalità di consegna
La consegna del progetto deve essere effettuata interamente in forma “elettronica”, cioè via email. QUINDI NON E’ NECESSARIO CONSEGNARE LA RELAZIONE SU CARTA PRESSO IL CENTRALINO COME INVECE SPECIFICATO NEL TESTO DEL PROGETTO DIFFUSO A LEZIONE. Il messaggio di consegna deve essere indirizzato a
    marcod chiocciola di.unipi.it
e deve avere:
    Subject: consegna LPRb0607 matricola Nome Cognome
All’email devono essere allegati i sorgenti necessari a far funzionare il progetto e un file con la relazione. Il file dei sorgenti deve essere o JAR o TAR/TGZ e devono contenere i file con tutte le sottodirectory necessarie ai vari package eventualmente impiegati. La relazione deve esplicitamente contenere i comandi necessari per scompattare e compilare i sorgenti, nonchè i comandi necessari per testare/lanciare le varie parti del progetto. Il file della relazione deve essere un PDF (se usate Word per scrivere la relazione, potete usare PDF995 per la conversione in PDF). Il file dei sorgenti e quello della relazione devono avere come nome
    Nome_Cognome_Matricola.tar (o.tgz o .jar)
    Nome_Cognome_Matricola.pdf
 
Testo del progetto
 
  1.     Progetto (Versione 1.0, file PDF)

  2.     Progetto (Versione 1.1, file PDF, file PDF “Errata - Corrige”, 1 pagina con le correzioni)
           Pubblicato il giorno 7 dicembre 2006 - E’ sufficiente scaricare la pagina con le
           correzioni, date per differenza con la versione 1.0.
           Sono state corrette le grammatiche, per includere i ritorni carrello dopo END.
           E’ stato spostato il tipo di messaggio RESET dalle risposte del ServerFarm ai tipi di
           messaggio di controllo che possono essere inviati dal cliente (anche qui con modifica
           della grammatica relativa).
           Sono stati aggiunti un esempio di messaggio di REPORT e un esempio di funzione (Inc)

  3.     Progetto (Versione 1.1.1, file PDF ed errata-corrige)
           Unica modifica rispetto alla 1.1 consiste nell’aggiunta della variabile per il numero di
           porta da utilizzare per il discovery UDP.
 
NOTE - FAQ - ETC
 
In questa sezione, ordinate per data, verranno inserite eventuali note esplicative, chiarimenti, suggerimenti, per la realizzazione del progetto. Consultatela regolarmente, durante lo svolgimento del progetto.
 
 
  1.  4 giugno 2007 Sembra che in Aula H e dintorni i problemi con il multicast siano finiti. Comunque sia, si accettano sia progetti che facciano uso del mutlicast che progetti che usino il broadcast, per il discovery.
      
  2. 2 febbraio 2007 - IMPORTANTE: Problemi con il multicast
    I problemi sperimentati in aula H e negli altri laboratori del centro di calcolo permangono. L’utilizzo di indirizzi di multicast diversi dal 224.0.0.1 continua a dare problemi in particolare nelle trasmissioni ripetute di pacchetti sullo stesso gruppo di multicast. Dunque ai fini del discovery dei RemoteWorker     potete utilizzare il broadcast invece che il multicast che invece non pare soffrire degli stessi problemi.
    Per utilizzare il broadcast, usate socket Datagram (anzichè Mutlicast) e l’indirizzo     131.114.11.255 (invece che quello del gruppo di multicast. In questo modo, i pacchetti inviati raggiungeranno tutte le macchine del centro di calcolo anzichè solo quelle che avevano fatto la joinGroup, nel caso di utilizzo del multicast. Ovviamente, i pacchetti in broadcast vanno indirizzati ad una porta particolare, che potete trattare allo stesso modo in cui trattavate la porta target dei messaggi di multicast.

  3.     23/01/2007 - C’è ancora un errore nella parte di grammatica che descrive un <ReqBody>. La grammatica corretta è la seguente:
            <ReqBody>::= <Task> | <Task> <ReqBody>
       <Task>   ::= FUNCTION <FName> \n DATA <Data> \n

    L’errore consisteva nel ritorno carrello dopo il <Task> singolo nella prima riga ...

  4.     17/01/2007 - Il remoteServer del progetto non deve pubblicare come metodo dell’oggetto remoto un metodo exec con la stessa signature del metodo exec della classe Compute. L’oggetto remoto deve pubblicare metodi atti  a far sì che il ServerFarm sia in grado di eseguire, con quei metodi, il calcolo di un generico task di tipo Compute. In altre parole, il remoteServer deve mettere a disposizione un servizio di interpretazione delle richieste di esecuzione dei vari task e l’oggetto esportato deve essere sempre lo stesso per tutta la durata della computazione, anche se nella computazione intevengono client diversi.

  5.     8/01/2007 - La terminazione del server farm a seguito di una richiesta di SHUTDOWN da parte di un cliente deve provocare la terminazione di tutti i RemoteServer e del ServerFarm stesso, indipendentemente dalle eventuali computazioni in atto sui RemoteServer.

  6.     8/01/2007 - Manca nel testo del progetto l’indicazione della porta da utilizzare per il discovery multicast. Si assuma che esista una variabile statica
        serverfarm.ServerFarm.MULTICASTPORT
    dichiarata come l’analoga serverfarm.ServerFarm.MULTICASTGROUP che contenga il numero della porta da utilizzare per il discovery implementatao mediante multicast UDP.

  7.     8/01/2007 - Quando nel testo si fa riferimento a “terminata da un ritorno carrello \n.” si intende che il carattere di terminazione deve essere semplicemente “\n”. In altre parole, la stringa deve essere una cosa tipo:
        “SERVERFARM SERVICE\nFUNCTION Inc\nDATA 123\nEND\n”
    (come da grammatica). Nel caso dei messaggi inviati dal client verso il server per trasmettere il codice delle funzioni, si trasmetterà il nome della funzione così
        Inc.java\n
    seguito immediatamente dopo dal codice del file Inc.java

  8.     21/12/2006 - Sebbene nel testo si richieda che il protocollo client-server sia di tipo ASCII, questo non vale per la trasmissione delle classi fra cliente e ServerFarm, nel caso si trasmettano file di tipo .class o .jar  In questi casi, dopo la trasmissione iniziale del nome del file, il protocollo prevede la trasmissione in binario dei .class e dei .jar, e la trasmissione in ASCII dei .java.
 
  1.     15/12/2006 - Per testare correttamente il progetto occorre realizzare diversi tipi di client. In particolare, o si realizza un client che esegue una delle operazioni previste (Service, ServiceN, Reset, Stats, Shutdown) a seconda dei parametri passati dalla riga di comando, o si realizzano tanti client quante sono le operazioni supportate. Il singolo cliente,esegue l’operazione richiesta inoltrando il messagio di richiesta e stampando il messaggio di risposta. dopo di che termina. Il protocollo prevede infatti che una connessione clinet/server serva per un’unica (richiesta di) operazione. Un progetto ben fatto deve permettere l’utilizzo di client di altri con il proprio server, e viceversa.

  2.     7/12/2006 - Il nome (o l’indirizzo) dell’host su cui gira il ServerFarm è un parametro della riga di comando del Client.

  3.     5/12/2006 - Il progetto impone un tipo particolare di trasferimento delle classi che implementano le funzioni (normalmente risiedono presso il client) e il ServerFarm, processo front end della applicazione server farm. Tuttavia, queste classi dovranno essere utilizzate, di fatto, dai RemoteServer per il calcolo vero e proprio dei task. Come implementare l’invio delle classi ai RemoteServer è uno dei pochi “punti liberi” del progetto. Sta allo studente progettare il software in maniera opportuna in modo che i RemotrServer abbiano accesso al codice delle funzioni che servono per calcolare i task.

  4.     5/12/2006 - Per far funzionare il progetto, si può anche utilizzare una macchina sola, avendo cura di modificare leggermente la specifica per quanto riguarda i numeri di porta utilizzati, per esempio. In generale, per essere sicuri che il codice funzioni come dovuto, occorre provarlo su almeno 4 macchine: 1 per il client, 1 per il ServerFarm e 2 per 2 RemoteServer distinti. Visto le caratteristiche del progetto, ServerFarm e RemoteServer non devono aver accesso mediante CLASSPATH alle classi delle funzioni messe a disposizione dal Client. Si suggerisce pertanto di implementare il Client in una directory separata dalle altre, ed addirittura in un altro pacchetto. Le classi a comune con il ServerFarm (se mai ve ne fossero) potranno essere opportunamente duplicate per la compilazione del cliente.
Attenzione: visti i problemi legati all’uso del multicast, potete utilizzare il broadcast invece del multicast per implementare il discovery.