Analisi per via simulativa del protocollo tcp a ritrasmissione asimmetrica anticipata su wifi

Viene implementato un algoritmo di ritrasmissione dei pacchetti nel protocollo TCP. Lo studio viene fatt utilizzando il simulatore OMNET++ e il framework INET

TCP a ritrasmissione asimmetrica anticipata su WiFi

Nell'ambito dell'architettura RWMA per l'aumento della qualità del servizio in ambiente wireless, si colloca la ritrasmissione asimmetrica anticipata su wifi. Lo scopo è migliorare ed ottimizzare la comunicazione nel livello datalink tra Access Point e Nodo Mobile per quanto riguarda le connessioni TCP. Il progetto è sviluppato nell'ambiente simulativo OMNET++/INET.

TCP a ritrasmissione asimmetrica anticipata su Access Point WiFi

La perdita di pacchetti durante una trasmissione su una rete Wireless influisce in maniera fondamentale sulla qualità del collegamento tra due End-System. Lo scopo del progetto è quello di implementare una tecnica di ritrasmissione asimmetrica anticipata dei pacchetti perduti, in modo da minimizzare i tempi di recupero dati e migliorare la qualità della comunicazione. Partendo da uno studio su determinati tipi di ritrasmissione, in particolare quelli implementati dal progetto ABPS, Always Best Packet Switching, si è maturata l'idea che un tipo di ritrasmissione particolarmente utile potrebbe avvenire a livello Access Point: nel caso in cui la perdita di pacchetti avvenga tra l'AP e il nodo mobile che vi è collegato via IEEE802.11, invece che attendere la ritrasmissione TCP e Effettuata dall'End-System sorgente è lo stesso Access Point che e effettua una ritrasmissione verso il nodo mobile per permettere un veloce recupero dei dati perduti. Tale funzionalità stata quindi concettualmente divisa in due parti, la prima si riferisce all'applicazione che si occupa della bufferizzazione di pacchetti che attraversano l'AP e della loro copia in memoria per poi ritrasmetterli in caso di segnalazione di mancata acquisizione, la seconda riguardante la modifica al kernel che permette la segnalazione anticipata dell'errore. E' già stata sviluppata un'applicazione che prevede una ritrasmissione anticipata da parte dell'Access Point Wifi, cioè una ritrasmissione prima che la notifica di avvenuta perdita raggiunga l'end-point sorgente e appoggiata su un meccanismo di simulazione di Error Detection. Inoltre è stata anche realizzata la ritrasmissione asincrona e anticipata del TCP. Questo documento tratta della realizzazione di una nuova applicazione che fornisca una più effciente versione del buffer di pacchetti e utilizzi il meccanismo di una ritrasmissione asimmetrica e anticipata del TCP, cioè attivare la ritrasmissione su richiesta del TCP tramite notifiche di validità del campo Acknowledgement.

Simulazione del protocollo TCP a ritrasmissione asimmetrica anticipata su WiFi

Progettazione e realizzazione di uno strumento simulativo che permette l'analisi degli effettivi vantaggi portati dalla ritrasmissione anticipata su WiFi applicata al protocollo TCP.

Criteri di valutazione del protocollo TCP

La diffusione di Internet negli ultimi anni e lo sviluppo sempre crescente nell'ambito delle reti di telecomunicazione, hanno portato oggi ad una vera e propria esplosione della diffusione di nuove tecnologie di trasmissione. Inizialmente il protocollo di trasporto dati, TCP, non era stato pensata per operare in scenari diversi da quello della rete fissa. Con l'introduzione di nuovi scenari, come quello wireless, wimax e satellitare, si è notato come le prestazioni peggiorino in questi ambienti. Proprio per questo, il protocollo TCP ha subito parecchie modifiche negli anni e sono state realizzate alternative atte a migliorare l'inefficienza del protocollo. Le modifiche, a cui il TCP è stato sottoposto, sono basate su alcuni criteri di valutazione e l'introduzione di meccanismi come il controllo del flusso o il controllo di congestione in modo da migliorare le performance in ambienti “ostili”. Molti ricercatori si sono concentrati nello studio e modifica di questi nuovi meccanismi cercando di adattare al meglio il TCP secondo diversi scenari di rete, trascurando così altri criteri un pò meno noti. Dopo aver introdotto lo scenario con la descrizione del protocollo TCP, andremo a descrivere e illustrare questi “nuovi criteri” presentando alcuni recenti studi effettuati, in seguito andremo a presentare un nuova versione del protocollo chiamata Early Warning TCP e nell'ultimo capitolo andremo a presentare delle conclusioni degli studi presentati.

Criteri di valutazione del protocollo TCP

Tesi relativa ai criteri di valutazione del protocollo TCP

Modellazione e comparazione del protocollo TCP in scenari di mobilità

Nell'ultimo ventennio l'impatto delle tecnologie wireless ha rivoluzionato il modo di comunicare. Tuttavia oltre a svariati benefici sono emersi diversi problemi di integrazione e ottimizzazione. Uno tra i protocolli più conosciuto e utilizzato in ambito di comunicazioni di rete, il TCP, viene sempre più spesso usato all'interno di sistemi wireless, per le sue caratteristiche di affidabilità e controllo, senza però fornire supporto specifico. Ciò è materia di forte dibattito e ricerca, che mira a cercare di raffinare le differenti versioni di TCP per renderle wireless-oriented. In questo lavoro si analizzano due varianti di sistema che sfruttano il TCP in scenari di mobilità, una con TCP classico e l'altra con TCP modificato tramite l'aggiunta di un meccanismo di ritrasmissione anticipata, e se ne studiano i vari aspetti e comportamenti, valutandone le prestazioni per mezzo di metodi matematici consolidati in letteratura.

Esperimenti di Modularizzazione dello Stack TCP-IP di Linux

In questo lavoro si introduce il progetto di estrarre lo stack tcp-ip dal kernel di linux e farlo funzionare come una normale libreria in userspace. Si parlerà dei vantaggi di avere lo stack tcp-ip in userspace, di altri progetti simili, del motivo per cui si è scelto lo stack di linux, dei principali problemi incontrati nel corso del lavoro, del percorso seguito, e di come il risultato possa essere migliorato per renderlo uno strumento effettivamente utile.

Sicurezza di rete, analisi del traffico e monitoraggio.

Il lavoro è stato suddiviso in tre macro-aree. Una prima riguardante un'analisi teorica di come funzionano le intrusioni, di quali software vengono utilizzati per compierle, e di come proteggersi (usando i dispositivi che in termine generico si possono riconoscere come i firewall). Una seconda macro-area che analizza un'intrusione avvenuta dall'esterno verso dei server sensibili di una rete LAN. Questa analisi viene condotta sui file catturati dalle due interfacce di rete configurate in modalità promiscua su una sonda presente nella LAN. Le interfacce sono due per potersi interfacciare a due segmenti di LAN aventi due maschere di sotto-rete differenti. L'attacco viene analizzato mediante vari software. Si può infatti definire una terza parte del lavoro, la parte dove vengono analizzati i file catturati dalle due interfacce con i software che prima si occupano di analizzare i dati di contenuto completo, come Wireshark, poi dei software che si occupano di analizzare i dati di sessione che sono stati trattati con Argus, e infine i dati di tipo statistico che sono stati trattati con Ntop. Il penultimo capitolo, quello prima delle conclusioni, invece tratta l'installazione di Nagios, e la sua configurazione per il monitoraggio attraverso plugin dello spazio di disco rimanente su una macchina agent remota, e sui servizi MySql e DNS. Ovviamente Nagios può essere configurato per monitorare ogni tipo di servizio offerto sulla rete.

Connessione di sitemi a microcontrollore con reti geografiche

Fra le varie ragioni della crescente pervasività di Internet in molteplici settori di mercato del tutto estranei all’ICT, va senza dubbio evidenziata la possibilità di creare canali di comunicazione attraverso i quali poter comandare un sistema e ricevere da esso informazioni di qualsiasi genere, qualunque distanza separi controllato e controllore. Nel caso specifico, il contesto applicativo è l’automotive: in collaborazione col Dipartimento di Ingegneria Elettrica dell’Università di Bologna, ci si è occupati del problema di rendere disponibile a distanza la grande quantità di dati che i vari sotto-sistemi componenti una automobile elettrica si scambiano fra loro, sia legati al tipo di propulsione, elettrico appunto, come i livelli di carica delle batterie o la temperatura dell’inverter, sia di natura meccanica, come i giri motore. L’obiettivo è quello di permettere all’utente (sia esso il progettista, il tecnico riparatore o semplicemente il proprietario) il monitoraggio e la supervisione dello stato del mezzo da remoto nelle sue varie fasi di vita: dai test eseguiti su prototipo in laboratorio, alla messa in strada, alla manutenzione ordinaria e straordinaria. L’approccio individuato è stato quello di collezionare e memorizzare in un archivio centralizzato, raggiungibile via Internet, tutti i dati necessari. Il sistema di elaborazione a bordo richiede di essere facilmente integrabile, quindi di piccole dimensioni, e a basso costo, dovendo prevedere la produzione di molti veicoli; ha inoltre compiti ben definiti e noti a priori. Data la situazione, si è quindi scelto di usare un sistema embedded, cioè un sistema elettronico di elaborazione progettato per svolgere un limitato numero di funzionalità specifiche sottoposte a vincoli temporali e/o economici. Apparati di questo tipo sono denominati “special purpose”, in opposizione ai sistemi di utilità generica detti “general purpose” quali, ad esempio, i personal computer, proprio per la loro capacità di eseguire ripetutamente un’azione a costo contenuto, tramite un giusto compromesso fra hardware dedicato e software, chiamato in questo caso “firmware”. I sistemi embedded hanno subito nel corso del tempo una profonda evoluzione tecnologica, che li ha portati da semplici microcontrollori in grado di svolgere limitate operazioni di calcolo a strutture complesse in grado di interfacciarsi a un gran numero di sensori e attuatori esterni oltre che a molte tecnologie di comunicazione. Nel caso in esame, si è scelto di affidarsi alla piattaforma open-source Arduino; essa è composta da un circuito stampato che integra un microcontrollore Atmel da programmare attraverso interfaccia seriale, chiamata Arduino board, ed offre nativamente numerose funzionalità, quali ingressi e uscite digitali e analogici, supporto per SPI, I2C ed altro; inoltre, per aumentare le possibilità d’utilizzo, può essere posta in comunicazione con schede elettroniche esterne, dette shield, progettate per le più disparate applicazioni, quali controllo di motori elettrici, gps, interfacciamento con bus di campo quale ad esempio CAN, tecnologie di rete come Ethernet, Bluetooth, ZigBee, etc. L’hardware è open-source, ovvero gli schemi elettrici sono liberamente disponibili e utilizzabili così come gran parte del software e della documentazione; questo ha permesso una grande diffusione di questo frame work, portando a numerosi vantaggi: abbassamento del costo, ambienti di sviluppo multi-piattaforma, notevole quantità di documentazione e, soprattutto, continua evoluzione ed aggiornamento hardware e software. È stato quindi possibile interfacciarsi alla centralina del veicolo prelevando i messaggi necessari dal bus CAN e collezionare tutti i valori che dovevano essere archiviati. Data la notevole mole di dati da elaborare, si è scelto di dividere il sistema in due parti separate: un primo nodo, denominato Master, è incaricato di prelevare dall’autovettura i parametri, di associarvi i dati GPS (velocità, tempo e posizione) prelevati al momento della lettura e di inviare il tutto a un secondo nodo, denominato Slave, che si occupa di creare un canale di comunicazione attraverso la rete Internet per raggiungere il database. La denominazione scelta di Master e Slave riflette la scelta fatta per il protocollo di comunicazione fra i due nodi Arduino, ovvero l’I2C, che consente la comunicazione seriale fra dispositivi attraverso la designazione di un “master” e di un arbitrario numero di “slave”. La suddivisione dei compiti fra due nodi permette di distribuire il carico di lavoro con evidenti vantaggi in termini di affidabilità e prestazioni. Del progetto si sono occupate due Tesi di Laurea Magistrale; la presente si occupa del dispositivo Slave e del database. Avendo l’obiettivo di accedere al database da ovunque, si è scelto di appoggiarsi alla rete Internet, alla quale si ha oggi facile accesso da gran parte del mondo. Questo ha fatto sì che la scelta della tecnologia da usare per il database ricadesse su un web server che da un lato raccoglie i dati provenienti dall’autovettura e dall’altro ne permette un’agevole consultazione. Anch’esso è stato implementato con software open-source: si tratta, infatti, di una web application in linguaggio php che riceve, sotto forma di richieste HTTP di tipo GET oppure POST, i dati dal dispositivo Slave e provvede a salvarli, opportunamente formattati, in un database MySQL. Questo impone però che, per dialogare con il web server, il nodo Slave debba implementare tutti i livelli dello stack protocollare di Internet. Due differenti shield realizzano quindi il livello di collegamento, disponibile sia via cavo sia wireless, rispettivamente attraverso l’implementazione in un caso del protocollo Ethernet, nell’altro della connessione GPRS. A questo si appoggiano i protocolli TCP/IP che provvedono a trasportare al database i dati ricevuti dal dispositivo Master sotto forma di messaggi HTTP. Sono descritti approfonditamente il sistema veicolare da controllare e il sistema controllore; i firmware utilizzati per realizzare le funzioni dello Slave con tecnologia Ethernet e con tecnologia GPRS; la web application e il database; infine, sono presentati i risultati delle simulazioni e dei test svolti sul campo nel laboratorio DIE.