Specifiche del Progetto

“Fornire Interattivita’ a comunicazione TCP sfruttando Multi-homing

per l’esame di Laboratorio di Programmazione di Rete

a.a. 2006/07,   Dott. Vittorio Ghini

 

Scadenza consegna, entro inizio febbraio 2008.

(Versione Non Definitiva, 14 maggio 2007)

 

Scenario:

Si vuole realizzare un sistema come descritto nella figura qui sotto, con tutti i processi che eseguono su una stesso host: i due applicativi più esterni sono identificati dai nomi Sender (S) e Receiver (R). Il Sender svolge il classico ruolo di client TCP e dopo l’instaurazione della connessione TCP spedisce dei dati verso il Receiver. Il Receiver svolge il ruolo classico di server in una connessione TCP, e dopo l’instaurazione della connessione riceve dei dati.

La coppia di programmi identificata con i nomi ProxySender (PS) e ProxyReceiver (PR), idealmente collegati tra loro mediante tre diverse connessioni TCP, svolgono il compito di instradare e bilanciare il flusso dei dati, ricevuti dal Sender, attraverso le tre connessioni TCP. Il quinto applicativo, denominato Ritardatore (R), ha il ruolo di emulare i tre percorsi della rete su cui operano le tre connessioni TCP tra ProxySender e ProxyReceiver.

Dei cinque applicativi, tre (Sender, Receiver, Ritardatore) vengono già forniti, mentre gli altri due (ProxySender e ProxyReceiver, in colore rosso) debbono essere implementati dagli studenti.

Il Sender genera dei blocchi di byte aventi dimensione di circa 2 KB, li marca con un timestamp che indica l’istante in cui sono stati generati e li invia verso il Receiver. Il Receiver riceve questi blocchi di dati, controlla l’orologio di sistema, sottrae il valore del timestamp del pacchetto ricevuto e in questo modo calcola il tempo impiegato per la trasmissione del pacchetto. Il receiver produce un file di testo delay.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.

Obiettivo:

Lo scopo dei due applicativi ProxySender e ProxyReceiver da realizzare, e’ di implementare un protocollo di livello applicazione che si occupi di instradare i dati ricevuti da ProxySender a ProxyReceiver attraverso le tre connessioni, cercando di far si che ogni blocco dati spedito dal Sender giunga al Receiver entro un tempo massimo di 500 millisecondi (ms).

 

Fase di setup:

L’instaurazione iniziale delle connessioni TCP, avviene così: quando il Sender si connette al ProxySender, questo deve connettersi al Ritardatore con le tre connessioni TCP, che a sua volta si connetterà al ProxyReceiver con le tre connessioni TCP che a sua volta dovrà connettersi al Receiver.

 

Crash di connessioni:

Qualora, durante la successiva trasmissione dei dati, una delle connessioni tra ProxySender e Ritardatore vada in crash, o comunque risulti inutilizzabile, il ProxySender non può tentare di riconnettersi al Ritardatore per instaurare una nuova connessione col ProxyReceiver al posto di quella caduta o inutilizzabile. In ogni caso, il ProxySender non dovrà mai utilizzare più delle tre connessioni con il Ritardatore e non potrà mai connettersi direttamente al ProxyReceiver.

 

Parametri necessari ai programmi:

Il Sender prende come parametri a riga di comando l’indirizzo IP e la porta TCP su cui il ProxySender rimane in attesa di ricevere la connessione dal Sender. Se non viene specificato nessun parametro il Sender usa i parametri di default 127.0.0.1 6001.

Il ProxySender prenderà sette parametri a riga di comando, nell’ordine la porta TCP su cui resta in attesa di ricevere la connessione TCP dal Sender, e tre coppie di (indirizzi IP e di porte TCP) su cui il Ritardatore rimane in attesa di ricevere le connessioni dal ProxySender. Se non viene specificato nessun parametro il ProxySender usa i parametri di default 6001 127.0.0.1 7001 127.0.0.1 7002 127.0.0.1 7003.

Il Ritardatore prendera’ dieci parametri a riga di comando, nell’ordine le tre porte TCP su cui resta in attesa di ricevere le connessione TCP dal ProxySender, e tre coppie di (indirizzi IP e di porte TCP) su cui il ProxyReceiver rimane in attesa di ricevere le connessioni dal Ritardatore. A questi segue un double che rappresenta la percentuale di blocchi TCP che verranno affetti da un ritardo, ad opera del Ritardatore. A questi infine seguono tre numeri interi che rappresentano la banda passante (espressi in bytes al secondo) di ciascun connessione tra PC e PS attraverso il Ritardatore. Se non viene specificato nessun parametro il Ritardatore usa i parametri di default 7001 7002 7003 127.0.0.1 8001 127.0.0.1 8002 127.0.0.1 8003  0.001.

 

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à (tutti i pacchetti devono giungere alla destinazione)

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 Ritardatore, che conta i byte scambiati),

·        portabilità del codice realizzato (gestione di endianess e allineamento struct)

·        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 Ritardatore colleziona informazioni sui dati che lo hanno attraversato. In particolare, killando il Ritardatore (premere CTRL+C) vengono visualizzati il numero di byte trasmessi attraverso ciascuna connessione. Inoltre, il Receiver produce un file di log delay.txt contenente il tempo di trasmissione di ciascun pacchetto. E’ inoltre importante evitare sprechi di tempo di CPU.

I parametri passati per default al Ritardatore sono solo indicativi, all’atto della demo del progetto, questi potrebbero essere modificati, pur rimanendo dello stesso ordine di grandezza. Si consiglia di effettuare prove con diverse configurazioni del ritardatore.

 

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 2006/07 dovrà essere consegnato entro inizio febbraio 2008.