Scadenza consegna, entro metà febbraio 2009.

(Versione Non Definitiva, 25 maggio 2008)

Scenario:

Si vuole realizzare un sistema come descritto nella figura 1 qui sotto, con tutti i processi che eseguono su una stesso host: i due applicativi più esterni sono identificati dai nomi AppMobile (AppM) e AppFixed (AppF). Lo AppMobile svolge il classico ruolo di client TCP ed instaura una connessione TCP con il MobileLoadBalancer che era in attesa sulla porta TCP numero 6001. Lo AppFixed svolge anch’esso il ruolo di client TCP ed instaura una connessione TCP con il FixedLoadBalancer che era in attesa sulla porta TCP numero 11001.

Figura 1: I processi componenti il sistema.

Sia lo AppMobile che lo AppFixed generano ad intervalli di 40 msec pacchetti aventi dimensioni di 100 Bytes, e li spediscono attraverso le connessioni instaurate, rispettivamente con il MobileLoadBalancer e con il FixedLoadBalancer. Tali pacchetti di 100 Bytes contengono nei primi 4 Bytes un numero intero, ordinato secondo l’endianess della macchina locale, che identifica univocamente in ordine crescente ciascun pacchetto generato.

Parallelamente, sia lo AppMobile che lo AppFixed si predispongono per ricevere dalle stesse connessioni TCP dei pacchetti di 100 Bytes.

L’obiettivo di MobileLoadBalancer e di FixedLoadBalancer è di ricevere pacchetti di 100 Bytes dalla connessioni TCP, rispettivamente da AppMobile e da AppFixed, e di realizzare un protocollo mediante datagram UDP, per trasferire i pacchetti da AppMobile a AppFixed (e viceversa) spedendo i datagram UDP all’applicazione intermedia denominata Monitor.

Il Monitor, all’inizio, rimane in attesa sulla porta TCP 8000, di una connessione TCP proveniente dal MobileLoadBalancer. Non appena tale connessione viene instaurata dal MobileLoadBalancer, il Monitor invia tramite la connessione TCP un messaggio di informazioni sulla propria configurazione, ovvero un blocco dati che descrive quante e quali porte UDP il Monitor mantiene aperte per ricevere datagram UDP dal MobileLoadBalancer.

In particolare, il blocco dati inviato è composto, come indicato in figura 2, da un byte contenente il carattere ‘C’, seguito da un intero a 4 Bytes che contiene il numero delle porte UDP aperte dal Monitor, seguito da tanti interi (tanti quanti il numero delle porte aperte), ciascuno da due Bytes, ed ogni intero contiene il numero di una porta UDP del Monitor.

Per ciascuna delle porte UDP aperte per scambiare datagram UDP con il MobileLoadBalancer, il Monitor mantiene aperta anche una porta UDP per scambiare datagram UDP con il FixedLoadBalancer. Il monitor può via via chiudere o aprire nuove porte UDP. Ogni volta che avviene una di queste modifiche, il Monitor spedisce un messaggio di Configurazione al MobileLoadBalancer per informarlo. Per la fase di test, il Monitor scatena una ri-configurazione (e la conseguente spedizione di messaggi di riconfigurazione) quando l’utente preme ENTER nella shell in cui il Monitor è in esecuzione.

Figura 2: Formato del messaggio (TCP) di Configurazione delle porte UDP del Monitor.

Il MobileLoadBalancer invia datagram UDP alle porte aperte del Monitor (ad es la porta 800X) e questo decide se scartarli oppure inoltrarli alla porta 10001 del FixedLoadBalancer usando come porta mittente la porta 900X corrispondente alla 800X da cui è stata ricevuta. Il Monitor, dopo avere scartato o inoltrato al FixedLoadBalancer un datagram UDP ricevuto dal MobileLoadBalancer, invia al MobileLoadBalancer mediante la connessione TCP aperta un messaggio di Notifica con l’esito della trasmissione del pacchetto. Il messaggio di notifica è formato da 5 bytes: il primo bytes è un carattere ‘A’ (Acknowledgment) nel caso il datagram sia stato inoltrato, oppure un carattere ‘N’ (Negative acknowledgment) se il datagram è stato scartato. Gli altri seguenti 4 Bytes del messaggio di Notifica servono ad identificare il datagram UDP a cui la Notifica si riferisce, e contengono i primi 4 bytes del datagram UDP stesso. E’ perciò consigliabile che i datagram UDP inviati dal MobileLoadBalancer mettano nei primi 4 bytes un identificatore univoco del datagram stesso. E’ importante notare che il Monitor può anche NON notificare la perdita di un datagram UDP, mentre sicuramente notificherà la corretta trasmissione.

Figura 3: Formato del messaggio (TCP) di Notifica di un datagram UDP.

Anche il FixedLoadBalancer invia datagram UDP alle porte aperte del Monitor sul lato fixed (ad es la porta 900X), e il Monitor può scartare o inoltrare i pacchetti alla porta 7001 del MobileLoadBalancer, usando come porta mittente la porta 800X corrispondente alla 900X da cui è stata ricevuta. Però, per i pacchetti che viaggiano dal FixedLoadBalancer al MobileLoadBalancer, NESSUNA Notifica di corretta trasmissione o di scarto del datagram viene inviata.

Un’altra precisazione importante è che lo AppMobile comincia a trasmettere blocchi dati da 100 Bytes subito dopo avere effettuato la connessione con il MobileLoadBalancer. Al contrario, lo AppFixed comincia a trasmettere blocchi dati da 100 Bytes solo dopo avere ricevuto dal FixedLoadBalancer un primo blocco originato dallo AppMobile.

Infine, il Monitor mantiene aperte al massimo 3 porte UDP sul lato mobile e altre 3 sul lato fixed.

Obiettivo del Progetto:

Poiché i datagram UDP possono essere scartati dal Monitor, le due applicazioni MobileLoadBalancer e FixedLoadBalancer hanno il compito di realizzare un meccanismo di controllo e di eventuale ritrasmissione dei datagram UDP per ottenere che: PIU’ del 90% dei pacchetti TCP creati da AppMobile e AppFixed giungano entro 150 msec all’altro end system (rispettivamente AppFixed e AppMobile). Tale meccanismo deve essere implementato esclusivamente mediante datagram UDP scambiati tra MobileLoadBalancer e FixedLoadBalancer.

Dei cinque applicativi, tre (AppMobile, AppFixed, AppMobile) vengono già forniti, mentre gli altri due (MobileLoadBalancer e FixedLoadBalancer, in colore rosso) debbono essere implementati dagli studenti.

Gli AppMobile e AppFixed generano ogni 40 msec dei blocchi di byte aventi dimensione di 100B, li marcano con un identificatore crescente, inoltre li marcano con un timestamp che indica l’istante in cui sono stati generati e li trasmettono verso il MobileLoadBalancer e il FixedLoadBalancer rispettivamente. Quando AppMobile e AppFixed ricevono da MobileLoadBalancer e FixedLoadBalancer questi blocchi di dati, controllano l’orologio di sistema, sottraggono il valore del timestamp del pacchetto ricevuto e in questo modo calcolano il tempo impiegato per la trasmissione del pacchetto. Inoltre verificano che i pacchetti siano ricevuti rispettando l’ordine con cui sono stati creati. E’ ammissibile che un pacchetto sia perso, NON è ammesso che un pacchetto sia consegnato fuori ordine. In caso un pacchetto sia consegnato fuori ordine, l’applicazione che lo ha ricevuto termina immediaamente.

Lo AppMobile e lo AppFixed producono ciascuno un file di testo, rispettivamente delaymobile.txt e delayfixed.txt, in cui ogni riga contiene l’indice del pacchetto ricevuto e il suo tempo di trasmissione. Questo file serve per controllare, a posteriori, l’interattivita’ del sistema.

Vincoli di progetto:

L’elaborato dovrà essere svolto in linguaggio ANSI C, si dovrà privilegiare la portabilità su sistemi POSIX. Lo scopo del progetto è acquisire conoscenza delle tecniche di progettazione mediante I/O MULTIPLEXING, e per questo motivo è vietato l’utilizzo di tecniche di progettazione basate su I/O asincrono e segnali. In particolare:

1) Non possono essere usate le signal(), sigvec(), sigaction(), e simili.

2) Non possono essere usate named pipe (dette anche FIFO), cioè quelle create con mknod(,,).

3) Non possono essere usati i socket unix named, cioè creati con socket(AF_UNIX, , )

4) Possono essere usate le pipe, cioè quelle create con int pipe(int filedes[2]), ricordando pero’ che le pipe non permettono di essere utilizzate mediante le invocazioni alle system call send e recv, e quindi non possono essere utilizzati i comportamenti definiti dai flags MSG_DONTWAIT, MSG_PEEK, etc.

5) Possono essere usati i socket unix anonimi, cioè quelli creati mediante la system call socketpair(AF_UNIX,SOCK_STREAM,0.

6) Potrebbero essere usati pthread e processi ausiliari, se ritenuti necessari (anche se non sono consigliati), evitando però di utilizzarne troppi contemporaneamente per evitare sovraccarico di memoria o di CPU.

7) Non possono essere sfruttate tecniche di compressione dei dati.

Valutazione del progetto:

La valutazione del progetto realizzato si baserà su diversi criteri, in particolare terrà conto di:

· impostazione del progetto,

· performance in termini di:

o affidabilità (percentuale di pacchetti che giungono a destinazione in tempo)

o interattivita’ realizzata (valutata mediante il file di log dei ritardi delay.txt ),

o uso di CPU,

o occupazione di memoria,

o consumo di bandwidth (calcolata dal Monitor, che conta i byte scambiati),

· chiarezza del codice realizzato,

· numero di componenti del gruppo.

Fase di test - l’emulatore di rete e le applicazioni client e server:

Per aiutare l’analisi prestazionale, il Monitor colleziona informazioni sui dati che lo hanno attraversato. In particolare, killando il Monitor (premere CTRL+C) vengono visualizzati il numero di byte trasmessi attraverso ciascuna connessione. Inoltre, AppMobile e AppFixed producono ciascuno un file di log contenente il tempo di trasmissione di ciascun pacchetto ricevuto.

Demo del progetto:

Quando un gruppo riterra’ di avere concluso il progetto, prenderà appuntamento, via email, per la demo del progetto. Il codice prodotto e la relazione NON devono essere inviati via mail ma solo presentati al momento della demo. Tale demo consiste nella valutazione del prodotto realizzato. Si svolge utilizzando i calcolatori dei laboratori didattici del corso di studio. Il gruppo si presenterà portando una stampa del codice realizzato, ed una breve relazione che descriva come il progetto e’ stato realizzato, i dettagli del protocollo realizzato, e quali test sono stati effettuati. Infine, il codice del progetto verrà compilato ed eseguito sulle macchine dei laboratori, per valutarlo.

Voto del progetto:

Il voto ottenuto per il progetto di Laboratorio di Programmazione di Rete, concorrerà a formare il voto del “Corso Integrato di Reti di Calcolatori e Laboratorio di Programmazione di Rete” mediante la media aritmetica con il voto ottenuto nello scritto del corso di Reti di Calcolatori.

Scadenza del progetto:

Il progetto di Laboratorio di Programmazione di Rete per l’anno accademico 2007/08 dovrà essere consegnato entro metà febbraio 2009.