Homework 1: Server UDP concorrente

Transcript

1 OLITECNICO DÌ TORINO III Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica Homework 1: Server UDP concorrente Programmazione distribuita I Studente: ROSICA MICHELE matricola:

2 Prova d esame in C con socket Si scriva in C ed utilizzando i socket un cliente ed un servitore che, comunicando mediante l UDP, effettuino le seguenti operazioni: 1. L utente che utilizza il software cliente può richiedere di inviare al server un file (upload), mediante il comando UP <nomefile>. L upload deve avere le seguenti caratteristiche: a. Il server che riceve la segnalazione di upload, apre un file locale in scrittura. b. Il cliente invia il file suddividendolo in blocchi di lunghezza opportuna. c. La fine del file è segnalata mediante l invio di un blocco vuoto (senza dati). d. Il server che riceve la segnalazione di fine file, chiude il file locale e conferma il successo dell operazione. 2. L utente che utilizza il software cliente può chiedere di ricevere un file memorizzato sulla macchina server (download), mediante il comando DOWN <nomefile>. Il download deve avere le seguenti caratteristiche: a. Il server che riceve la richiesta di download apre il relativo file locale in lettura. b. È sempre il cliente che richiede la lettura di un nuovo frammento del file, specificandone la lunghezza in bytes. c. Il server invia il frammento richiesto. d. La fine del file è segnalata dall invio di un frammento vuoto o di lunghezza inferiore a quella richiesta dal cliente. e. La fine del download provoca la chiusura del file locale lato server. f. Il cliente può chiedere la fine della lettura del file in qualsiasi momento, con un apposito comando. 3. Mentre si stanno svolgendo le operazioni di upload di un file non si può far partire un operazione di download, e viceversa. 4. Il server deve essere costituito da 4 processi pre-forked, nel momento in cui si iniziano le operazioni. 5. Il cliente non deve bloccare l interfaccia con l utente, nel caso vi siano operazioni in corso sulla rete. 6. Bisogna trattare il caso di errori nella trasmissione. 7. Bisogna rilevare e recuperare eventuali crash di server e cliente. 8. Bisogna evitare eventuali problemi di leakage. 9. Bisogna trattare l accesso concorrente allo stesso file. Introduzione La trasmissione prevede l'uso di un socket UDP, il processo padre (del server) accetta le richieste di connessione che arrivano dai vari client. Il pre-fork gestisce massimo quattro processi contemporaneamente. La politica adottata è quella di creare un socket per quel client, il quale ha effettuato la richiesta e assegnargli una porta; il client da quel momento in poi comunicherà con il server esclusivamente su quella porta. Alla fine dell operazione di quel client, il server chiuderà quel socket dando cosi la possibilità a quel processo di ritornare in attesa di una nuova richiesta. Il programma è CASE-INSENSITIVE quindi accetta comandi in carattere maiuscolo e minuscolo. Si ricorda che i nomi dei file non devono contenere spazi tra loro. Compilazione Server Client gcc o server my_server.c gcc o server -DTRACE my_server.c gcc o server -DTRACE my_server.c -DWALL gcc o server -DTRACE my_server.c -DWALL -DSTAMP run:./server porta gcc o client my_client.c gcc o client -DTRACE my_client.c gcc o client -DTRACE my_client.c -DWALL gcc o client -DTRACE my_client.c -DWALL -DSTAMP run:./client ip porta Opzioni: -DTRACE: Fornisce le informazioni utili all avvio. -DSTAMP: Visualizza le PDU trasmesse tra client e server. 2

3 -DWALL : Abilita tutti i messaggi di utilità generale (simile a GCC -Wall) fornite dal programma. Molto utile quando l utente vuole capire le attività svolte dal programma. Si consiglia la seguente compilazione (default): Server gcc o server -DTRACE my_server.c Client run:./server porta gcc o client -DTRACE my_client.c run:./client ip porta Si ricorda che con questa compilazione il server è in modalità compatta, il server adotta la politica nascosta e cioè i messaggi ritenuti di poca importanza non vengono visualizzati; per ovviare a questa modalità basta aggiungere -DWALL. Strutture /******************************************************************** STRUCT ********************************************************************/ typedef struct PCK pck_t; typedef struct CMD cmd_t; /** * Struttura PDU (1040 byte) * uint8_t - 1 byte * uint16_t - 2 byte * uint32_t - 4 byte */ struct PCK { }; uint16_t src_port; /* Source port [16 bit] */ uint16_t dst_port; /* Destination port [16 bit] */ uint32_t ack; /* Acknowledgment number [32 bit] */ uint32_t offset; /* Data offset [32 bit] */ uint16_t length; /* Length [16 bit] */ char data[maxbuf]; /* Data [1024 byte] */ uint16_t flag; /* FLAG [16 bit] */ /** * Struttura comandi (client) */ struct CMD { char cmd[maxh]; cmd_t *next; }; 3

4 Struttura di un datagramma UDP Un datagramma (o pacchetto) UDP è così strutturato (in realtà ha meno campi): Source port [16 bit] - Identifica il numero di porta sull'host del mittente del datagramma; Destination port [16 bit] - Identifica il numero di porta sull'host del destinatario del datagramma; Acknowledgment number [32 bit] - Numero di riscontro che conferma la ricezione di una parte del flusso di dati nella direzione opposta, indicando il valore del prossimo Sequence number che l'host mittente del datagramma UDP si aspetta di ricevere. Offset [32 bit] Indica l offset all interno del file. Length [16 bit] - contiene la lunghezza totale in bytes del datagramma UDP (dati); Data [1024 Byte] - contiene i dati del datagramma UDP. Flags [16 bit] - Bit utilizzati per il controllo del protocollo: ACK [flag = 0] - indica che il campo Acknowledgment number è valido; ERR [flag = 1] - indica che durante il trasferimento si è verificato un errore. FIN [flag = 2] - se settato a 1 indica che l'host mittente del segmento vuole chiudere la connessione UDP aperta con l'host destinatario. Il mittente attende la conferma dal ricevente (con un FIN-ACK). Quando l'host destinatario invierà il pacchetto con FIN-ACK la connessione sarà considerata completamente chiusa; altrimenti la connessione è ritenuta chiusa per metà: l'host che ha inviato FIN non potrà più inviare dati, mentre l'altro host ha il canale di comunicazione ancora disponibile. URG [flag = 3] - indica che nel flusso sono presenti dati urgenti, ad esempio in alcuni casi viene usato per indicare che il file è in stato di lock. Sequence number e Acknowledgment number Il Sequence number, o numero di sequenza, serve a posizionare il carico utile del datagramma UDP all'interno del flusso di dati. UDP si aspetta di ricevere il segmento successivo all'ultimo segmento ricevuto in ordine, ovvero quello il cui numero di sequenza è pari al numero di sequenza dell'ultimo segmento inviato in ordine. In relazione al numero di sequenza in ricezione UDP attua le seguenti procedure: se il numero di sequenza ricevuto è quello atteso si procede alla eliminazione della copia in memoria liberando i propri buffer. se il numero di sequenza ricevuto è maggiore di quello atteso deduce che uno o più segmenti ad esso precedenti sono andati persi o ritardati dal livello di rete sottostante. Pertanto si riprova ad inviare il giusto datagramma con il corretto numero di sequenza. Se entro tre tentativi non viene ricevuto o confermato il datagramma, si chiude la connessione segnalando che si è verificato un errore. Dal punto di vista dell algoritmo, i dati arriveranno in ordine anche se la rete ha per qualsiasi motivo alterato questo ordine, realizzando così il requisito della consegna ordinata dei dati. se il numero di sequenza ricevuto è inferiore a quello atteso, il segmento viene considerato un duplicato di uno già ricevuto e già inviato allo strato applicativo, e quindi scartato. Questo permette di realizzare l'eliminazione dei duplicati di rete. In ogni datagramma viene inviato un Acknowledgment Number, o numero di riscontro. Il numero di riscontro presente in un datagramma riguarda il flusso di dati nella direzione opposta. In particolare, il numero di riscontro inviato da A a B è pari al numero di sequenza atteso da A e, quindi, riguarda il flusso di dati da B ad A. Il protocollo UDP adotta la politica di Conferma cumulativa, ciò significa semplicemente che l'arrivo di numero di riscontro indica al ricevente che il mittente ha ricevuto correttamente la conferma. Per tale motivo, in trasmissione, UDP mantiene temporaneamente una copia del datagramma corrente, solo quando sarà confermato il corretto trasferimento, allora si potrà liberare la memoria (libera il proprio buffer da questi dati) e quindi passare al successivo datagramma. Per ciascun datagramma inviato, UDP avvia un timer, se il datagramma non riceve un ACK prima che il timer scada, UDP assume che il datagramma trasmesso sia andato perso e quindi lo ritrasmette fino a tre volte, dopodiché si chiude la connessione. I numeri di riscontro e i relativi timer permettono quindi di realizzare la consegna affidabile, ovvero di garantire che tutti i dati inviati siano consegnati anche se alcuni pacchetti vengono persi dalla rete. 4

5 I timer dell UDP : Timer di ritrasmissione Come descritto sopra, il timer di ritrasmissione serve a verificare che ciascun segmento trasmesso venga riscontrato. La corretta impostazione di questo timer è difficile ma molto importante, in quanto un timer troppo breve comporta ritrasmissioni inutili (il timer scatta mentre il riscontro o il pacchetto sono ancora in viaggio), mentre un timer troppo lungo comporta attese in caso di perdita di pacchetti; qui di default si è usato un timer pari a 3s, ma è possibile modificarlo in qualsiasi momento andando a settare un opportua costante. Timed wait L'ultimo timer utilizzato da UDP è il timed wait. In pratica, prima di disconnettere effettivamente una connessione, il ricevente attende un tempo pari al doppio del tempo del timer UDP: questo evita che dei pacchetti possano rimanere circolanti per la rete anche dopo la chiusura. Applicazioni che utilizzano UDP Le applicazioni che hanno la necessità di un trasferimento affidabile dei loro dati si affidano ovviamente a TCP. Le applicazioni più elastiche riguardo alla perdita dei dati e dipendenti dal tempo si affidano invece a UDP. Inoltre si utilizza UDP per comunicazioni in broadcast (invio a tutti i terminali in una rete locale) e multicast (invio a tutti i terminali iscritti ad un servizio). Di seguito è proposto un elenco dei principali servizi internet e dei protocolli che adottano: Applicazione Protocollo strato applicazione Protocollo strato trasporto Posta elettronica SMTP TCP Accesso a terminale remoto telnet TCP Trasferimento file FTP TCP Web HTTP TCP Streaming Audio/Video RTSP/RTP TCP (comandi) + UDP (flusso) Server di file remoto NFS tipicamente UDP Telefonia su internet (VoIP) SIP, H.323, altri tipicamente UDP Gestione della rete SNMP tipicamente UDP Protocollo di routing RIP tipicamente UDP Risoluzione dei nomi DNS tipicamente UDP Le principali differenze tra TCP e UDP (User Datagram Protocol), l'altro principale protocollo di trasporto della suite di protocolli Internet, sono: UDP non offre nessuna garanzia dell'arrivo dei datagrammi né sul loro ordine di arrivo, al contrario il TCP tramite i meccanismi di acknowledgement e di ritrasmissione su timeout riesce a garantire la consegna dei dati, anche se al costo di un maggiore overhead (raffrontabile visivamente confrontando la dimensione delle intestazioni dei due protocolli); TCP è un protocollo orientato alla connessione, pertanto per stabilire, mantenere e chiudere una connessione, è necessario inviare pacchetti di servizio i quali aumentano l'overhead di comunicazione. Al contrario, UDP invia solo i datagrammi richiesti dal livello applicativo; l'oggetto della comunicazione di TCP è il flusso di byte mentre quello di UDP è il singolo datagramma. L'utilizzo del protocollo TCP rispetto a UDP è, in generale, preferito quando è necessario avere garanzie sulla consegna dei dati o sull'ordine di arrivo dei vari segmenti (come per esempio nel caso di trasferimenti di file). Al contrario UDP viene principalmente usato quando l'interazione tra i due host è idempotente o nel caso si abbiano forti vincoli sulla velocità e l'economia di risorse della rete. Server e Client I due processi che comunicano attraverso una connessione UDP hanno ruoli diversi: Il processo che avvia una nuova connessione UDP è detto client, ed invia una richiesta di connessione verso una determinata porta. Affinché la connessione venga stabilita, su quella porta deve esserci un processo server "in ascolto", che accetta di stabilire una connessione UDP. Le porte conosciute e registrate sono quindi utilizzate dai processi server, e sono convenzionalmente associate a particolari servizi, in modo che un client sappia a quale porta connettersi per raggiungere un determinato server. Il processo server, che è in ascolto su una certa porta, rimane bloccato in attesa che un client si colleghi. Il processo client richiede di stabilire una connessione verso un determinato server su una determinata porta. Normalmente la porta sorgente usata dal client viene allocata dinamicamente dal sistema operativo del client. Quando UDP stabilisce la connessione, a entrambi i processi viene assegnato un socket tramite cui essi possono comunicare tra loro. Tipicamente il processo server 5

6 effettua una fork, affida al figlio il compito di comunicare con il nuovo client e si rimette in ascolto. Da questo punto in poi, client e server hanno ruoli simmetrici, e utilizzano gli stessi strumenti per comunicare attraverso il socket. Richieste 1. L utente che utilizza il software cliente può richiedere di inviare al server un file (upload), mediante il comando UP <nomefile>. L upload deve avere le seguenti caratteristiche: a. Il server che riceve la segnalazione di upload, apre un file locale in scrittura. b. Il cliente invia il file suddividendolo in blocchi di lunghezza opportuna. c. La fine del file è segnalata mediante l invio di un blocco vuoto (senza dati). d. Il server che riceve la segnalazione di fine file, chiude il file locale e conferma il successo dell operazione. Il client (UP) invia pacchetti in sequenza e si mette in attesa di conferma. Se la risposta non è coerente allora si prova a reinoltrare (x 3 volte) il pacchetto. Se non si riceve una risposta esatta in questi tentativi, il client termina la comunicazione, poichè la perdità di 3 pacchetti consecutivi dello stesso pacchetto possono essere sintomo di congestione della rete o guasto lato server. Il client (DOWN) invia la dimensione del suo pacchetto (ogni volta) dopodiché si mette in attesa di ricevere il pacchetto della giusta dimensione e in sequenza; quando riceve un pacchetto fuori sequenza: viene scartato e richiesto quello in sequenza. Se arriva un pacchetto che era già stato confermato, viene scartato; si accettano solo pacchetti in sequenza. void uploadcl (cmd_t **c, int fd, pck_t pk, char *filein, SA *sa, socklen_t salen); void uploadsr (int fd, char *filein, SA *sa, socklen_t salen); 2. L utente che utilizza il software cliente può chiedere di ricevere un file memorizzato sulla macchina server (download), mediante il comando DOWN <nomefile>. Il download deve avere le seguenti caratteristiche: a. Il server che riceve la richiesta di download apre il relativo file locale in lettura. b. È sempre il cliente che richiede la lettura di un nuovo frammento del file, specificandone la lunghezza in bytes. c. Il server invia il frammento richiesto. d. La fine del file è segnalata dall invio di un frammento vuoto o di lunghezza inferiore a quella richiesta dal cliente. e. La fine del download provoca la chiusura del file locale lato server. f. Il cliente può chiedere la fine della lettura del file in qualsiasi momento, con un apposito comando. Il server (DOWN) prima di trasferire un pacchetto attende sempre che il client gli dica da quanto vuole il suo pacchetto, dopodichè invia pacchetti in sequenza mettendosi in attesa di conferma. Se la risposta non è coerente allora si prova a reinoltrare (x 3 volte) il pacchetto. Se non si riceve una risposta esatta in questi tentativi, il client termina la comunicazione, poichè la perdità di 3 pacchetti consecutivi dello stesso pacchetto possono essere sintomo di congestione della rete o guasto lato server. Il server (UP) riceve un pacchetto fuori sequenza: viene scartato e richiesto quello in sequenza. Se arriva un pacchetto che era già stato confermato, viene scartato; si accettano solo pacchetti in sequenza. void downloadsr (int fd, pck_t pk, char *filein, SA *sa, socklen_t salen); void downloadcl (cmd_t **c, int fd, char *filein, SA *sa, socklen_t salen); 6

7 3. Mentre si stanno svolgendo le operazioni di upload di un file non si può far partire un operazione di download, e viceversa. Per gestire questo punto si è usata una lista dei comandi, in modo tale che il processo (client) non dimentichi i comandi digitati. Si è usata una lista FIFO, in questo vengono eseguiti i comandi in testa e cosi via fino all esaurimento della lista. Ogni comando viene estratto dalla lista ed eseguito. A questo punto il client può digitare infiniti comandi, fino all esaurimento di memoria disponibile. Cosi facendo i comandi verranno eseguiti uno alla volta e prima di procedere ad un download/upload si dovrà attendere il completamento del comando corrente. In qualsiasi momento è possibile digitare il comando ABORT, il quale interromperà immediatamente il trasferimento corrente. 4. Il server deve essere costituito da 4 processi pre-forked, nel momento in cui si iniziano le operazioni. Come si nota dalla figura 4.1, il server è costituito da 4 processi pre-forked, quindi al massimo si avranno 4 processi che lavorano contemporaneamente. Ogni volta che un processo termina le sue operazioni, chiude il socket, lasciando cosi posto ad un nuovo processo (sempre 4 processi max). 7

8 Figura 4.1: Pre-fork. Dalla figura 4.2 si nota che il primo processo ha terminato e a quel punto ha liberato il socket, lasciando cosi posto per un altro processo (il quinto client); successivamente terminando anche il secondo processo il successivo (sesto client) che aveva richiesto il file ottiene la risposta. In questo modo si servono in parallalo sempre al max 4 processi, ma solamente i primi che arrivano occupano i posti, il processo sfortunato (> 4), attenderà il completamento delle operazioni effettuate da un processo, non appena termina le sue operazioni il nuovo processo entrerà al suo posto. Il client (bloccato) viene avvertito tramite un messaggio dove gli viene detto che il server ha raggiunto il limite massimo di connessioni, a questo punto il client può decidere se attendere oppure chiudere la connessione. Figura 4.2: Pre-fork: Si servono altri client. Se un processo chiede più file contemporaneamente, una volta che si è terminata la prima operazione si controlla se c è un client che aveva fatto qualche richiesta ed era stato messo in attesa, se si allora si serve quel client dopo di che si procede al successivo. Si adotta questa politica per evitare che lavorino sempre gli stessi client, ma venga data la stessa possibilità a tutti i client (criterio di Round Robin per la schedulazione dei processi). 8

9 Terminazione dei processi Come si nota dalla figura 4.3 nei processi è presente il processo padre, il quale viene messo in wait; successivamente ci sono i quattro figli. Figura 4.3: Pre-fork. Come si nota dalla figura 4.4 i processi sono stati perfettamente rimossi. Figura 4.4: kill. 5. Il cliente non deve bloccare l interfaccia con l utente, nel caso vi siano operazioni in corso sulla rete. Questo punto viene fatto in automatico al punto 3. Si è usata una select in modo da sentire i comandi digitati dall utente utilizzando l opportuna funzione listencmd(). Questa funzione ha il compito di sentire i comandi digitati dall utente e memorizzarli in lista, solo alla fine del trasferimento si passerà ad eseguire il comando successivo. Vengono accettati solo i comandi : UP, DOWN, ABORT e QUIT; qualsiasi altro comando verrà ignorato. Si ricorda che il comando ABORT ha priorità maggiore rispetto agli altri comandi, di conseguenza se digitato interromperà immediatamente il trasferimento corrente. int listencmd (cmd_t **c, int fd); 9

10 6. Bisogna trattare il caso di errori nella trasmissione. Algoritmo: Stop and Wait TEST EFFETTUATI SERVER * Il server perde due pacchetti casuali 2 e 11: il protocollo (lato client) provvede a reinoltrarli. * Il server perde per 3 volte il pacchetto 2: è possibile che il client sia terminato oppure ci sia una forte congestione; a questo punto la connessione viene terminata. * Il server rimane in attesa per problemi della rete per un tempo T (sleep(t)): il protocollo (lato client) provvede a reinoltrare i pacchetti (x 3 volte) non vedendo le risposte di conferma (ACK) arrivare; non appena si riceve una conferma si passa al pacchetto ACK+1. Scaduto il numero di tentativi si chiude la connessione. CLIENT * Il client perde due pacchetti casuali 2 e 11: il protocollo (lato server) provvede a reinoltrarli. * Il client perde per 3 volte il pacchetto 2: è possibile che il server sia terminato oppure ci sia una forte congestione; a questo punto il trasferimento viene terminato. * Il client rimane in attesa per problemi della rete per un tempo T (sleep(t)) * Il client rimane in attesa per problemi della rete per un tempo T (sleep(t)): il protocollo (lato server) provvede a reinoltrare i pacchetti (x 3 volte) non vedendo le risposte di conferma (ACK) arrivare; non appena si riceve una conferma si passa al pacchetto ACK+1. Scaduto il numero di tentativi si termina il trasferimento. Come si nota dalla figura 6.1, vengono persi i pacchetti 2 e 11, successivamente questi vengono recuperati dal server e reinoltrati al client, a questo punto i pacchetti ricevuti e opportunamente controllati vengono salvati su disco. I pacchetti fuori sequenza vengono scartati figura 6.2. Figura 6.1: pacchetti 2 e 11 persi. Figura 6.2: pacchetto fuori sequenza. 10

11 In questa situazione figura 6.3 viene perso per 3 volte il pacchetto 2, questo risulta sintomo di errori di trasmissione quindi il server chiude il trasferimento; a questo punto il client rimuove il file perché corrotto. Figura 6.3: 3 pacchetti persi. In entrambe le procedure (UP e DOWN) si utilizza l'algoritmo STOP AND WAIT, quindi qualsiasi tipo di problema si verifichi nel server o nel client: in caso di successo: si passerà a spedire/attendere il pacchetto ACK+1. in caso di perdita: richiederanno/reinoltreranno opportunamente i pacchetti in sequenza. 7. Bisogna rilevare e recuperare eventuali crash di server e cliente. Fase download * Il server termina senza dire nulla al client: il client effettua una serie di tentativi (3) per vedere se il server sia ancora in attesa (richiedendo il pacchetto corretto); se dopo questi tentativi (e allo scadere del time out) il server non risponde, il client termina il trasferimento rimuovendo opportunamente il file creato. * Il client termina senza dire nulla al server: il server effettua una serie di tentativi (3) per vedere se il client sia ancora in attesa (riprovando ad inviare di nuovo lo stesso pacchetto); se dopo questi tentativi (e allo scadere del time out) il client non risponde, il server termina il trasferimento e si rimette in ascolto di nuove richieste. Fase di upload è analoga al download. Il server durante l avvio crea contemporaneamente 4 file uno per ogni client, dove li verranno registrate le operazioni del file corrente; se si dovesse rilevare un crash del server durante un trasferimento, il server quando sarà riavviato durante il suo boot provvedderà all eliminazione dei file corrotti. Il client durante l avvio crea un file, dove saranno registrate le sue operazioni di trasferimento; in caso di crash, quando sarà riavviato durante il suo boot sarà rimosso opportunamente il file corrotto. 8. Bisogna evitare eventuali problemi di leakage. Tutte le operazioni di allocazione (lato server) sono perfettamente rimosse alla terminazione del server, digitando il comando CTRL-C si provvederà all eliminazione dei processi figli (4) più l eliminazione del processo padre; inoltre si provvederà all eliminazione dei file di log a meno che questi non contengano file corrotti dove al successivo riavvio verranno rimossi correttamente. Tutte le operazioni di allocazione (lato client) sono perfettamente rimosse alla terminazione del client digitando il comando QUIT. 11

12 9. Bisogna trattare l accesso concorrente allo stesso file. Come si nota dalla figura 9.1, il server quando apre il file in scrittura mette il file nello stato di lock. Il successivo client che tenterà di inviare lo stesso file (con lo stesso nome) verrà bloccato, il quale riceverà un messaggio che il file è lock. Si ricorda che il lock è messo esclusivamente in scrittura, quindi è possibile leggero contemporaneamente, ma non scriverlo. Figura 9.1: Lock (in scrittura). Figura 9.2: Più client possono richiedere lo stesso file. 12

13 Come si nota dalla figura 9.3, inviando il file al server (UP) e poi richiedendo lo stesso file da un altro client (DOWN), il file durante il completamento è messo in lock per questo motivo non è possibile scaricarlo; solo quando il server ha ricevuto correttamente il file può procedere con ulteriori richieste. Figura 9.3: up e poi down. Dalla figura 9.3 si verifica la situazione opposta e cioè, il client(down) richiede un file, un altro client tenta di inviare un file con lo stesso nome di quello che sta trasferendo in quel momento; in questa situazione si evita di sovrascrivere un file mentre questo è in lettura. Figura 9.4: down e poi up. 13

14 10. Funzionalità aggiuntive Handshake (botta e risposta tra client e sever) ProgressDownload() (calcola il tempo di trasferimento, byte inviati/ricevuti e lo speed) checkip () - Controllo degli indirizzi IPV4/IPV6 (si accettano solo indirizzi validi) myself () Da le seguenti informazioni: Sistema operativo(nome, versione, ecc.), alias presenti, indirizzi IPV4/IPV6 della macchina utilizzata; un esempio si trova nella figura 9.4. Senza Handshake: Con Handshake: Figura 10.1: senza Handshake. Figura 10.2: Handshake. Test di esecuzione In figura 10.3 si riporta il seguente test effettuato in labinf con il Sistema operativo Fedora 13. Il test è stato fatto su una pen-drive con un file di circa 3GB, dimostrando cosi che anche con file di certe dimensioni l algoritmo sviluppato risulta efficiente. Per semplicità il programma lavora a 32bit, questo non vuol dire che il server o client non funzionino con file maggiori di 4GB, ma che con file maggiori i contatori utilizzati non riporteranno valori corretti; il file sarà comunque trasferito correttamente. Per trasferire in modo corretto i file maggiori di 4GB, basta togliere il controllo messo all inizio del trasferimento: if (dimf <= 0 dimf > UINT32_MAX) e sostituirlo con: if (dimf <= 0 dimf > UINT64_MAX). A questo punto si potranno trasferire file maggiori di 4GB fino ad arrivare ad un massimo di 8GB; ad ogni modo si deve estendere anche il formato delle variabili usate portandole da 32bit (uint32_t) a 64bit (uint64_t). 14

15 Figura 10.3: Max transfer 4GB. Test effettuati su: Ubuntu v and v.11 Fedora v.13 Xubuntu v.10 La maggior parte dei test è sono stati effettuati sul sistema operativo Ubuntu v di Linux, pertanto si consiglia di testarlo su questa versione. 15