IP Mobility e Multihoming nell'architettura Serval

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "IP Mobility e Multihoming nell'architettura Serval"

Transcript

1 Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Protocolli per Reti Mobili IP Mobility e Multihoming nell'architettura Serval Anno Accademico 2014/2015 Candidato: Umberto Ferrandino matr. N46/000932

2 IP Mobility e Multihoming nell'architettura Serval Umberto Ferrandino LATEX 2

3 Dedicato a chi, nei modi più svariati, ma sempre con le migliori intenzioni, mi ha sostenuto ed accompagnato in questo cammino. 3

4 Indice Introduzione 5 1 Serval Architecture Problematiche arontate Cos'è Serval? La rete del futuro Il concetto di Servizio Service Access Layer (SAL) Installazione del SAL Funzionalità di base Ripensare lo stack TCP/IP Livello Applicazione Livello Trasporto Livello Rete Astrazione dei servizi e dei ussi Service Naming Flow Naming Inoltro dei pacchetti nello stack Serval Active Socket Forwarding e data plane Service discovery e registration Meccanismi di segnalazione eventi Prototipo dell'architettura Benchmark performance Casi di studio Web Service replicato con load balancing Storage distribuito Migrazione ussi e macchine virtuali Translator per compatibilità con host legacy 32 8 Dimostrazioni e test di funzionamento Catturare pacchetti Serval con Wireshark Invio di un le Flow migration Conclusioni 39 Bibliograa 40 4

5 Introduzione Fin dagli anni sessanta, la rete Internet, o ancora prima ARPANET, si è evoluta seguendo quelle che erano le necessità cui tale invenzione poteva far fronte. In pochi anni, il mondo intero ha assistito a quella che è probabilmente una delle più grandi rivoluzioni tecnologiche che la storia ricordi: da un progetto partito per essere un esperimento militare, poi un modo per interconnettere una quantità limitata di terminali, si è giunti ad interconnettere l'intero globo, rendendo pressoché irrisoria ogni distanza e possibile ogni comunicazione. Come è ovvio che sia, anché tale evoluzione fosse possibile, la rete ha dovuto subire una serie di cambiamenti e migliorie, con l'introduzione di nuovi protocolli e funzionalità, al ne di restare al passo con i tempi e garantire specici standard in materia di sicurezza, ecienza e quant'altro. Ad oggi, Internet va incontro ad ulteriori e più radicali cambiamenti. Infatti, nel corso degli anni, pur evolvendosi, la struttura di base della rete è rimasta fedele allo stesso modello, il famoso Stack TCP/IP. Con l'avvento del cosiddetto Web 2.0, Internet è diventato fortemente interattivo, grazie alla creazione delle piattaforme e delle applicazioni, che fanno ormai parte, della vita di tutti i giorni di ognuno di noi. Tuttavia, tale processo, ha mostrato agli sviluppatori, agli ingegneri e a chiunque lavorasse nell'ambito del networking, una serie di inadeguatezze cui la rete è soggetta, specialmente in vista di quello che potrebbe essere il passo successivo nella trasformazione di Internet e dunque, inevitabilmente, della vita di coloro che ne usufruiscono. Per far fronte alle problematiche postesi, quali ad esempio il crescente numero di dispositivi connessi alla rete (e di conseguenza al carico di lavoro dei server), o alla sempre più frequente presenza nella rete di dispositivi mobili, molti provvedimenti, sono già stati messi in atto, altrettanti invece, sono in cantiere o in attesa di essere standardizzati. Ad ogni modo, così come si è passati da un web prevalentemente statico, ad uno fortemente sociale, che basa le propria fondamenta sulla libertà di espressione e di condivisione (appunto il Web 2.0 ), allo stesso modo, si viaggia verso un nuovo web, in cui ogni oggetto possa essere connesso alla rete per sfruttarne le potenzialità, in cui l'utente possa vivere un'esperienza virtuale completa grazie alla realtà aumentata e alla semantica dei contenuti (solitamente indicato con Web 3.0 ). Tale elaborato, si propone dunque, di illustrare uno dei progetti in via di sviluppo più interessanti nell'ambito della mobilità e del multihoming, ovvero: Serval Architecture. 5

6 1 Serval Architecture 1.1 Problematiche arontate Un tempo, il web era popolato prevalentemente da dispositivi la cui mobilità era limitata ad un ambiente domestico o aziendale. La comunicazione avveniva dunque, tra singoli terminali che dicilmente avevano necessità di spostarsi. Oggigiorno, le cose sono profondamente cambiate. Infatti, sempre più spesso, un'altissima percentuale dei client che usufruiscono di un determinato servizio, sono dispositivi mobili con diverse interfacce di comunicazione (ad esempio, Wi-Fi e 3G/4G). Data la proliferazione degli abitanti del web, i provider, e in generale tutte le realtà che forniscono servizi online ad una copiosa utenza, hanno dovuto adeguare i propri organismi, passando ad architetture che prevedono numerosi server dislocati in tutto il globo. Tutto ciò ovviamente, si ripercuote sul funzionamento e sulla essibilità dei servizi. Lo stack TCP/IP, risulta essere inadeguato per quelli che sono i prossimi step nell'evoluzione della mobilità e della fruizione dei contenuti. Ad esempio, diverse sono le problematiche legate allo spostamento del usso di rete da un'interfaccia all'altra (si pensi ad esempio al fatto che, sul proprio smartphone, non si possa intercambiare Wi-Fi e 3G/4G in modo trasparente e senza interrompere le connessioni in corso), o all'utilizzo parallelo di più interfacce per lo stesso scopo (ad esempio, uno streaming in cui il download dei dati avviene in parallelo tra rete wireless e rete mobile). Per quanto riguarda invece la gestione dei server, si rende necessario un load balancer, in grado di distribuire nel miglior modo possibile il carico di lavoro tra i server, evitandone il sovraccarico. An application can run on multiple servers at dierent locations, and can launch at or migrate to a new machine at any time. In addition, user devices are often multi-homed (e.g., WiFi and 4G) and mobile. In short, modern services operate under unprecedented multiplicity (in service replicas, host interfaces, and network paths) and dynamism (due to replica failure and recovery, service migration, and client mobility). Yet, multiplicity and dynamism match poorly with today's host-centric TCP/IP-stack that binds connections to xed attachment points with topology-dependent addresses and conates service, ow, and network identiers. This forces online services to rely on clumsy and restrictive techniques that manipulate the network layer and constrain how services are composed, managed, and controlled. For example, today's load balancers repurpose IP addresses to refer to a group of (possibly changing) service instances; unfortunately, this requires all client trac to traverse the load balancer. Si veda [1, p. 1] per maggiori informazioni. 6

7 1.2 Cos'è Serval? Serval, è un progetto open source dell'università di Princeton, nato da un'idea di Michael J.Freedman, professore associato della facoltà di Informatica. Come spiegato precedentemente, le problematiche cui va incontro Internet, sono molteplici e rischiano di comprometterne un funzionamento ottimale in futuro. Per tale motivo, molti sono i progetti nati al ne di evitare che ciò accada. Serval è uno di questi: Freedman infatti, sostiene che ad oggi, gli ingegneri per poter implementare talune funzionalità, debbano ricorrere ad una serie di hack piuttosto complessi, che non sarebbero necessari risolvendo alla base le problematiche di cui sopra. Si veda [3]. Smart engineers are great at mastering complexity and hacking around it. But with the current approach, everybody needs to reinvent the wheel [...] Serval is something that will make things easier to build and easier to manage without relying on these hacks. Oltre Freedman, lavorano a Serval, anche Erik Nordstrom, David Shue, Prem Gopalan, Robert Kiefer, Matvey Arye, Steven Y.Ko e Jennifer Rexford. Il progetto, è stato nanziato da: National Science Fundation, DARPA, Oce of Naval Research e Cisco Systems. [4] La rete del futuro L'idea che sta alla base di Serval, vede l'utente, non più interessato al web come mezzo per interconnettersi ad uno specico terminale nella rete, ma piuttosto come tramite verso uno specico servizio. Si pensi ad esempio a realtà quali Google, che mettono a disposizione una moltitudine di servizi (Gmail, Maps, Drive etc.) dislocati su altrettanti server: un indirizzo IP, all'interno della rete, non può che rappresentare una specica macchina. Tale approccio, che prevede l'utilizzo dei load balancers sopracitati, risulta dunque fortemente limitativo in ambienti in cui, ogni funzionalità deve necessariamente essere dislocata su più server per far fronte al carico di lavoro. Inoltre, tutto ciò, impone dei vincoli in termini di mobilità degli host, i quali, non possono ad esempio migrare da una interfaccia all'altra, e dunque cambiare il proprio indirizzo IP, senza che la fruizione del servizio venga interrotta. Jennifer Rexfort, professoressa del dipartimento di Informatica, impegnata nello sviluppo di Serval, sostiene che (si veda [3]): A lot of applications can be rewritten to hide the fact that you break your connection and re-establish it, but it makes things unnecessarily complex and more expensive. The Internet is increasingly a platform for connecting mobile 7

8 users with the cloud and the Internet was not designed to do that [...] All the work that goes into shoehorning that into the old network architecture is very dicult Il concetto di Servizio Gli sviluppatori di Serval, hanno deciso di astrarre il concetto di servizio al punto da far sì che, l'utente, piuttosto che connettersi ad un indirizzo IP, e di conseguenza ad un terminale ben preciso, possa invece richiedere la connessione ad uno specico servizio, senza avere diretta visibilità dell'ip. Diamo allora una denizione più rigorosa di servizio [1, p. 1]: Un servizio, corrisponde ad un gruppo di sistemi, che orono le stesse funzionalità, disaccoppiando il servizio stesso, dagli identicatori di rete. Le applicazioni, possono instaurare una comunicazione senza badare ad indirizzo IP e porto. In altre parole: Service names identify who one communicates with, ow names identify what communication context to use, while addresses tell where to direct the communication. 8

9 1.3 Service Access Layer (SAL) Il cuore di Serval, è il Service Access Layer (di qui in poi SAL), che viene introdotto nello stack TCP/IP tra il livello rete e il livello trasporto. Lo scopo del SAL, è quello di realizzare l'astrazione di cui sopra e di mappare l'identicatore del servizio all'indirizzo IP corrispondente, mediante una service table, similmente a quel che avviene nel livello rete per le forwarding table. Tutto ciò senza nessuna ulteriore modica allo stack TCP/IP e senza che siano necessari ulteriori apparecchi di rete. Figura 1: Lo stack TCP/IP con e senza Serval. [1, Fig. 1] Installazione del SAL Il SAL, viene integrato all'interno del sistema operativo, mediante un modulo del Kernel Linux e/o Android, (in futuro gli sviluppatori prevedono di rendere il tutto compatibile con tutti i SO Unix-based nonché con i sistemi Windows) che può essere caricato e rimosso a tempo d'esecuzione mediante gli specici comandi da shell. Il codice sorgente necessario, può essere prelevato dall'apposita pagina del progetto su Github: Princeton-sns/Serval. Ovviamente, prima che sia possibile caricare il modulo del SAL, sarà necessario generarlo compilando il codice sorgente scaricato, mediante la tipica procedura certamente nota agli utilizzatori di un sistema operativo GNU/Linux. Per ogni dubbio, è possibile consultare la documentazione online (Serval Wiki) o i le README ed INSTALL all'interno del pacchetto contenente i sorgenti. Una volta caricato il modulo, sarà possibile far uso dei servizi messi a 9

10 disposizione da Serval ed avviare alcuni software di base (forniti all'interno dell'archivio disponibile su Github) per il testing delle funzionalità Funzionalità di base Uno degli scopi principali di Serval è quello di migliorare la mobilità delle connessioni (Mobility e Multihoming), che nell'approccio attuale risulta essere ineciente. In particolare, tramite l'astrazione realizzata dal SAL, Serval fa in modo che, non avendo le applicazioni visibilità in tutto e per tutto degli indirizzi IP, quest'ultimo possa variare senza interrompere il usso dati, nel passare da una rete all'altra o nel cambiare interfaccia di connessione. Figura 2: Mobility e multihoming. [2, Pag. 6] Oltre che per la mobilità dei client, Serval, prevede anche delle migliorie che possano invece interessare gli Internet Provider e più in generale i fornitori di servizi online. Attualmente, una architettura che prevede la distribuzione del carico di lavoro su più server, richiede l'utilizzo di terminali che si occupino di gestire le connessioni in entrata per indirizzarle in modo intelligente ad uno dei server disponibili. Tale approccio, fa sì che i load balancer, debbano gestire l'inoltro di tutti i pacchetti inviati dai client verso i server, cosa che, evidentemente, accresce la complessità ed il costo del sistema complessivo. Un simile approccio viene inoltre utilizzato per la risoluzione dei nomi tramite DNS, e di conseguenza presenta le stesse problematiche. 10

11 Figura 3: Approccio con load balancer. [2, Pag. 8] Serval gestisce tali situazioni, in modo diverso e sicuramente più eciente, e lo fa tramite i cosiddétti service routers, dei terminali che si occupano di instaurare il collegamento al servizio su richiesta del client, mediante un apposito pacchetto. Il traco successivamente generato, viaggia invece direttamente tra gli host implicati nella comunicazione (dierentemente da quando accade in presenza dei load balancer, che rischiano invece di essere sovraccaricati). Michael J.Freedman, spiega infatti che (si veda [4]): One can think of this as an overlay, but really, it means there is some software running on machines that act as service routers (much like DNS resolvers/nameservers or DHCP servers [...] These are only 'on-path' for the rst packet of each ow, unlike today's load balancers, which must be on-path for each packet. Inne, altra interessante miglioria, che potrebbe interessare in particolar modo i servizi di Cloud riguarda la migrazione delle macchine virtuali. Attualmente, qualora una organizzazione in possesso di diversi server, su ognuno dei quali sono in funzione più VM, abbia necessità di trasferirne una o più da un terminale ad un altro, dovrà necessariamente sospendere la comunicazione con i client che stavano interfacciandosi con la macchina in questione. 11

12 Figura 4: Migrazione VM tra diversi host. [2, Pag. 9] Tale inconveniente, potrebbe essere evitato se fosse possibile migrare le connessioni dei client implicati, verso altre VM. Ed è proprio in tal modo che Serval conta di risolvere tale problematica, oltre che riuscendo a diminuire il tempo di interruzione del servizio durante la migrazione della macchina. 12

13 2 Ripensare lo stack TCP/IP Le problematiche dello stack TCP/IP odierno, derivano prevalentemente dal fatto che, i concetti di indirizzo IP e porta, siano sovraccaricati dei più svariati signicati. Dierentemente, Serval, separa in modo netto il servizio dal usso dati corrispondente (relativo ad una specica socket) e dall'indirizzo di rete (che identica l'interfaccia dell'host). Di seguito sono riportati, per vari livelli dello stack, i cambiamenti che hanno luogo all'interno di quest'ultimi quando Serval è in funzione. Per maggiori informazioni, si veda [1, p. 2]. 2.1 Livello Applicazione Ad oggi, il livello applicativo, presenta le seguenti limitazioni: Indirizzo IP e port number, identicano solo in modo implicito il nome del servizio, che deve essere eventualmente risolto generando ulteriore traco (ad esempio tramite DNS), prima che la connessione possa aver luogo (early-binding). Le applicazioni utilizzano meccanismi di caching per velocizzare la risoluzione dei nomi, tuttavia, possono creare rallentamenti in caso di fallimento. Ogni socket, può essere legata al più ad un unico, immodicabile, indirizzo. In presenza del SAL, la necessità, all'interno delle applicazioni, di implementare alcuni meccanismi di risoluzione e di ottimizzazione della gestione del traco di rete, possono essere evitati o resi superui. In particolare, in termini di livello applicativo, l'introduzione del SAL comporta le seguenti migliorie: Grazie al concetto di servizio, attraverso il quale fa sì che l'ip sia trasparente alle applicazioni, è possibile risolvere l'indirizzo di rete, direttamente quando si instaura l'eettiva connessione tra gli host (late-binding). Tale questione è trattata in modo più approfondito nel paragrafo 4.1. In presenza di load balancer (ed eventualmente di NAT), la connessione può essere stabilita mediante l'invio di uno specico pacchetto (anycast-forwarded), senza che il restante traco debba attraversare il load balancer stesso. 13

14 2.2 Livello Trasporto Lo stack TCP/IP, a livello trasporto, fa uso della classica quintupla di elementi, formata da: IP mittente, porta mittente, IP destinatario, porta destinatario, protocollo. Tali informazioni, risultano necessarie per il demultiplexing dei pacchetti. In conseguenza di ciò, accade che: L'IP non può cambiare senza che le connessioni in corso siano interrotte; Le possibilità di mobilità e migrazione, sono pressoché nulle. Ad oggi, esistono diverse proposte per quanto riguarda l'integrazione della mobilità e del multihoming in TCP, ma nessuna ricopre tutti i possibili scenari in modo soddisfacente. Alcune soluzioni, prevedono che gli IP nella quintupla sopracitata possano cambiare dinamicamente, altre sostituiscono agli indirizzi altri identicatori, ma nessuna di queste soluzioni è in grado di supportare, oltre che TCP, altri protocolli di livello trasporto. Dierentemente, Serval, risolve il problema alla base, facendo sì che i protocolli di trasporto non si occupino del demultiplexing dei pacchetti, il quale ha luogo invece nel SAL grazie agli identicatori di servizio (serviceid) e di usso (owid). Così facendo, gli indirizzi di rete sono liberi di cambiare, e poiché il controllo del usso dati è relegato al SAL, tale soluzione può essere adottata con diversi protocolli di trasporto. 2.3 Livello Rete Dal momento che il SAL è posizionato al di sopra del livello rete, l'inoltro dei pacchetti, avviene così come previsto dal protocollo IP mediante una gestione gerarchica degli indirizzi. 14

15 3 Astrazione dei servizi e dei ussi 3.1 Service Naming Ogni servizio, è rappresentato da un nome di facile memorizzazione per gli utenti, e da un identicatore, che viene invece utilizzato dai dispositivi di rete e dai terminali, comunemente detto serviceid. Le istanze del servizio corrispondente, si aspettano dunque di ricevere in ingresso connessioni per quello specico identicatore, nascondendo ai client indirizzi e porti, garantendo dunque una certa essibilità. Seguendo la schematizzazione vista su [1, p. 3.1], è possibile discutere le seguenti caratteristiche: Granularità: Il concetto di servizio, realizza un'astrazione tale da nascondere l'eettiva tipologia del sistema complessivo, ad esempio: un service name può indierentemente rappresentare un singolo demone, un cluster di stampanti, un insieme di peer che distribuiscono lo stesso le o un normale servizio online distribuito su più macchine. In sostanza, la granularità del servizio è estranea ai client. Formato dell'identicatore: Di fondamentale importanza è la questione del naming. È necessario infatti, stabilire le dimensioni dei serviceid e decidere come questi debbano essere memorizzati. Gli sviluppatori di Serval, suggeriscono una soluzione che preveda un namespace di 256 bit, gestito eventualmente da autorità che si occupino della memorizzazione ed eventualmente di una suddivisione in blocchi, in base a dei pressi rappresentativi di speciche entità. È possibile in tal modo, adoperare una risoluzione gerarchica dei servizi, specialmente per quelle realtà che ne orono molteplici. Sicurezza e registrazione: Dal punto di vista della sicurezza, Serval, propone l'utilizzo di una bitstring alla ne del serviceid, ottenuta mediante crittograa hash di una chiave pubblica e del presso, rappresentativi del servizio. Tale meccanismo, non richiede la presenza di infrastrutture, ma soltanto una strategia per garantire che i serviceid vengano appresi attraverso canali sicuri e che la registrazione stessa dei servizi, avvenga mediante un sistema adabile di registrazione. Ad ogni modo, da questo punto di vista, Serval non impone alcuna politica di gestione dei serviceid, lasciando libere le imprese di scegliere come eettuare le registrazioni all'interno della propria rete. Tuttavia, va specicato che tali misure di sicurezza, non bastano ad assicurare che l'hoster del servizio sia autorizzato. Memorizzazione dei nomi: Anche per quanto riguarda questo aspetto, non vi è alcuna imposizione. Serval non si occupa di gestire 15

16 il mapping tra serviceid e service name, lasciando che sia l'utente a decidere come associare ad un identicatore un nome che possa essere facilmente memorizzato, mediante gli più svariati meccanismi (come accade ad esempio per DNS). 3.2 Flow Naming Serval fornisce un sistema di naming per il usso dati di una specica connessione, basato sul owid. Tramite tale identicatore, il SAL può eettuare il demultiplexing dei pacchetti, senza aver bisogno della classica quintupla di elementi di cui si è discusso nel paragrafo 3.2. In denitiva, il serviceid e il owid rappresentano tutto ciò che è necessario per l'inoltro dei pacchetti. Tali informazioni, vengono trasportate all'interno di uno specico header, posizionato tra quello del livello rete e quello del livello trasporto, come da immagine. Figura 5: Identicatori di Serval all'interno di un pacchetto (alcuni campi sono stati omessi per una migliore leggibilità). [1, Fig. 2] Possiamo quindi concludere che, come spiegato in [1, p. 3.2], Serval, tramite i suoi identicativi, implementa: Mobilità e multi-path: attraverso eventi che possano modicare l'interfaccia corrispondente ad un owid, o associando ad un'unica interfaccia più ussi che attraversino percorsi diversi. Inconsapevolezza del livello rete: i ussi dati sono identicati pur senza conoscere gli indirizzi IP corrispondenti, cosa che permette a Serval, di supportare indierentemente IPv4 e IPv6. Migrazione in presenza di NAT: un NAT consapevole della presenza del SAL, sostituisce l'indirizzo IP mittente, con l'ip pubblico (come di consueto) e il owid, unica informazione necessaria a destinazione per l'identicazione del usso dati corrispondente. In questo modo, può passare da una rete provvista di NAT all'altra, senza alcuna preoccupazione. 16

17 Sicurezza: dal momento che i owid possono essere generati casualmente, un identicatore sucientemente lungo, dovrebbe servire a proteggere da eventuali malintenzionati. Tuttavia, un owid troppo lungo, potrebbe generare un overhead eccessivo: per tale motivo, Serval adotta un owid di 32 bit più dei nonces che sono scambiati soltanto durante il setup della connessione e durante eventuali migrazioni. Port number non richiesto: il numero di porta, spesso identica anche il protocollo utilizzato per il usso dati verso l'applicazione (si pensi ad esempio al fatto che, il porto 80, è generalmente associato al protocollo HTTP). Il owid, invece, non tiene in alcun modo memoria del protocollo utilizzato, che può essere eventualmente specicato all'interno dell'apposito campo nel transport-header. 17

18 4 Inoltro dei pacchetti nello stack Serval Vedremo, nei paragra successivi, come Serval gestisce l'inoltro e il demultiplexing dei pacchetti all'interno delle reti, mediante i seguenti approcci e componenti: Scissione del control plane dal data plane; Service-controller, una componente che si occupa della risoluzione dei servizi, della gestione di particolari eventi, della comunicazione con gli altri controller; Service table che realizzano il mapping tra serviceid ed indirizzi di rete; Flow table che realizzano il mapping tra owid e socket; Meccanismi di comunicazione e segnalazione per la gestione di particolari eventi; Active socket per l'interazione tra le applicazioni. Figura 6: Stack Serval con le varie componenti che partecipano all'inoltro e alla gestione del traco. [1, Fig. 3] 18

19 4.1 Active Socket Le Active Socket, così come le socket BSD, su cui sono basate, vengono utilizzate per il passaggio dei dati da e verso le applicazioni, realizzando un'astrazione di un canale di comunicazione. Tali socket, si dierenziano da quelle classiche, per via del fatto che, le funzioni normalmente utilizzate per la gestione delle connessioni, hanno tra i parametri il serviceid, invece che gli indirizzi IP e il porto. Mediante un meccanismo di segnalazione eventi (si veda 4.4), Serval gestisce automaticamente la registrazione/deregistrazione dei servizi, quando vengono eseguite speciche operazioni sulle socket. Tipiche funzioni sono ad esempio: bind(): associa un indirizzo e un porto ad una socket (nel caso di Serval fa uso invece di un serviceid), su cui ci si pone in ascolto (l'evento generato da una chiamata alla funzione bind, causa una registrazione all'interno della service table che viene noticata al service-controller). close(): chiude la socket (causa una deregistrazione all'interno della service table che viene noticata al service-controller). connect(): chiamata utilizzata dai client per connettersi ad una speci- ca socket. accept(): accetta la prima connessione in coda. sendto(): invia i dati verso la specica destinazione. Figura 7: Dierenze d'utilizzo delle socket BSD classiche rispetto a quelle modicate da Serval per il funzionamento tramite serviceid. [1, Tab. 1] 19

20 Le applicazioni che fanno uso di tali funzioni, di conseguenza, non hanno visibilità dell'indirizzo di rete (dal momento che è il SAL ad occuparsi della risoluzione del serviceid nell'indirizzo corrispondente). Questo, non solo fa sì che gli IP possano cambiare liberamente, ma consente anche di eettuare il late binding, ovvero di mappare l'identicatore del servizio sul corrispondente indirizzo, solo all'atto di una connetct() o di una sendto(). 4.2 Forwarding e data plane L'instaurazione di una nuova connessione, mediante l'invio di uno specico pacchetto, comporta che venga eettuata una ricerca all'interno della service table dello specico serviceid contenuto all'interno dell'header Serval, mediante LPM (longest prex matching). Vari servizi infatti, possono avere lo stesso presso, poiché appartenenti alla stessa entità. Come è possibile notare guardando la Figura 6, la service table è composta da 3 campi, di cui il campo Action, il quale può assumere 4 diversi valori: FORWARD: viene utilizzato per l'inoltro di un pacchetto tramite il livello rete ad uno o più indirizzi. Sia il mittente, sia eventuali hop SAL intermedi o eventuali dispositivi di rete, presentano tuple all'interno della propria service table con ruolo impostato su FORWARD, contribuendo all'invio del pacchetto verso la specica destinazione. Tali hop, si comportano eettivamente come fossero dei service router. DEMUX: è il ruolo presente nella service table del destinatario, per poter smistare i pacchetti ricevuti verso la socket presso la quale la specica applicazione è in ascolto per quel serviceid. Una chiamata alla funzione bind() (si veda 4.1) fa sì che all'interno della service table, venga aggiunta una nuova voce con ruolo DEMUX per quel servizio, viceversa, una chiamata alla funzione close(), causa l'eliminazione della stessa. Figura 8: Aggiunta e rimozione di un ruolo DEMUX nella service table per il servizio X. [2, Pag ] 20

21 DELAY: un pacchetto il cui serviceid trova nella service table in sua corrispondenza una action DELAY, viene messo in coda ed una notica viene inviata al service controller. Tale ruolo, viene ad esempio utilizzato per una risoluzione ritardata (si veda 4.3). DROP: utilizzato semplicemente per scartare i pacchetti per uno speci- co servizio. Va specicato che, di default, ogni volta che un interfaccia si connette alla rete, un ruolo FORWARD viene inserito nella service table, cui corrisponde l'indirizzo di broadcast per l'interfaccia. Di seguito è illustrato un esempio di come avviene l'inoltro di un pacchetto: Figura 9: Inoltro di un pacchetto tra due terminali attraverso un service router intermedio. [1, Fig. 4] 1. Un client stabilisce una connessione per il servizio X, per il quale è presente nella service table un ruolo FORWARD verso il nodo b. 2. Il nodo intermedio, riceve il pacchetto; per lo specico serviceid ha nella sua service table un ruolo FORWARD. Il pacchetto viene dunque inoltrato verso il nodo g. 3. A destinazione, un ruolo DEMUX smista il pacchetto verso la socket sulla quale l'applicazione è in ascolto. Un esempio più complesso, è mostrato in Figura 10. Nell'esempio, un client richiede di poter usufruire di un servizio X, disponibile su due diversi server, allora il SAL assegna un owid ed un nonce generato casualmente (per proteggere da eventuali attacchi) alla socket corrispondente, ed una nuova tupla è aggiunta alla ow table. 21

22 Figura 10: Connessione ad un servizio X da parte del client a, tramite inoltro del pacchetto SYN. I ruoli indicato con ' * ' sono quelli di default. [1, Fig. 5] 1. Il SAL del client, cerca il serviceid all'interno della service table, ed inoltra la richiesta verso il nodo b (indicato come indirizzo per il ruolo FORWARD di default). 2. Il SR (service router) b, trova all'interno della propria service table, un ruolo FORWARD verso un ulteriore nodo, detto e. Reinoltra dunque il pacchetto sovrascrivendo l'indirizzo destinazione. 3. Il forwarding del pacchetto continua ricorsivamente attraverso il nodo e ed altri, nché non raggiunge il terminale g in ascolto sulla socket. 4. Il nodo g, crea quindi una nuova socket da utilizzare per l'invio della risposta al pacchetto SYN ricevuto, aggiornando la propria ow table. 5. Il pacchetto SYN-ACK generato da g, contiene il suo indirizzo di rete, il owid ed il nonce. Tale pacchetto, e tutti quelli che seguiranno, saranno scambiati in modo diretto tra i due host, senza che debbano attraversare i SR intermedi (b ed e). Va inoltre specicato, che il demultiplexing dei pacchetti successivi potrà essere eettuato pur senza l'invio del SAL header, essendo ormai noto il owid. 22

23 4.3 Service discovery e registration Al ne di poter gestire situazioni dierenti, Serval, supporta diverse modalità di registrazione e risoluzione dei servizi. Sono infatti i service controller a gestire le service table, ed eventualmente a propagarle verso altri service controller. È possibile distinguere diversi scenari: Risoluzione e routing in larga scala (wide-area): ogni qual volta una nuova istanza di un servizio è disponibile, il service controller si occupa di propagare l'informazione agli altri controller, permettendo così che il servizio possa essere raggiunto. Mediante l'utilizzo dei pressi, organizzazioni che forniscono molteplici servizi, possono organizzare i propri resolvers. Servizi nelle reti ad-hoc: essendo prive di infrastrutture di rete, le informazioni sui servizi devono essere propagate tramite ooding. Eventuali richieste vengono quindi inviate in broadcast, in attesa di risposte da istanze del servizio richiesto. Lato server, all'atto di una registrazione, il service controller può: inserire un ruolo DEMUX nella service table, propagare la registrazione agli altri controller (che potranno quindi installare nelle proprie service table un ruolo FOR- WARD). Viceversa, all'atto di una deregistrazione. Risoluzione con lookup server (on demand): come spiegato nel paragrafo 4.2, uno dei possibili ruoli per una tupla all'interno della service table, è DELAY. Tale ruolo, fa sì che i pacchetti corrispondenti al servizio, vengano messi in coda, in attesa ad esempio che il service controller si occupi della risoluzione. Una volta che tale risoluzione ha avuto luogo, i DELAY corrispondenti possono essere sostituiti con ruoli FORWARD per permettere l'inoltro dei pacchetti. Un approccio che prevede simili meccanismi, è quello con lookup server: i client interessati, inoltrano il pacchetto SYN verso il server in questione, il quale prima li mette in coda (DELAY) ed una volta eettuata la risoluzione, li inoltra (FORWARD) verso il servizio destinazione. 23

24 4.4 Meccanismi di segnalazione eventi I meccanismi di segnalazione, per la gestione di particolari eventi all'interno dello stack, sono fondamentali per garantire la essibilità e il dinamismo messi a disposizione dal SAL, in particolar modo per una corretta gestione della mobilità e della migrazione in presenza di più ussi dati. I protocolli utilizzati in Serval, si dierenziano dai classici meccanismi solitamente adottati in TCP. Prima di tutto, i messaggi di controllo viaggiano separati dai dati ed hanno un proprio sequence number, cosa che non accade ad esempio nei più comuni MPTCP e TCP Migrate, i quali possono inviare messaggi di controllo solo all'interno dei pacchetti dati, inoltre diversi protocolli di trasporto sono supportati grazie alla presenza del SAL che gestisce i ussi dati ad un livello più basso, e per lo stesso motivo migrazione e ussi multipli sono ammissibili. Per maggiori informazioni si veda [1, p. 4.4]. Per meglio illustrare le possibilità messe a disposizione da Serval, in termini di multihoming, multipath e migrazione, si faccia riferimento all'esempio riportato nella gura sottostante: Figura 11: Esempio di comunicazione multipath (con possibilità di migrazione) in presenza di terminali multihomed. [1, Fig. 6] Multipath e multihoming: in presenza di diverse interfacce di rete, possono essere instaurati più ussi dati lungo percorsi diversi. Si faccia riferimento all'esempio di Figura 11: i due host, posseggono ambedue una coppia di interfacce (a1 e a2 per il client Host C, a3 e a4 per server Host S). Il primo usso viene instaurato quando il client richiede di connettersi, usando ad esempio l'interfaccia a1 con owid fc1, che lato server corrispondono all'interfaccia a3 con owid fs1. Ogni qual volta viene inviato un pacchetto, all'interno del SAL extension header, gli host possono indicare eventuali altre interfacce disponibili per la connessione per dare la possibilità di creare più ussi dati. In questo caso ad esempio, qualora Host S lo segnali ad Host C, quest'ultimo potrebbe decidere di instaurare una nuova connessione tra le interfacce a2 e a4. 24

25 Migrazione: essendo il livello trasporto ignaro della gestione del owid da parte del SAL, è possibile migrare ussi dati da una interfaccia all'altra, su percorsi diversi o verso un altro indirizzo. Ovviamente, eventuali migrazioni possono inuire sulle prestazioni, e ridurre la banda a disposizione per il trasferimento dati. Per questo motivo, il SAL può noticare a livello trasporto l'avvio di una migrazione, così che questa possa essere gestita in modo adeguato. Facendo riferimento all'esempio di Figura 11, immaginiamo che improvvisamente l'interfaccia a3 del server smetta di funzionare. Per non interrompere la connessione, il server può migrare il usso dati su un'altra interfaccia, ad esempio a4. Tale migrazione avviene mediante l'invio da parte del server, di un pacchetto di risincronizzazione detto RSYN, contenente i owid della connessione corrente (fc1 e fs1) nonché l'indirizzo della nuova interfaccia (a4). Il client invia quindi un RSYN-ACK per noticare al server il proprio assenso alla migrazione, ed attende un ulteriore conferma da parte di quest'ultimo. La presenza di un sequence number all'interno dei pacchetti di sincronizzazione, assicura che questa vada a buon ne anche nel caso in cui arrivino fuori ordine (eventualità rara ma possibile). 25

26 5 Prototipo dell'architettura Attraverso la prototipazione dell'architettura, gli sviluppatori, si sono resi conto man mano di quelle che sono le potenzialità di Serval e i beneci che può apportare in termini di dinamicità, prestazioni e quant'altro. Attualmente, il prototipo disponibile, supporta: migrazione, SAL forwarding (comprensivo di service table con ruoli FORWARD e DEMUX, risoluzione dei servizi e meccanismi di segnalazione) ed altre funzionalità. Tuttavia, non è ancora possibile far uso del multi-path, che gli sviluppatori progettano di aggiungere in futuro. Inoltre, la presenza del service controller (che interagisce a sua volta con lo stack mediante una particolare socket), permette una gestione dinamica delle service table in presenza delle chiamate a funzioni bind(), connect() etc. Attualmente sono supportati i protocolli di livello trasporto TCP e UDP. Per maggiori informazioni su come Serval sia giunto all'architettura attuale attraverso le varie prototipazioni susseguitesi, si veda [1, p. 5.1]. 5.1 Benchmark performance Gli sviluppatori di Serval, si sono preoccupati dell'esecuzione di alcuni test che mostrassero in termini di throughput, pacchetti inviati, data loss, deviazione standard, le prestazioni di uno stack modicato dal SAL, rispetto ad un classico TCP/IP. Figura 12: Statistiche di confronto tra connessioni tramite stack TCP/IP nativo e con SAL. [1, Tab. 2] I dati mostrati, sono relativi a test di 10 secondi, eseguiti mediante tool iperf su macchine con 2 CPU Intel 2.4GHz ed interfaccia GigE con sistema operativo Ubuntu Si consideri nel valutare i risultati ottenuti da Serval, che alcune ottimizzazioni non sono ancora implementate. Sono inoltre riportati nella tabella in Figura 12, i risultati in presenza di un translator, ovvero una componente che si occupa del rendere possibile una comunicazione tra host che implementano l'architettura Serval ed host che fanno uso del classico stack TCP/IP (si veda il paragrafo 7). 26

27 La seconda parte della tabella in Figura 12, mostra i risultati ottenuti nell'inoltro di alcuni pacchetti con payload da 48 byte gestiti dal SAL, rispetto ad altri inviati con l'approccio attuale previsto da IP. Gli sviluppatori condano di poter colmare il divario presente, specialmente in termini di packet-rate, con le future ottimizzazioni. 6 Casi di studio Per dimostrare l'ecacia di Serval in una serie di casi possibili, gli sviluppatori hanno realizzato dei test su sistemi realmente funzionanti, di svariati tipi. Di seguito sono riportati i risultati ed una serie di considerazioni derivanti da tali test, per diversi utilizzi di Serval in ambito server. 6.1 Web Service replicato con load balancing In questo esperimento, si fa uso di un web-cluster con architettura Serval, per mostrare i vantaggi che quest'ultimo può apportare all'interno di una simile architettura. Supponiamo, che 4 client invino richieste verso il web service, il quale gira su diverse istanze di un web server Mongoose. Tutti gli host, sono connessi allo stesso switch di rete ToR GigE. Il load balancing, è a carico di un singolo service router, che si occupa della risoluzione delle richieste. Per illustrare i risultati ottenuti, si faccia riferimento alla seguente immagine, considerando che ogni client richiede un le di 3MB su una nestra di 20 richieste HTTP, al ne di saturare la banda a disposizione. Figura 13: Relazione tra request rate e throughput in presenza di più istanze di servizio. [1, Fig. 7] 27

28 Distinguiamo situazioni dierenti, in base alle istanze del servizio disponibili, in particolare: 0-60 secondi: due istante di servizio servono un totale di 80 richieste al secondo (20 per client), raggiungendo un throughput di circa 1.8Gbps; secondi: dopo 60 secondi, due nuove istanze di servizio si registrano presso il service router, ed iniziano a servire richieste. Si ottiene così un request rate di 160 req/s ed un throughput di circa 3.6Gbps; secondi: le prime due istanze di servizio, vengono stoppate. Dunque, eseguono la deregistrazione e servono le ultime richieste pendenti. I risultati ottenuti in termini di request rate e throughput sono comparabili a quelli ottenuti nei primi 60 secondi (avendo lo stesso numero di istanze attive); secondi: una terza istanza viene avviata su uno dei server disponibili, ottenendo così migliori prestazioni (120 req/s e 2.7Gbps). Dall'esperimento si capisce dunque, come Serval sia in grado di gestire senza l'uso di un costoso load balancer, un notevole carico di richieste riuscendo a distribuirle in modo adeguato sui server disponibili ed ottenendo ottimi risultati in termini di throughput e request rate (tali da saturare la banda disponibile). Il tutto, ricordando che il service router, non è altro che un nodo coinvolto nella sola registrazione e risoluzione dei servizi (attraversato unicamente dal primo pacchetto di una connessione e non dall'interno traco generato dal trasferimento dei dati). 6.2 Storage distribuito Si illustra di seguito, l'impiego di Serval in un sistema di storage basato su Memcached. Memcached fornisce un servizio di caching, basato sull'utilizzo di alcune chiavi, tramite le quali un algoritmo di risoluzione, fa corrispondere speciche partizioni distribuite su più server. Tramite una mappa, il client può individuare il server contenente la partizione di interesse, ed inviare ad esso le sue richieste. Tuttavia, la staticità di questo approccio, complica la gestione dei server quando se ne vogliano aggiungere o sottrarre, o nel caso in cui si voglia ripartizionare lo spazio. Con Serval, il mapping delle partizione può avvenire dinamicamente: i client possono inoltrare le proprie richieste al service router indicando un serviceid con presso comune a Memcached, seguito dalla chiave del contenuto. Il mapping tra il serviceid e la partizione corrispondente alla chiave, avviene mediante LPM nella service table. Le richieste possono quindi essere 28

29 inoltrate verso il server, il quale di qui in poi, comunicherà in modo diretto col client. Nel caso in cui un nuovo server si registri alla rete, le partizioni possono essere semplicemente riassegnate modicando la service table, tuttavia, con tale approccio, non avendo i client visibilità diretta del server (ma solo del servizio) non possono aggregare richieste (si richiede che sia il service router ad occuparsene). L'immagine sottostante, riporta i risultati ottenuti per l'esperimento, in presenza di 4 server ed un client (con un service router intermedio). Il client ed il service router sono su macchine con le stesse speciche indicate per i benchmark del paragrafo 5.1, mentre i server hanno le seguenti speciche: due CPU AMD Opteron 2.4GHz quad-core con interfaccia GigE. Il service router, assegna un totale di 16 partizioni (4 per ogni server), le cui chiavi sono codicate sugli ultimi 4 bit del presso del serviceid. Figura 14: Gestione Serval delle partizioni sotto Memcached, in presenza di 4 server. [1, Fig. 8] Anche in questo caso, come nell'esperimento precedente, distinguiamo diverse situazioni in base ai server disponibili nei vari intervalli di tempo: 0-10 secondi: inizialmente, tutti i server sono in funzione; secondi: dopo circa 10 secondi, un server viene rimosso (server 3) ed il service router ridistribuisce le 4 partizioni del server rimosso tra quelli rimanenti; secondi: dopo 20 secondi, un altro server viene rimosso (server 2) e le partizioni corrispondenti distribuite sui due server rimanenti; 29

30 30-40 secondi: il server 3, si registra nuovamente alla rete dopo circa 30 secondi, il carico dovuto alla gestione delle partizioni viene ridistribuito; secondi: il server 4 si registra nuovamente, e si torna alla situazione iniziale. 6.3 Migrazione ussi e macchine virtuali Nel seguito, sono illustrati in breve, esperimenti che mostrano come Serval possa gestire la migrazione di ussi dati su diverse interfacce, o di vere e proprie macchine virtuali, situazione particolarmente di interesse ad esempio per i servizi di cloud. Nel primo caso, abbiamo un server (sul quale è lanciato iperf) con due interfacce di rete GigE, che serve due client. Tali interfacce, possono garantire una velocità a piena banda, di 1Gbps. Figura 15: Miglioramenti in termini di throughput dovuti alla migrazione del usso dati del secondo client sulla seconda interfaccia. [1, Fig. 9] Inizialmente, i ussi di entrambi i client sono diretti verso un'unica interfaccia server, raggiungendo una velocità di circa 500Mbps (e dunque in totale di 1Gbps). Dopo 6 secondi, il service controller segnala al SAL di voler migrare uno dei ussi sulla seconda interfaccia. Trascorso un breve periodo, necessario per l'assestamento della velocità di trasmissione, entrambi i client ottengono una velocità pari a 1Gbps (2Gbps totali), raddoppiando dunque il throughput rispetto alla situazione iniziale. 30

31 Un possibile uso della migrazione oerta da Serval, utile in particolar modo a fornitori di servizi cloud, è quello in cui una macchina virtuale, debba essere trasferita da un host all'altro senza una interruzione del usso dati. Figura 16: Flusso dati, in presenza di una migrazione. [1, Fig. 10] Come l'immagine suggerisce, il usso dati subisce un lieve rallentamento ed una breve interruzione, nel periodo in cui un nuovo indirizzo di rete viene assegnato alla macchina virtuale, e mentre viene eettuata la risincronizzazione. 31

32 7 Translator per compatibilità con host legacy L'integrazione di Serval all'interno dello stack TCP/IP, risulta essere piuttosto semplice, tuttavia, per ovvi motivi, è necessario garantire compatibilità anche con host che presentano uno stack privo del SAL. Per questo motivo, sono stati sviluppati dei translators, attraverso i quali è possibile risolvere tale problematica. In particolar modo, il translator TCP-to-Serval, può tradurre una normale connessione basata su TCP (senza SAL), in una connessione adatta ad essere gestita da uno stack Serval. Un translator Serval-to-TCP, eettua invece l'operazione inversa. [1, p. 7] - [5, p. 3.1] TCP-to-Serval (lato client): per poter eettuare la traduzione, il translator (che in questo caso è un middlebox lato client) ha bisogno di conoscere quale servizio il client desidera utilizzare, e di ricevere i pacchetti relativi al usso dati associato. Il translator, agisce non molto dierentemente da un recursive DNS, utilizzando i nomi dei domini cui il client desidera connettersi, come nomi del servizio richiesto. Il translator, mappa quindi tali nomi su un indirizzo IP privato. TCP-to-Serval (lato server): alcune grandi organizzazioni, che permettono la fruizione di una molteplicità di servizi, potrebbero pensare di implementare un proprio translator, presso i propri PoP (Points of presence). Tale approccio, prevede una architettura siatta: Figura 17: Comunicazione client-server mediante translator lato server. Solo il primo pacchetto attraversa il service router, i restanti solo il translator. [5, Fig. 2] In una situazione simile, il client ovviamente non conosce il serviceid, ma piuttosto risolve tramite DNS l'indirizzo IP di una specica macchina. Ogni server che permette l'utilizzo del servizio è associato ad un IP pubblico e ad una porta. Tuttavia, l'ip che il client scopre, non 32

33 corrisponde ad una delle macchine del servizio, bensì al translator. Quest'ultimo, riceve dunque tutto il traco generato dalle richieste dei client, e tramite una tabella mappa l'ip e la porta richiesti dal client sul corretto serviceid, come mostrato nell'immagine sottostante. Figura 18: Tabella per il mapping di IP e porta sul corretto serviceid. [5, Fig. 1] Riconosciuto il serviceid corretto, il translator, invia una richiesta di connessione mediante Serval, al service router della rete. Il service router a sua volta, decide per quale server della rete stabilire la connessione. Una volta stabilita la connessione, i pacchetti successivi, potranno essere trasferiti senza attraversare il service router, mentre dovranno sempre essere gestiti dal translator, il quale mantiene una connessione classica verso il client ed una basata su Serval, verso il server che fornisce il servizio. Per le strategie di realizzazione di un translator, si veda [5, p. 4]. Serval-to-TCP/UDP: un translator di questo tipo, funziona in modo molto simile a quanto visto per il TCP-to-Serval. È piuttosto interessante valutare la possibilità di utilizzare una coppia di translator in serie, al ne di poter usufruire delle funzionalità messe a disposizione da uno stack Serval, ad esempio: si immagini un client privo di SAL, che stabilisca una connessione verso una specica destinazione. I pacchetti inviati, attraversano prima un translator TCP-to-Serval e poi un translator Serval-to-TCP, al ne di inoltrare a destinazione pacchetti mediante una connessione legacy. Così facendo, pur essendo il client un dispositivo non modicato, potrà usufruire dei vantaggi tipici dell'architettura Serval, grazie alla presenza dei translator. 33

34 8 Dimostrazioni e test di funzionamento Di seguito, sono riportati alcuni esempi e test dimostrativi eettuati, al ne di mostrare il funzionamento di Serval in alcuni scenari d'uso comune. Tutte le istruzioni riportare, fanno chiaramente riferimento a le generati tramite il processo di compilazione, primo passo da eseguire, così come accennato nel paragrafo (si consiglia ad ogni modo di far riferimento alla pagina Serval su Github e al relativo Wiki). I comandi vengono lanciati dall'interno della directory principale di Serval, comunemente chiamate servalmaster. Serval, può essere avviato in due dierenti modalità: come modulo del Kernel Linux, o in user-space. Tutti gli esempi riportati di seguito, sono stati eseguiti lanciando Serval in user-space. Avvio di Serval tramite caricamento del modulo nel Kernel: # insmod./src/stack/serval.ko Per controllare che il modulo sia stato eettivamente caricato: $ lsmod grep serval Avvio di Serval in user-space: #./src/stack/serval -i INTERFACCIA -d Una lista delle interfacce disponibili si può ottenere lanciando ifcong. L'opzione d, lancia Serval in background, come demone. Serval fornisce anche un demone (il cui uso è opzionale), detto servd, utile alla gestione degli eventi, poiché segnala registrazioni e deregistrazioni dei servizi al service router di competenza. È possibile specicare alcune opzioni per servd, creando il le /usr/local/etc/servd.conf. Per lanciare il demone: #./src/servd/servd L'opzione -rip può essere specicata per indicare esplicitamente l'ip del service router (che servd trova da solo qualora sia nella stessa sottorete, diversamente è necessario indicarlo in modo esplicito). Per maggiori informazioni, si lanci servd -h. 34

35 Una volta avviato il demone, è possibile visualizzare service e ow table, lanciando: $ telnet Figura 19: Service e ow table, visualizzate tramite telnet. Prima di iniziare, potrebbe essere utile aggiungere una entry d'esempio nella service table per il serviceid 76568: $./src/tools/serv service add IP_SERVER 8.1 Catturare pacchetti Serval con Wireshark Di base, Wireshark, noto programma per l'analisi del traco di rete, non è in grado di individuare all'interno dei pacchetti il SAL (e dunque header ed estensioni realtive). Tuttavia, è possibile istruire Wireshark anché sia in grado di individuare correttamente pacchetti Serval. Per farlo, è necessario un dissector. Un dissector non è altro che uno script, programmato in LUA, contenente le direttive necessarie per la corretta decodica di talune caratteristiche dei pacchetti nel traco di rete. Per maggiori informazioni, si veda [6]. Un dissector attraverso il quale è possibile decodicare correttamente pacchetti Serval, è stato realizzato da Isaakidis Marios (misaakidis) nell'ambito del suo progetto ServalDHT e distribuito sotto licenza GNU General Public License. Il le.lua, è disponibile tra i le del progetto sotto la directory: serval/src/serval_wireshark_dissector.lua Scaricato il le, è necessario istruire Wireshark anché ne faccia uso per la decodica dei pacchetti. Wireshark, all'avvio, carica alcuni script in base alle direttive che sono contenute nel le init.lua, dunque, per far uso del dissector, si lancino si seguenti comandi: 35

36 # cp serval_wireshark_dissector.lua /usr/share/wireshark # nano /usr/share/wireshark/init.lua Inserire alla ne del le la direttiva: dofile(data_dir.."serval_wireshark_dissector.lua") Wireshark, sarà adesso in grado di individuare il SAL. In alternativa, si faccia uso di tshark (la versione a riga di comando di Wireshark). Il comando da eseguire per catturare pacchetti Serval è il seguente: $ tshark -i INTERFACCIA -X lua_script:serval_wireshark_dissector.lua Come mostra la gura seguente, Wireshark individua correttamente il SAL. Figura 20: Pacchetto Serval individuato da Wireshark. 36

37 8.2 Invio di un le Serval, mette a disposizione una serie di semplici programmi di test, al ne di vericare il corretto funzionamento di talune funzionalità. In questo esempio, verrà mostrato come, degli host Serval, possano scambiarsi un le come se questo fosse fornito dal servizio. Si noti che, qualora i due host si trovino in sottoreti diverse, sarà necessario aggiungere nella service table, una entry che indichi presso quale indirizzo raggiungere il servizio relativo al serviceid indicato. Supponendo di voler inviare un le.jpg contenuto nella cartella Immagini di nome dark_side.jpg, lato server si lanci: $./src/test/tcp_server_user -s f /home/user/immagini/dark_side.jpg Lato client invece, si può scaricare il le mediante il seguente comando: $./src/test/tcp_client_user -s f /home/user/scrivania/serval_test.jpg Figura 21: Invio di un le tramite stack Serval. 37

Elementi di Informatica e Programmazione

Elementi di Informatica e Programmazione Elementi di Informatica e Programmazione Le Reti di Calcolatori (parte 2) Corsi di Laurea in: Ingegneria Civile Ingegneria per l Ambiente e il Territorio Università degli Studi di Brescia Docente: Daniela

Dettagli

12.5 UDP (User Datagram Protocol)

12.5 UDP (User Datagram Protocol) CAPITOLO 12. SUITE DI PROTOCOLLI TCP/IP 88 12.5 UDP (User Datagram Protocol) L UDP (User Datagram Protocol) é uno dei due protocolli del livello di trasporto. Come l IP, é un protocollo inaffidabile, che

Dettagli

Informatica per la comunicazione" - lezione 9 -

Informatica per la comunicazione - lezione 9 - Informatica per la comunicazione" - lezione 9 - Protocolli di livello intermedio:" TCP/IP" IP: Internet Protocol" E il protocollo che viene seguito per trasmettere un pacchetto da un host a un altro, in

Dettagli

DNS (Domain Name System) Gruppo Linux

DNS (Domain Name System) Gruppo Linux DNS (Domain Name System) Gruppo Linux Luca Sozio Matteo Giordano Vincenzo Sgaramella Enrico Palmerini DNS (Domain Name System) Ci sono due modi per identificare un host nella rete: - Attraverso un hostname

Dettagli

Prova di Esame - Rete Internet (ing. Giovanni Neglia) Prova completa Mercoledì 2 Marzo 2005, ore 14.30

Prova di Esame - Rete Internet (ing. Giovanni Neglia) Prova completa Mercoledì 2 Marzo 2005, ore 14.30 Prova di Esame - Rete Internet (ing. Giovanni Neglia) Prova completa Mercoledì 2 Marzo 2005, ore 14.30 NB: alcune domande hanno risposta multipla: si richiede di identificare TUTTE le risposte corrette.

Dettagli

Modello OSI e architettura TCP/IP

Modello OSI e architettura TCP/IP Modello OSI e architettura TCP/IP Differenza tra modello e architettura - Modello: è puramente teorico, definisce relazioni e caratteristiche dei livelli ma non i protocolli effettivi - Architettura: è

Dettagli

UBUNTU SERVER. Installazione e configurazione di Ubuntu Server. M. Cesa 1

UBUNTU SERVER. Installazione e configurazione di Ubuntu Server. M. Cesa 1 UBUNTU SERVER Installazione e configurazione di Ubuntu Server M. Cesa 1 Ubuntu Server Scaricare la versione deisiderata dalla pagina ufficiale http://www.ubuntu.com/getubuntu/download-server Selezioniare

Dettagli

Firewall. Generalità. Un firewall può essere sia un apparato hardware sia un programma software.

Firewall. Generalità. Un firewall può essere sia un apparato hardware sia un programma software. Generalità Definizione Un firewall è un sistema che protegge i computer connessi in rete da attacchi intenzionali mirati a compromettere il funzionamento del sistema, alterare i dati ivi memorizzati, accedere

Dettagli

Introduzione alle applicazioni di rete

Introduzione alle applicazioni di rete Introduzione alle applicazioni di rete Definizioni base Modelli client-server e peer-to-peer Socket API Scelta del tipo di servizio Indirizzamento dei processi Identificazione di un servizio Concorrenza

Dettagli

Mod. 4: L architettura TCP/ IP Classe 5 I ITIS G. Ferraris a.s. 2011 / 2012 Marcianise (CE) Prof. M. Simone

Mod. 4: L architettura TCP/ IP Classe 5 I ITIS G. Ferraris a.s. 2011 / 2012 Marcianise (CE) Prof. M. Simone Paragrafo 1 Prerequisiti Definizione di applicazione server Essa è un servizio che è in esecuzione su un server 1 al fine di essere disponibile per tutti gli host che lo richiedono. Esempi sono: il servizio

Dettagli

CARATTERISTICHE DELLE CRYPTO BOX

CARATTERISTICHE DELLE CRYPTO BOX Secure Stream PANORAMICA Il sistema Secure Stream è costituito da due appliance (Crypto BOX) in grado di stabilire tra loro un collegamento sicuro. Le Crypto BOX sono dei veri e propri router in grado

Dettagli

VIRTUALIZE IT. www.digibyte.it - digibyte@digibyte.it

VIRTUALIZE IT. www.digibyte.it - digibyte@digibyte.it il server? virtualizzalo!! Se ti stai domandando: ma cosa stanno dicendo? ancora non sai che la virtualizzazione è una tecnologia software, oggi ormai consolidata, che sta progressivamente modificando

Dettagli

Intrusion Detection System

Intrusion Detection System Capitolo 12 Intrusion Detection System I meccanismi per la gestione degli attacchi si dividono fra: meccanismi di prevenzione; meccanismi di rilevazione; meccanismi di tolleranza (recovery). In questo

Dettagli

Zeroshell come client OpenVPN

Zeroshell come client OpenVPN Zeroshell come client OpenVPN (di un server OpenVpn Linux) Le funzionalità di stabilire connessioni VPN di Zeroshell vede come scenario solito Zeroshell sia come client sia come server e per scelta architetturale,

Dettagli

Cos è un protocollo? Ciao. Ciao 2:00. tempo. Un protocollo umano e un protocollo di reti di computer:

Cos è un protocollo? Ciao. Ciao 2:00. <file> tempo. Un protocollo umano e un protocollo di reti di computer: Cos è un protocollo? Un protocollo umano e un protocollo di reti di computer: Ciao Ciao Hai l ora? 2:00 tempo TCP connection request TCP connection reply. Get http://www.di.unito.it/index.htm Domanda:

Dettagli

SubnetMask: come funzionano e come si calcolano le sottoreti (SpySystem.it)

SubnetMask: come funzionano e come si calcolano le sottoreti (SpySystem.it) SubnetMask: come funzionano e come si calcolano le sottoreti (SpySystem.it) In una rete TCP/IP, se un computer (A) deve inoltrare una richiesta ad un altro computer (B) attraverso la rete locale, lo dovrà

Dettagli

RETI DI CALCOLATORI E APPLICAZIONI TELEMATICHE

RETI DI CALCOLATORI E APPLICAZIONI TELEMATICHE RETI DI CALCOLATORI E APPLICAZIONI TELEMATICHE Prof. PIER LUCA MONTESSORO Facoltà di Ingegneria Università degli Studi di Udine 1999 Pier Luca Montessoro (si veda la nota a pagina 2) 1 Nota di Copyright

Dettagli

Routing (instradamento) in Internet. Internet globalmente consiste di Sistemi Autonomi (AS) interconnessi:

Routing (instradamento) in Internet. Internet globalmente consiste di Sistemi Autonomi (AS) interconnessi: Routing (instradamento) in Internet Internet globalmente consiste di Sistemi Autonomi (AS) interconnessi: Stub AS: istituzione piccola Multihomed AS: grande istituzione (nessun ( transito Transit AS: provider

Dettagli

Luca Mari, Sistemi informativi applicati (reti di calcolatori) appunti delle lezioni. Architetture client/server: applicazioni client

Luca Mari, Sistemi informativi applicati (reti di calcolatori) appunti delle lezioni. Architetture client/server: applicazioni client Versione 25.4.05 Sistemi informativi applicati (reti di calcolatori): appunti delle lezioni Architetture client/server: applicazioni client 1 Architetture client/server: un esempio World wide web è un

Dettagli

Inizializzazione degli Host. BOOTP e DHCP

Inizializzazione degli Host. BOOTP e DHCP BOOTP e DHCP a.a. 2002/03 Prof. Vincenzo Auletta auletta@dia.unisa.it http://www.dia.unisa.it/~auletta/ Università degli studi di Salerno Laurea e Diploma in Informatica 1 Inizializzazione degli Host Un

Dettagli

J+... J+3 J+2 J+1 K+1 K+2 K+3 K+...

J+... J+3 J+2 J+1 K+1 K+2 K+3 K+... Setup delle ConnessioniTCP Una connessione TCP viene instaurata con le seguenti fasi, che formano il Three-Way Handshake (perchè formato da almeno 3 pacchetti trasmessi): 1) il server si predispone ad

Dettagli

Symbolic. Ambiti Operativi. Presente sul mercato da circa 10 anni Specializzata in Network Security Partner e distributore italiano di F-Secure Corp.

Symbolic. Ambiti Operativi. Presente sul mercato da circa 10 anni Specializzata in Network Security Partner e distributore italiano di F-Secure Corp. Symbolic Presente sul mercato da circa 10 anni Specializzata in Network Security Partner e distributore italiano di F-Secure Corp. La nostra mission è di rendere disponibili soluzioni avanzate per la sicurezza

Dettagli

Modulo 11. Il livello trasporto ed il protocollo TCP Indice

Modulo 11. Il livello trasporto ed il protocollo TCP Indice Pagina 1 di 14 Il livello trasporto ed il protocollo TCP Indice servizi del livello trasporto multiplexing/demultiplexing trasporto senza connesione: UDP principi del trasferimento dati affidabile trasporto

Dettagli

CHIAVETTA INTERNET ONDA MT503HSA

CHIAVETTA INTERNET ONDA MT503HSA CHIAVETTA INTERNET ONDA MT503HSA Manuale Utente Linux Debian, Fedora, Ubuntu www.ondacommunication.com Chiavet ta Internet MT503HSA Guida rapida sistema operativo LINUX V 1.1 33080, Roveredo in Piano (PN)

Dettagli

Configuration Managment Configurare EC2 su AWS. Tutorial. Configuration Managment. Configurare il servizio EC2 su AWS. Pagina 1

Configuration Managment Configurare EC2 su AWS. Tutorial. Configuration Managment. Configurare il servizio EC2 su AWS. Pagina 1 Tutorial Configuration Managment Configurare il servizio EC2 su AWS Pagina 1 Sommario 1. INTRODUZIONE... 3 2. PROGRAMMI NECESSARI... 4 3. PANNELLO DI CONTROLLO... 5 4. CONFIGURARE E LANCIARE UN ISTANZA...

Dettagli

Guida all'installazione ed uso dell'app RXCamLink

Guida all'installazione ed uso dell'app RXCamLink Guida all'installazione ed uso dell'app RXCamLink Questa guida riporta i passi relativi all'installazione ed all'utilizzo dell'app "RxCamLink" per il collegamento remoto in mobilità a sistemi TVCC basati

Dettagli

Le Reti Informatiche

Le Reti Informatiche Le Reti Informatiche modulo 10 Prof. Salvatore Rosta www.byteman.it s.rosta@byteman.it 1 Nomenclatura: 1 La rappresentazione di uno schema richiede una serie di abbreviazioni per i vari componenti. Seguiremo

Dettagli

Sizing di un infrastruttura server con VMware

Sizing di un infrastruttura server con VMware Sizing di un infrastruttura server con VMware v1.1 Matteo Cappelli Vediamo una serie di best practices per progettare e dimensionare un infrastruttura di server virtuali con VMware vsphere 5.0. Innanzitutto

Dettagli

INTERNET e RETI di CALCOLATORI A.A. 2014/2015 Capitolo 4 DHCP Dynamic Host Configuration Protocol Fausto Marcantoni fausto.marcantoni@unicam.

INTERNET e RETI di CALCOLATORI A.A. 2014/2015 Capitolo 4 DHCP Dynamic Host Configuration Protocol Fausto Marcantoni fausto.marcantoni@unicam. Laurea in INFORMATICA INTERNET e RETI di CALCOLATORI A.A. 2014/2015 Capitolo 4 Dynamic Host Configuration Protocol fausto.marcantoni@unicam.it Prima di iniziare... Gli indirizzi IP privati possono essere

Dettagli

Analisi dei requisiti e casi d uso

Analisi dei requisiti e casi d uso Analisi dei requisiti e casi d uso Indice 1 Introduzione 2 1.1 Terminologia........................... 2 2 Modello della Web Application 5 3 Struttura della web Application 6 4 Casi di utilizzo della Web

Dettagli

La configurazione degli indirizzi IP. Configurazione statica, con DHCP, e stateless

La configurazione degli indirizzi IP. Configurazione statica, con DHCP, e stateless La configurazione degli indirizzi IP Configurazione statica, con DHCP, e stateless 1 Parametri essenziali per una stazione IP Parametri obbligatori Indirizzo IP Netmask Parametri formalmente non obbligatori,

Dettagli

Sicurezza del DNS. DNSSEC & Anycast. Claudio Telmon ctelmon@clusit.it

Sicurezza del DNS. DNSSEC & Anycast. Claudio Telmon ctelmon@clusit.it Sicurezza del DNS DNSSEC & Anycast Claudio Telmon ctelmon@clusit.it Perché il DNS Fino a metà degli anni '80, la traduzione da nomi a indirizzi IP era fatta con un grande file hosts Fino ad allora non

Dettagli

Il World Wide Web: nozioni introduttive

Il World Wide Web: nozioni introduttive Il World Wide Web: nozioni introduttive Dott. Nicole NOVIELLI novielli@di.uniba.it http://www.di.uniba.it/intint/people/nicole.html Cos è Internet! Acronimo di "interconnected networks" ("reti interconnesse")!

Dettagli

HORIZON SQL CONFIGURAZIONE DI RETE

HORIZON SQL CONFIGURAZIONE DI RETE 1-1/9 HORIZON SQL CONFIGURAZIONE DI RETE 1 CARATTERISTICHE DI UN DATABASE SQL...1-2 Considerazioni generali... 1-2 Concetto di Server... 1-2 Concetto di Client... 1-2 Concetto di database SQL... 1-2 Vantaggi...

Dettagli

Caratteristiche raccomandate del Network in un progetto di Home Automation

Caratteristiche raccomandate del Network in un progetto di Home Automation Caratteristiche raccomandate del Network in un progetto di Home Automation Uno degli aspetti progettuali più importanti di un sistema Control4 è la rete. Una rete mal progettata, in molti casi, si tradurrà

Dettagli

WAN 80.80.80.80 / 24. L obiettivo è quello di mappare due server web interni (porta 80) associandoli agli indirizzi IP Pubblici forniti dall ISP.

WAN 80.80.80.80 / 24. L obiettivo è quello di mappare due server web interni (porta 80) associandoli agli indirizzi IP Pubblici forniti dall ISP. Configurazione di indirizzi IP statici multipli Per mappare gli indirizzi IP pubblici, associandoli a Server interni, è possibile sfruttare due differenti metodi: 1. uso della funzione di Address Translation

Dettagli

Configurazione avanzata di IBM SPSS Modeler Entity Analytics

Configurazione avanzata di IBM SPSS Modeler Entity Analytics Configurazione avanzata di IBM SPSS Modeler Entity Analytics Introduzione I destinatari di questa guida sono gli amministratori di sistema che configurano IBM SPSS Modeler Entity Analytics (EA) in modo

Dettagli

Progetto VirtualCED Clustered

Progetto VirtualCED Clustered Progetto VirtualCED Clustered Un passo indietro Il progetto VirtualCED, descritto in un precedente articolo 1, è ormai stato implementato con successo. Riassumendo brevemente, si tratta di un progetto

Dettagli

Manuale installazione KNOS

Manuale installazione KNOS Manuale installazione KNOS 1. PREREQUISITI... 3 1.1 PIATTAFORME CLIENT... 3 1.2 PIATTAFORME SERVER... 3 1.3 PIATTAFORME DATABASE... 3 1.4 ALTRE APPLICAZIONI LATO SERVER... 3 1.5 ALTRE APPLICAZIONI LATO

Dettagli

SOFTWARE GESTIONE SMS DA INTERFACCE CL MANUALE D INSTALLAZIONE ED USO

SOFTWARE GESTIONE SMS DA INTERFACCE CL MANUALE D INSTALLAZIONE ED USO CLSMS SOFTWARE GESTIONE SMS DA INTERFACCE CL MANUALE D INSTALLAZIONE ED USO Sommario e introduzione CLSMS SOMMARIO INSTALLAZIONE E CONFIGURAZIONE... 3 Parametri di configurazione... 4 Attivazione Software...

Dettagli

Guida all'installazione di WiFi Booster WN1000RP per dispositivi mobili

Guida all'installazione di WiFi Booster WN1000RP per dispositivi mobili Guida all'installazione di WiFi Booster WN1000RP per dispositivi mobili 2012 NETGEAR, Inc. Tutti i diritti riservati. Nessuna parte della presente pubblicazione può essere riprodotta, trasmessa, trascritta,

Dettagli

Interfaccia Web per customizzare l interfaccia dei terminali e

Interfaccia Web per customizzare l interfaccia dei terminali e SIP - Session Initiation Protocol Il protocollo SIP (RFC 2543) è un protocollo di segnalazione e controllo in architettura peer-to-peer che opera al livello delle applicazioni e quindi sviluppato per stabilire

Dettagli

Sistemi avanzati di gestione dei Sistemi Informativi

Sistemi avanzati di gestione dei Sistemi Informativi Esperti nella gestione dei sistemi informativi e tecnologie informatiche Sistemi avanzati di gestione dei Sistemi Informativi Docente: Email: Sito: Eduard Roccatello eduard@roccatello.it http://www.roccatello.it/teaching/gsi/

Dettagli

GUIDA alla configurazione di un DVR o Router su dyndns.it. in modalità compatibile www.dyndns.org

GUIDA alla configurazione di un DVR o Router su dyndns.it. in modalità compatibile www.dyndns.org GUIDA alla configurazione di un DVR o Router su dyndns.it in modalità compatibile www.dyndns.org Questa semplice guida fornisce le informazioni necessarie per eseguire la registrazione del proprio DVR

Dettagli

ARP (Address Resolution Protocol)

ARP (Address Resolution Protocol) ARP (Address Resolution Protocol) Il routing Indirizzo IP della stazione mittente conosce: - il proprio indirizzo (IP e MAC) - la netmask (cioè la subnet) - l indirizzo IP del default gateway, il router

Dettagli

Active Solution & Systems illustra La virtualizzazione dei Server secondo il produttore di Storage Qsan

Active Solution & Systems illustra La virtualizzazione dei Server secondo il produttore di Storage Qsan Active Solution & Systems illustra La virtualizzazione dei secondo il produttore di Storage Qsan Milano, 9 Febbraio 2012 -Active Solution & Systems, società attiva sul mercato dal 1993, e da sempre alla

Dettagli

Programmazione di rete in Java

Programmazione di rete in Java Programmazione di rete in Java Reti di calcolatori Una rete di calcolatori è un sistema che permette la condivisione di dati informativi e risorse (sia hardware sia software) tra diversi calcolatori. Lo

Dettagli

Virtualizzazione con Microsoft Tecnologie e Licensing

Virtualizzazione con Microsoft Tecnologie e Licensing Microsoft Virtualizzazione con Microsoft Tecnologie e Licensing Profile Redirezione dei documenti Offline files Server Presentation Management Desktop Windows Vista Enterprise Centralized Desktop Application

Dettagli

Livello di applicazione. Reti di Calcolatori. Corso di Laurea in Ingegneria Informatica. Livello di applicazione DNS A.A.

Livello di applicazione. Reti di Calcolatori. Corso di Laurea in Ingegneria Informatica. Livello di applicazione DNS A.A. Corso di Laurea in Ingegneria Informatica Reti di Calcolatori Livello di applicazione DNS A.A. 2013/2014 1 Livello di applicazione Web e HTTP FTP Posta elettronica SMTP, POP3, IMAP DNS Applicazioni P2P

Dettagli

Posta Elettronica. Claudio Cardinali claudio@csolution.it

Posta Elettronica. Claudio Cardinali claudio@csolution.it Posta Elettronica Claudio Cardinali claudio@csolution.it Posta Elettronica: WebMail Una Webmail è un'applicazione web che permette di gestire uno o più account di posta elettronica attraverso un Browser.

Dettagli

Talento LAB 4.1 - UTILIZZARE FTP (FILE TRANSFER PROTOCOL) L'UTILIZZO DI ALTRI SERVIZI INTERNET. In questa lezione imparerete a:

Talento LAB 4.1 - UTILIZZARE FTP (FILE TRANSFER PROTOCOL) L'UTILIZZO DI ALTRI SERVIZI INTERNET. In questa lezione imparerete a: Lab 4.1 Utilizzare FTP (File Tranfer Protocol) LAB 4.1 - UTILIZZARE FTP (FILE TRANSFER PROTOCOL) In questa lezione imparerete a: Utilizzare altri servizi Internet, Collegarsi al servizio Telnet, Accedere

Dettagli

Web Conferencing Open Source

Web Conferencing Open Source Web Conferencing Open Source A cura di Giuseppe Maugeri g.maugeri@bembughi.org 1 Cos è BigBlueButton? Sistema di Web Conferencing Open Source Basato su più di quattordici componenti Open-Source. Fornisce

Dettagli

BPEL: Business Process Execution Language

BPEL: Business Process Execution Language Ingegneria dei processi aziendali BPEL: Business Process Execution Language Ghilardi Dario 753708 Manenti Andrea 755454 Docente: Prof. Ernesto Damiani BPEL - definizione Business Process Execution Language

Dettagli

UML Component and Deployment diagram

UML Component and Deployment diagram UML Component and Deployment diagram Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Università di Catania I diagrammi UML Classificazione

Dettagli

GESTIONE DELLA E-MAIL

GESTIONE DELLA E-MAIL GESTIONE DELLA E-MAIL Esistono due metodologie, completamente diverse tra loro, in grado di consentire la gestione di più caselle di Posta Elettronica: 1. tramite un'interfaccia Web Mail; 2. tramite alcuni

Dettagli

Setup e installazione

Setup e installazione Setup e installazione 2 Prima di muovere i primi passi con Blender e avventurarci nel vasto mondo della computer grafica, dobbiamo assicurarci di disporre di due cose: un computer e Blender. 6 Capitolo

Dettagli

Voice Over IP NAT Traversal

Voice Over IP NAT Traversal Voice Over IP Traversal Giorgio Zoppi zoppi@cli.di.unipi.it Tecnologie di Convergenza su IP a.a.2005/2006 VoIP Traversal 1 57 Tecnologie di Convergenza su IP Che cosa è il (Network Address Translation?

Dettagli

2 Requisiti di sistema 4 2.1 Requisiti software 4 2.2 Requisiti hardware 5 2.3 Software antivirus e di backup 5 2.4 Impostazioni del firewall 5

2 Requisiti di sistema 4 2.1 Requisiti software 4 2.2 Requisiti hardware 5 2.3 Software antivirus e di backup 5 2.4 Impostazioni del firewall 5 Guida introduttiva Rivedere i requisiti di sistema e seguire i facili passaggi della presente guida per distribuire e provare con successo GFI FaxMaker. Le informazioni e il contenuto del presente documento

Dettagli

AGGIORNAMENTO PROTOCOLLO VERSIONE 3.9.0

AGGIORNAMENTO PROTOCOLLO VERSIONE 3.9.0 AGGIORNAMENTO PROTOCOLLO VERSIONE 3.9.0 Con questo aggiornamento sono state implementate una serie di funzionalità concernenti il tema della dematerializzazione e della gestione informatica dei documenti,

Dettagli

Manuale di Remote Desktop Connection. Brad Hards Urs Wolfer Traduzione: Luciano Montanaro Traduzione: Daniele Micci

Manuale di Remote Desktop Connection. Brad Hards Urs Wolfer Traduzione: Luciano Montanaro Traduzione: Daniele Micci Manuale di Remote Desktop Connection Brad Hards Urs Wolfer Traduzione: Luciano Montanaro Traduzione: Daniele Micci 2 Indice 1 Introduzione 5 2 Il protocollo Remote Frame Buffer 6 3 Uso di Remote Desktop

Dettagli

Sistemi Web-Based - Terminologia. Progetto di Sistemi Web-Based Prof. Luigi Laura, Univ. Tor Vergata, a.a. 2010/2011

Sistemi Web-Based - Terminologia. Progetto di Sistemi Web-Based Prof. Luigi Laura, Univ. Tor Vergata, a.a. 2010/2011 Sistemi Web-Based - Terminologia Progetto di Sistemi Web-Based Prof. Luigi Laura, Univ. Tor Vergata, a.a. 2010/2011 CLIENT: il client è il programma che richiede un servizio a un computer collegato in

Dettagli

Virtualizzazione e installazione Linux

Virtualizzazione e installazione Linux Virtualizzazione e installazione Linux Federico De Meo, Davide Quaglia, Simone Bronuzzi Lo scopo di questa esercitazione è quello di introdurre il concetto di virtualizzazione, di creare un ambiente virtuale

Dettagli

ORACLE BUSINESS INTELLIGENCE STANDARD EDITION ONE A WORLD CLASS PERFORMANCE

ORACLE BUSINESS INTELLIGENCE STANDARD EDITION ONE A WORLD CLASS PERFORMANCE ORACLE BUSINESS INTELLIGENCE STANDARD EDITION ONE A WORLD CLASS PERFORMANCE Oracle Business Intelligence Standard Edition One è una soluzione BI completa, integrata destinata alle piccole e medie imprese.oracle

Dettagli

I name server DNS. DNS: Domain Name System. Esempio di DNS. DNS: Root name server. DNS: queries ripetute

I name server DNS. DNS: Domain Name System. Esempio di DNS. DNS: Root name server. DNS: queries ripetute DNS: Domain Name System I name DNS Persone: identificatori: CF, nome, Numero di Passaporto Host e router Internet: Indirizzo IP ( bit) - usato per instradare i pacchetti nome, per es., massimotto.diiie.unisa.it

Dettagli

Determinare la grandezza della sottorete

Determinare la grandezza della sottorete Determinare la grandezza della sottorete Ogni rete IP possiede due indirizzi non assegnabili direttamente agli host l indirizzo della rete a cui appartiene e l'indirizzo di broadcast. Quando si creano

Dettagli

I veri benefici dell Open Source nell ambito del monitoraggio IT. Georg Kostner, Department Manager Würth Phoenix

I veri benefici dell Open Source nell ambito del monitoraggio IT. Georg Kostner, Department Manager Würth Phoenix I veri benefici dell Open Source nell ambito del monitoraggio IT Georg Kostner, Department Manager Würth Phoenix IT Service secondo ITIL Il valore aggiunto dell Open Source Servizi IT Hanno lo scopo di

Dettagli

Payment Card Industry (PCI) Data Security Standard

Payment Card Industry (PCI) Data Security Standard Payment Card Industry (PCI) Data Security Standard Procedure per la scansione di sicurezza Versione 1.1 Release: settembre 2006 Indice generale Finalità... 1 Introduzione... 1 Ambito di applicazione dei

Dettagli

GUIDA ALLE BEST PRACTICE PER MOBILE DEVICE MANAGEMENT E MOBILE SECURITY

GUIDA ALLE BEST PRACTICE PER MOBILE DEVICE MANAGEMENT E MOBILE SECURITY GUIDA ALLE BEST PRACTICE PER MOBILE DEVICE MANAGEMENT E MOBILE SECURITY Con Kaspersky, adesso è possibile. www.kaspersky.it/business Be Ready for What's Next SOMMARIO Pagina 1. APERTI 24 ORE SU 24...2

Dettagli

Cross Software ltd Malta Pro.Sy.T Srl. Il gestionale come l'avete sempre sognato... Pag. 1

Cross Software ltd Malta Pro.Sy.T Srl. Il gestionale come l'avete sempre sognato... Pag. 1 Il gestionale come l'avete sempre sognato... Pag. 1 Le funzionalità di X-Cross La sofisticata tecnologia di CrossModel, oltre a permettere di lavorare in Internet come nel proprio ufficio e ad avere una

Dettagli

- Antivirus, Firewall e buone norme di comportamento

- Antivirus, Firewall e buone norme di comportamento Reti Di cosa parleremo? - Definizione di Rete e Concetti di Base - Tipologie di reti - Tecnologie Wireless - Internet e WWW - Connessioni casalinghe a Internet - Posta elettronica, FTP e Internet Browser

Dettagli

IT-BOOK. Domini Hosting Web marketing E-mail e PEC

IT-BOOK. Domini Hosting Web marketing E-mail e PEC 5 giugno 09 IT-BOOK Configurazioni e cartatteristiche tecniche possono essere soggette a variazioni senza preavviso. Tutti i marchi citati sono registrati dai rispettivi proprietari. Non gettare per terra:

Dettagli

Configurazioni Mobile Connect

Configurazioni Mobile Connect Mailconnect Mail.2 L EVOLUZIONE DELLA POSTA ELETTRONICA Configurazioni Mobile Connect iphone MOBILE CONNECT CONFIGURAZIONE MOBILE CONNECT PER IPHONE CONFIGURAZIONE IMAP PER IPHONE RUBRICA CONTATTI E IPHONE

Dettagli

GLI ERRORI DI OUTLOOK EXPRESS

GLI ERRORI DI OUTLOOK EXPRESS Page 1 of 6 GLI ERRORI DI OUTLOOK EXPRESS 1) Impossibile inviare il messaggio. Uno dei destinatari non è stato accettato dal server. L'indirizzo di posta elettronica non accettato è "user@dominio altro

Dettagli

SERVER VIDEO 1-PORTA H.264

SERVER VIDEO 1-PORTA H.264 SERVER VIDEO 1-PORTA H.264 MANUALE UTENTE DN-16100 SALVAGUARDIA IMPORTANTE Tutti i prodotti senza piombo offerti dall'azienda sono a norma con i requisiti della legge Europea sulla restrizione per l'uso

Dettagli

Guida ai Servizi Internet per il Referente Aziendale

Guida ai Servizi Internet per il Referente Aziendale Guida ai Servizi Internet per il Referente Aziendale Indice Indice Introduzione...3 Guida al primo accesso...3 Accessi successivi...5 Amministrazione dei servizi avanzati (VAS)...6 Attivazione dei VAS...7

Dettagli

DNS cache poisoning e Bind

DNS cache poisoning e Bind ICT Security n. 19, Gennaio 2004 p. 1 di 5 DNS cache poisoning e Bind Il Domain Name System è fondamentale per l'accesso a internet in quanto risolve i nomi degli host nei corrispondenti numeri IP. Se

Dettagli

Test del funzionamento di un Rendez-vous Server mediante l implementazione InfraHIP

Test del funzionamento di un Rendez-vous Server mediante l implementazione InfraHIP Facoltá di Ingegneria Corso di Studi in Ingegneria Informatica Elaborato finale in Protocolli per Reti Mobili Test del funzionamento di un Rendez-vous Server mediante l implementazione InfraHIP Anno Accademico

Dettagli

Outlook Express 6 Microsoft Internet Explorer, Avvio del programma Creare un nuovo account

Outlook Express 6 Microsoft Internet Explorer, Avvio del programma Creare un nuovo account Outlook Express 6 è un programma, incluso nel browser di Microsoft Internet Explorer, che ci permette di inviare e ricevere messaggi di posta elettronica. È gratuito, semplice da utilizzare e fornisce

Dettagli

Architettura di un sistema informatico 1 CONCETTI GENERALI

Architettura di un sistema informatico 1 CONCETTI GENERALI Architettura di un sistema informatico Realizzata dal Dott. Dino Feragalli 1 CONCETTI GENERALI 1.1 Obiettivi Il seguente progetto vuole descrivere l amministrazione dell ITC (Information Tecnology end

Dettagli

Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN)

Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN) Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN) System Overview di Mattia Bargellini 1 CAPITOLO 1 1.1 Introduzione Il seguente progetto intende estendere

Dettagli

Introduzione ai protocolli di rete Il protocollo NetBEUI Il protocollo AppleTalk Il protocollo DLC Il protocollo NWLink Il protocollo TCP/IP

Introduzione ai protocolli di rete Il protocollo NetBEUI Il protocollo AppleTalk Il protocollo DLC Il protocollo NWLink Il protocollo TCP/IP Protocolli di rete Sommario Introduzione ai protocolli di rete Il protocollo NetBEUI Il protocollo AppleTalk Il protocollo DLC Il protocollo NWLink Il protocollo TCP/IP Configurazione statica e dinamica

Dettagli

Per questa ragione il nostro sforzo si è concentrato sugli aspetti elencati qui di seguito:

Per questa ragione il nostro sforzo si è concentrato sugli aspetti elencati qui di seguito: Autore : Giulio Martino IT Security, Network and Voice Manager Technical Writer e Supporter di ISAServer.it www.isaserver.it www.ocsserver.it www.voipexperts.it - blogs.dotnethell.it/isacab giulio.martino@isaserver.it

Dettagli

PRESENTAZIONE DI UN SMS AL GATEWAY

PRESENTAZIONE DI UN SMS AL GATEWAY Interfaccia Full Ascii Con questa interfaccia è possibile inviare i dati al Server utilizzando solo caratteri Ascii rappresentabili e solo i valori che cambiano tra un sms e l altro, mantenendo la connessione

Dettagli

Arcserve Replication and High Availability

Arcserve Replication and High Availability Arcserve Replication and High Availability Guida operativa per Oracle Server per Windows r16.5 La presente documentazione, che include il sistema di guida in linea integrato e materiale distribuibile elettronicamente

Dettagli

Guida alla scansione su FTP

Guida alla scansione su FTP Guida alla scansione su FTP Per ottenere informazioni di base sulla rete e sulle funzionalità di rete avanzate della macchina Brother, consultare la uu Guida dell'utente in rete. Per ottenere informazioni

Dettagli

Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali

Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali Riusabilità del software - Catalogo delle applicazioni: Applicativo verticale Applicazione: DoQui/Index - Motore di gestione dei contenuti digitali Amministrazione: Regione Piemonte - Direzione Innovazione,

Dettagli

Guida all'installazione rapida di scansione su e-mail

Guida all'installazione rapida di scansione su e-mail Xerox WorkCentre M118i Guida all'installazione rapida di scansione su e-mail 701P42705 Questa guida fornisce un riferimento rapido per l'impostazione della funzione Scansione su e-mail su Xerox WorkCentre

Dettagli

Ambienti di sviluppo integrato

Ambienti di sviluppo integrato Ambienti di sviluppo integrato Un ambiente di sviluppo integrato (IDE - Integrated Development Environment) è un ambiente software che assiste i programmatori nello sviluppo di programmi Esso è normalmente

Dettagli

CONFIGURAZIONE DEI SERVIZI (seconda parte)

CONFIGURAZIONE DEI SERVIZI (seconda parte) Corso ForTIC C2 LEZIONE n. 10 CONFIGURAZIONE DEI SERVIZI (seconda parte) WEB SERVER PROXY FIREWALL Strumenti di controllo della rete I contenuti di questo documento, salvo diversa indicazione, sono rilasciati

Dettagli

Guida all'installazione del WiFi Booster WN1000RP per dispositivi mobili

Guida all'installazione del WiFi Booster WN1000RP per dispositivi mobili Guida all'installazione del WiFi Booster WN1000RP per dispositivi mobili Sommario Per iniziare............................................ 3 Il WiFi Booster......................................... 4 Pannello

Dettagli

Architettura SPC e porta di dominio per le PA

Architettura SPC e porta di dominio per le PA Libro bianco sulla SOA v.1.0 Allegato 2_1 Architettura SPC e porta di dominio per le PA vs 02 marzo 2008 Gruppo di Lavoro SOA del ClubTI di Milano Premessa L architettura SPC e la relativa porta di dominio

Dettagli

La gestione integrata della sicurezza in Agenzia ANSA: dal firewalling all'utm Michelangelo Uberti, Sales Engineer Babel S.r.l.

La gestione integrata della sicurezza in Agenzia ANSA: dal firewalling all'utm Michelangelo Uberti, Sales Engineer Babel S.r.l. La gestione integrata della sicurezza in Agenzia ANSA: dal firewalling all'utm Michelangelo Uberti, Sales Engineer Babel S.r.l. Babel S.r.l. - P.zza S. Benedetto da Norcia 33, 00040 Pomezia (RM) www.babel.it

Dettagli

Il Concetto di Processo

Il Concetto di Processo Processi e Thread Il Concetto di Processo Il processo è un programma in esecuzione. È l unità di esecuzione all interno del S.O. Solitamente, l esecuzione di un processo è sequenziale (le istruzioni vengono

Dettagli

***** Il software IBM e semplice *****

***** Il software IBM e semplice ***** Il IBM e semplice ***** ***** Tutto quello che hai sempre voluto sapere sui prodotti IBM per qualificare i potenziali clienti, sensibilizzarli sulle nostre offerte e riuscire a convincerli. WebSphere IL

Dettagli

Servizi DNS - SMTP FTP - TELNET. Programmi. Outlook Express Internet Explorer

Servizi DNS - SMTP FTP - TELNET. Programmi. Outlook Express Internet Explorer Servizi DNS - SMTP FTP - TELNET Programmi Outlook Express Internet Explorer 72 DNS Poiché riferirsi a una risorsa (sia essa un host oppure l'indirizzo di posta elettronica di un utente) utilizzando un

Dettagli

Introduzione alle VLAN Autore: Roberto Bandiera 21 gennaio 2015

Introduzione alle VLAN Autore: Roberto Bandiera 21 gennaio 2015 Introduzione alle VLAN Autore: Roberto Bandiera 21 gennaio 2015 Definizione Mentre una LAN è una rete locale costituita da un certo numero di pc connessi ad uno switch, una VLAN è una LAN VIRTUALE (Virtual

Dettagli

MANUALE UTENTE DEL SOFTWARE DI GESTIONE DEGLI ART. SDVR040A/SDVR080A/SDVR160A

MANUALE UTENTE DEL SOFTWARE DI GESTIONE DEGLI ART. SDVR040A/SDVR080A/SDVR160A MANUALE UTENTE DEL SOFTWARE DI GESTIONE DEGLI ART. SDVR040A/SDVR080A/SDVR160A Leggere attentamente questo manuale prima dell utilizzo e conservarlo per consultazioni future Via Don Arrigoni, 5 24020 Rovetta

Dettagli

Reti di Telecomunicazione Lezione 7

Reti di Telecomunicazione Lezione 7 Reti di Telecomunicazione Lezione 7 Marco Benini Corso di Laurea in Informatica marco.benini@uninsubria.it Il protocollo Programma della lezione file transfer protocol descrizione architetturale descrizione

Dettagli

NetMonitor. Micro guida all uso per la versione 1.2.0 di NetMonitor

NetMonitor. Micro guida all uso per la versione 1.2.0 di NetMonitor NetMonitor Micro guida all uso per la versione 1.2.0 di NetMonitor Cos è NetMonitor? NetMonitor è un piccolo software per il monitoraggio dei dispositivi in rete. Permette di avere una panoramica sui dispositivi

Dettagli