Specifiche del Progetto

“QoS per VoWLAN sfruttando Multi-homing”

per l’esame di Laboratorio di Programmazione di Rete

a.a. 2008/09, Dott. Vittorio Ghini

Scadenza consegna, entro metà febbraio 2010.

(Versione Non Definitiva, 17 aprile 2009)

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). L’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. L’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.

Figura 2: Formato del pacchetti prodotti e spediti dalle applicazioni Appf e Appm.

Sia l’AppMobile che l’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, come indicato in figura 2, contengono nei primi 4 Bytes un numero intero, ordinato secondo l’endianess della macchina locale, che identifica univocamente in ordine crescente ciascun pacchetto generato. I successivi 8 Bytes contengono una struttura struct timeval il cui valore rappresenta l’istante in cui il pacchetto è stato generato, ottenuto con un’invocazione alla funzione gettimeofday().

Parallelamente, sia l’AppMobile che l’AppFixed si predispongono per ricevere dalle stesse connessioni TCP dei pacchetti di 100 Bytes, quelli prodotti dall’altra applicazione.

E’ importante notare che le applicazioni sono predisposte per ricevere i pacchetti anche in ordine diverso dall’ordine in cui sono stati spediti, e possono ricevere anche pacchetti duplicati (che ovviamente però scartano) ma la ricezione di pacchetti duplicati è considerata un fattore di demerito.

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 3, 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. Il Monitor, per default, attiva la riconfigurazione (chiusura e apertura) delle porte automaticamente. Per favorire il debugging, è però possibile disattivare la riconfigurazione automatica delle porte, lanciando il Monitor con una opportuna riga di comando in cui l’ultimo parametro deve essere il valore 1. In tal modo il Monitor non disattiva le porte automaticamente ma lo fa solo quando l’utente preme il tasto “ENTER”. In particolare, 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.

Il Monitor mantiene aperte al massimo 4 porte UDP sul lato mobile e le corrispondenti 4 porte sul lato fixed.

Figura 3: 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, come indicato nella figura 4: 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. La Notifica NON viene inoltrata immediatamente dal Monitor al MobileLoadBalancer, e può subire un ritardo fino a 30 nsec.

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

Emulazione dei canali trasmissivi.

Il monitor considera ciascuna coppia di porte (800X,900X) un percorso di rete formato da una parte wireless ed una parte wired, in cui la parte wireless costituisce il primo hop del percorso dal dispositivo mobile (la porta 800X) verso il dispositivo fisso (la porta 900X).

La parte wireless è affetta da un’alta percentuale di perdita di pacchetti (dell’ordine del 50%). Le perdite sul canale wireless sono concentrate tipicamente in intervalli di tempo di dimensioni comprese nell’intervallo [200ms;1400ms] in cui tutti i pacchetti sono persi. Questi burst di perdite sono separati da intervalli di tempo aventi dimensioni comprese nell’intervallo [200ms;1400ms] in cui i pacchetti invece sono correttamente trasmessi; in tali intervalli fortunati solo pochi pacchetti sparsi (circa un 1%) vengono persi in modo uniforme nell’intervallo.

Anche la parte wired può perdere qualche pacchetto in modo sparso, con un basso tasso di perdite circa di 1%.

La Notifica (ACK o NACK) fornita dal Monitor al dispositivo mobile riguarda solo l’esito della trasmissione di un datagram UDP nella sola parte wireless. Il pacchetto potrebbe superare la parte wireless ed essere scartato nella parte wired. E’ importante perciò sottolineare che il Monitor potrebbe notificare la corretta trasmissione di un datagram (ACK) nella parte wireless, ma nonostante questo scartarlo con una probabilità pari alla probabilità di perdita del canale wired (1%).

Inoltre, è’ importante notare che il Datagram UDP spedito dal MobileLoadBalancer al Monitor in teoria potrebbe essere scartato dal kernel in caso di riempimento dei buffer dei socket (evento poco probabile) e quindi il Monitor potrebbe non ricevere il datagram e quindi il Monitor potrebbe NON INVIARE la notifica per quel datagram UDP che non ha mai ricevuto.

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 è che l’AppMobile comincia a trasmettere blocchi dati da 100 Bytes subito dopo avere effettuato la connessione con il MobileLoadBalancer. Al contrario, l’AppFixed comincia a trasmettere blocchi dati da 100 Bytes solo dopo avere ricevuto dal FixedLoadBalancer un primo blocco originato dall’AppMobile.

Figura 5: Esempio di ritardi e perdite introdotti in un canale trasmissivo

In ascissa l’identificatore univoco crescente dei datagram.

In ordinata la latenza di trasmissione espressa in msec.

Il valore di latenza -100 indica un datagram perso.

Traffico prodotto dalle applicazioni

Le applicazioni possono produrre tre tipi di traffico, producendo pacchetti da 100 Bytes in tre diverse modalità, modalità selezionate dal secondo parametro passato a riga di comando alle applicazioni stesse:

0: nessun traffico generato; in realtà viene spedito un pacchetto ogni 10 secondi.

1: traffico continuo; pacchetti generati continuamente ogni 40 msec.

2: traffico conversazionale; sequenze di pacchetti voce intervallati da silenzi durante i quali non vengono prodotti pacchetti.

Durante la demo verranno testate le diverse modalità di traffico.

Obiettivo del Progetto:

Poiché i datagram UDP possono essere scartati dai canali trasmessivi emulati dal Monitor, le due applicazioni MobileLoadBalancer e FixedLoadBalancer hanno il compito di realizzare un protocollo di livello sessione che decida quali canali utilizzare per le trasmissioni e decida se e quando effettuare eventuali ritrasmissione dei datagram UDP per ottenere che: PIU’ del 90% dei pacchetti voceda 100 Bytes creati da AppMobile e AppFixed giungano entro 150 msec all’altro end system (rispettivamente AppFixed e AppMobile). Tale protocollo di livello sessione deve essere implementato esclusivamente mediante datagram UDP scambiati tra MobileLoadBalancer e FixedLoadBalancer attraverso i canali trasmessivi del Monitor.

Dei cinque applicativi, tre (AppMobile, AppFixed, Monitor) vengono già forniti, mentre gli altri due (MobileLoadBalancer e FixedLoadBalancer, in colore arancione) 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.

L’AppMobile e l’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 consumo di bandwidth (calcolata dal Monitor, che conta i byte scambiati), considerata in termini di overhead di trasmissione; la quantità di dati complessivamente scambiati tra i LoadBalacer dovrebbe essere inferiore al 110% del traffico generato in totale dalle due applicazioni; l’overhead cioè non dovrebbe superare il 10%.

o interattività realizzata (valutata mediante i file di log dei ritardi delay.txt ),

o uso di CPU,

o occupazione di memoria,

o numero di pacchetti duplicati che arrivano alle applicazioni.

· chiarezza del codice realizzato,

· numero di componenti del gruppo (deve essere minore o uguale a 4).

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 (delaymobile.txt e delayfixed.txt) 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 2008/09 dovrà essere consegnato entro metà febbraio 2010.