1. ABSTRACT 2. INTRODUZIONE PROGETTO DI UN INFRASTRUTTURA GERARCHICA PER SERVIZI DI FILE HOSTING

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "1. ABSTRACT 2. INTRODUZIONE PROGETTO DI UN INFRASTRUTTURA GERARCHICA PER SERVIZI DI FILE HOSTING"

Transcript

1 PROGETTO DI UN INFRASTRUTTURA GERARCHICA PER SERVIZI DI FILE HOSTING 1. ABSTRACT Al giorno d oggi, l enorme diffusione di contenuti multimediali quali, ad esempio, video ad alta definizione piuttosto che musica o foto digitali, ha causato un notevole aumento della capacità di memorizzazione richiesta da ogni utente. Disporre di dispositivi di archiviazione sempre più grandi non è più la scelta ottimale sia dal punto di vista economico che, soprattutto, considerando come i nuovi scenari dell IT moderno spingono verso una sempre maggior mobilità di dati e utenti che hanno una variegata quantità di dispositivi diversi: da classici PC fino a computer palmari, passando per telefoni cellulari e computer portatili. Emerge quindi un problema cruciale presente in tali scenari: la portabilità dei dati. Ogni utente, infatti, desidera poter avere i propri file indipendentemente dalla sua locazione fisica o dal dispositivo che utilizza in ogni istante. Per risolvere questo problema è necessario avere un deposito remoto dove immagazzinare i propri dati e un sistema che consenta di renderli fruibili ovunque nell intero globo. In questo scenario nascono i servizi di file hosting, che consentono agli utenti di memorizzare dati personali su server remoti, non occupando le proprie risorse locali e potendo disporre dei file da qualsiasi postazione connessa alla rete Internet, che allo stato attuale consente una copertura pressoché capillare del globo, grazie anche alle recenti introduzioni di tecnologie radio wireless come il Wi-Fi o, migliore, il Wi-Max. È evidente che con questa soluzione siamo in grado di risolvere i problemi citati in precedenza, ma non solo. Ci si rende subito conto della possibilità di instaurare una forma di condivisione dei dati. Infatti, in base alla politica adottata dal servizio, potranno esserci file pubblici, accessibili a tutti gli utenti, piuttosto che file privati. Esiste però anche un rovescio della medaglia. Pensare di realizzare un tale servizio di file hosting a larga scala, pone seri problemi riguardo alla capacità di memoria richiesta, la congestione indotta nella rete di supporto ed anche riguardo alla sicurezza dei dati nelle loro varie fasi di vita: dal trasporto via rete al server di file hosting fino alla memorizzazione nel file system di quest ultimo. E necessario anche predisporre un opportuno meccanismo di autenticazione e autorizzazione dei diversi utenti per garantire un adeguata privacy. Gli aspetti fondamentali che determinano la QoS percepita dagli utenti in questi servizi, sono senza dubbio la disponibilità e la correttezza dei dati, nonché la velocità di risposta da parte del server. Il presente lavoro s inquadra proprio in questo scenario e mira a realizzare un infrastruttura client/server che consenta di fruire di un servizio di file hosting affidabile, disponibile e scalabile, garantendo agli utenti la maggior QoS percepita possibile in base alle risorse disponibili nell architettura server. 2. INTRODUZIONE Questo lavoro presenta un infrastruttura client/server che implementa un servizio di file hosting. Nella realizzazione sono stati particolarmente curati gli aspetti di disponibilità, affidabilità e scalabilità del servizio, presentando una soluzione server basata su un cluster in grado di garantire sia le proprietà sopra enunciate, che di bilanciare il carico di lavoro tra i diversi nodi del cluster stesso. È stato inoltre realizzato un middleware di supporto in grado di integrare, in maniera 1

2 trasparente, qualsiasi client con l architettura server progettata, fornendo una interfaccia che espone tutti le api base per accedere a tutti i servizi offerti. 3. ARCHITETTURA L infrastruttura progettata è basata su un paradigma client/server, in cui il server è gestito mediante una struttura a livelli, modellando l intera architettura server come un highavailability cluster. La figura seguente rappresenta la struttura proposta: M I D D L E W A R E Manager Server Data Server Si vengono così a individuare tre tipologie diversi di attori (manager server, data server, client) organizzati in una struttura gerarchica. Il cliente vede in modo trasparente solo un manager, ed esegue su di esso tutte le operazioni che desidera, senza accorgersi della presenza dei data server e/o degli altri manager server: questo grazie all uso di un middleware, che nasconde tutti i dettagli della struttura e della comunicazione. Fondamentalmente la struttura del sistema presenta due layer: Manager server: uno o più server di gestione dove i clienti si collegano e richiedono le operazioni sul file system (aggiunta file, rimozione file, lista file, ecc ). Data server: uno o più server dove risiedono i veri e propri file depositati dai clienti. Il cliente, per accedere al file di hosting, richiede i servizi utilizzando il middleware di supporto, che invierà la richiesta ad un manager (locazione presente nel file di configurazione del middleware e scelto in base a politiche implementate all interno del middleware stesso) che a sua volta la ridirigerà sull opportuno data server, applicando le politiche di bilanciamento di risorse e di carico, implementate all interno del manager. Nella memoria del manager deve quindi essere presente una struttura dati che definisca logicamente l intero file system, mentre i file sono fisicamente memorizzati nei diversi data server partecipanti. Ciò permette al manager da un lato di servire velocemente richieste da parte dei client delegandole ai data server che presentano una situazione di carico migliore e dall altro lato di mantenere un controllo centralizzato sui diversi data server per gestire al meglio le capacità di replicazione e faulttolerance, nonché di garantire un elevata scalabilità del servizio. Da notare che l overhead di comunicazione dovuto alla gestione e coordinamento tra data server e manager server è limitato alla sola isola di gestione di ciascun manager (ricordiamo che ciascun data server, in ogni istante, è registrato presso un solo manager server) e sarà quest ultimo che, con un servizio di background, aggiornerà gli altri manager sullo stato di operatività e carico dei data server registrati presso di lui, minimizzando così il numero di pacchetti scambiati (vedi capitolo 10) e quindi l overhead di comunicazione dovuto alla gestione dell infrastruttura. In linea teorica il sistema può operare correttamente se sono presenti un client, un manager e un data server. Questa è una configurazione minima che ovviamente non consente alcun tipo di ottimizzazione e che in 2

3 sostanza non garantisce nessuna delle proprietà che sono obiettivo di progetto. E quindi con l aggiunta di più data server e manager server che si ottengono i benefici desiderati da un sistema di tale genere: infatti, grazie agli algoritmi di ottimizzazione implementati dai manager, si possono ottenere affidabilità, disponibilità e scalabilità del servizio. Il prossimo capitolo è dedicato alla presentazione di tali algoritmi e delle annesse scelte di progetto. Passiamo ora a una rapida descrizione delle scelte tecnologiche effettuate. L intero progetto è stato scritto sfruttando il linguaggio Java, con l obiettivo di beneficiare dell ormai nota portabilità inter-piattaforma propria di questo linguaggio. Per quanto riguarda le comunicazioni attraverso la rete si è preferito utilizzare delle socket TCP che, a fronte di un maggiore overhead di trasmissione, garantiscono l affidabilità necessaria al servizio (garanzia di consegna dei messaggi e conservazione dell ordine d invio): questo non è un vincolo stretto di progetto, poiché, grazie all utilizzo del provider model, è possibile in modo molto semplice integrare diversi tipi di connettività semplicemente cambiando il file di configurazione. E stato implementato, per ora, un servizio di file hosting mono-utente, dove i file depositati sono pubblici e chiunque può vederli o aggiungerne degli altri, senza nessun meccanismo di autenticazione o autorizzazione. Le operazioni possibili per i client sono quelle di upload e di download di file e listare i file contenuti correntemente nel sistema, mentre l amministratore, tramite l interfaccia grafica, può decidere a run-time di registrare il manager server (o il data server) sul sistema per iniziare a servire le richieste dei clienti, o deregistrarsi dal sistema per eseguire ad esempio delle operazioni di manutenzione offline sul server. Interessante è notare che alla chiusura del manager non è terminato solo lui, ma a cascata, sono chiusi anche tutti i data server che erano registrati presso lui. Illustriamo ora le principali caratteristiche del manager e del data server, rimandando al capitolo 9 quelle riguardanti il client e il rispettivo middleware. 3.1 MANAGER SERVER Il manager rappresenta il fulcro dell architettura, poiché ha il duplice ruolo di coordinare i vari data server e di servire o ridirigere le richieste provenienti dai client, nonché di sincronizzarsi con gli altri manager per mantenere una copia del File System logico globale, e riconfigurare l anello logico presente fra i vari manager server nel caso avvengano delle variazioni (aggiunta/rimozione di nuovi manager). Per questo motivo, esso è realizzato come un applicazione multi-threaded: una server socket TCP riceve, infatti, le richieste dai client attivando un thread specifico per ogni operazione; una server socket TCP per accettare i nuovi data server che vogliono registrarsi al sistema; e una server socket TCP per registrare i nuovi manager server (da notare che i manager che vogliono registrarsi al cluster devono farne richiesta presso un qualsiasi dei manager già attivo nel sistema). Per mantenere un alta disponibilità del servizio, all interno del sistema sono presenti più manager server organizzati in una struttura ad anello logico, il cui numero può essere variato in modo dinamico senza interruzioni di servizio. Ogni manager ha una connessione permanente verso un manager successivo, e queste connessioni sono utilizzate dai manager per: controllare l operatività dei server: in particolare ogni manager controlla l operatività del proprio manager successivo attraverso l invio di messaggi di heartbeat mediante questo canale; per propagare eventuali modifiche del file system; 3

4 per propagare informazioni sullo stato di carico dei vari server (sia data server che manager server). In questo modo ogni manager server è incaricato di servire i clienti, e nel caso vada offline, questi ultimi possono rivolgersi a un manager alternativo per richiederne i servizi. Per questo motivo occorre che tutti i manager server siano perfettamente sincronizzati tra di loro in modo che ciascuno di questi abbia una copia del file system logico globale. A tal scopo ogni manager server mantiene al suo interno due oggetti di tipo InformationControl e FileSystem contenenti tutte le info riguardanti il sistema globale: rispettivamente, informazioni sul carico dei vari server sino a quel momento registrati al sistema, e struttura logica dei file presenti nei diversi data server. Tramite l ispezione di questi oggetti sono scelte le locazioni di download e upload per i client e si definiscono le operazioni di ottimizzazione possibili. Nascono così problematiche di propagazione dello stato e sincronizzazione a run-time dei manager che affronteremo nel capitolo DATA SERVER I data server rappresentano gli effettivi esecutori del servizio e il loro numero può essere dinamicamente variato, con la prerogativa che maggiore è il loro numero e maggiori saranno le prestazioni dell infrastruttura. Ogni data server è registrato presso un manager che lo gestisce, ed è compito dell amministratore del sistema stabilire in modo statico quest associazione, inserendo nella configurazione del data server la locazione del manager server al quale rivolgersi, cercando di strutturare il sistema in modo intelligente, associando i vari data server in base alle esigenze di risorse richieste (manager ad alto traffico dovrebbero avere più data server a disposizione rispetto a manager più scarichi) e permettere quindi politiche di bilanciamento sensate sfruttando al massimo le potenzialità dell hardware a disposizione. I data server sono costantemente monitorati dal manager, che gestisce la replicazione dei file e bilancia il carico di lavoro su ognuno di essi. La comunicazione con i client durante le operazioni di trasferimento file sono ovviamente gestite secondo il protocollo TCP, così come le operazioni di replica fra data server diversi. Anche i data server sono realizzati come applicazioni multi-threaded e presentano una GUI tramite la quale un amministratore di sistema può avviare il server e visualizzare le operazioni che avvengono grazie ad un log grafico, o deregistrarlo rendendo i file in esso contenuti non più disponibili (ad esempio per far migrare il data server presso altri manager che presentano una situazione di carico maggiore, o per eseguire qualsiasi tipo di manutenzione offline del server). Per essere integrato nel sistema, un data server quindi ha bisogno di registrarsi presso un manager già attivo nel sistema: durante questa procedura esso invia i propri dati identificativi (IP, porta di ascolto, file condivisi, spazio disponibile ) e attende una risposta per mettersi in ascolto sulla porta convenuta in attesa di richieste da parte dei client. Inoltre viene connessa con il manager anche una socket TCP permanente che funge da canale di controllo per monitorare l operatività del data server mediante invio di messaggi heartbeat, e propagare lo stato di carico del data server verso il manager (spazio disponibile, quantità di carico, ecc). 3.3 PRINCIPALI OPERAZIONI Vediamo ora quali sono i protocolli previsti per le principali operazioni messe a disposizione dall architettura. Banalmente la richiesta della lista dei file remoti prevede un messaggio di richiesta da parte del middleware verso il manager server a lui assegnato e un 4

5 messaggio di risposta contenente la lista dei file. Più d interesse possono essere invece gli altri due protocolli. Per quanto riguarda l upload/download di file il protocollo è il seguente: il middleware invia un messaggio di richiesta al manager contenente il path remoto e la dimensione del file da caricare/scaricare; il manager, dopo aver effettuato alcuni controlli, risponde alla richiesta con la locazione (indirizzo ip + porta) del data server dove depositare/prelevare il file (scelta secondo le politiche di bilanciamento che affronteremo nel capitolo 5); il middleware quindi instaura una connessione con esso e inizia il trasferimento del file; in caso di upload, al termine del trasferimento, il data server invia una notifica al manager server a conferma del completamento del trasferimento del file, e quest ultimo provvede ad aggiungerlo all interno del file system; inserire la corrispondente informazione nel vettore delle modifiche per essere propagata all interno dell anello, e risponde al data server con un messaggio di successo; in caso di errori durante queste operazioni risponde con un messaggio di fallimento (una eccezione) contenente una descrizione dell errore; il data server ricevuta la risposta invia un messaggio al middleware (cliente), che può essere di successo nel caso non ci siano stati malfunzionamenti durante il protocollo; altrimenti cancella il file appena caricato e inoltra la descrizione dell errore al cliente. In questo ultimo caso è il cliente che dovrà ripetere al richiesta riprendendo il protocollo dal principio. Questo stesso protocollo è eseguito anche dal data server nel caso di replica di un file: in particolare quando un manager trova un file da replicare invia un comando al data server interessato, indicando la locazione del data server scelto per il deposito del file ed instaura una connessione con questo per il trasferimento del file. Per quanto riguarda la rimozione di file il protocollo seguito è il seguente: il middleware invia un messaggio al manager contenente il path remoto del file da rimuovere; il manager provvede a rimuovere il file dal file system logico e inserisce la rispettiva informazione di modifica nel vettore delle modifiche da propagare nell anello; lancia un thread responsabile di rimuovere il file dai rispettivi data server da lui gestiti dove risiede realmente il file, in modo da liberarne le risorse (il cliente non dovrà attendere che il file sia fisicamente rimosso dal data server); invia un messaggio al middleware contenente l esito dell operazione; anche gli altri manager server alla ricezione del messaggio di modifica rimuoveranno eventuali repliche del file sui data server gestiti. Da notare che il middleware (e quindi il cliente) ottiene una risposta sull esito dell operazione richiesta nonostante la modifica non sia stata ancora propagata all interno del sistema (approccio time-based di propagazione delle modifiche del file system). Questo tipo di approccio può portare a delle inconsistenze nel file system nel caso ad esempio il manager cada prima che l informazioni siano propagate, o anche nel caso ci siano interferenze nelle modifica dei file (due clienti eseguano delle modifiche sui medesimi file), dovuto ai tempi di propagazione. Tutti questi aspetti sono stati presi in considerazione e si è deciso di accettare eventuali inconsistenze per mantenere il più possibile un ottimo livello di prestazione e 5

6 banda occupata. Per risolvere questi problemi, si potrebbe pensare di complicare la progettazione dell infrastruttura, anche in relazione agli scopi d impiego, prevedendo ad esempio degli spazi di hosting separati, e impedire quindi che due utenti diversi non possano accedere in contemporanea allo stesso spazio, in modo da evitare a monte queste situazioni. 4. SINCRONIZZAZIONE L infrastruttura, come visto nel capitolo precedente, presenta più manager server organizzati in una struttura ad anello che collaborano per la fornitura del servizio. Ciascuno di essi mantiene una copia dell intero file system: occorre quindi che informazioni riguardanti la modifica del file system (aggiunta o rimozione file da parte dei clienti o anche replicazione automatica dei file) siano propagate nell interno anello in modo che ogni manager continui a mantenere una copia esatta del file system logico. Per far ciò si è pensato di usare ancora una volta un sistema time-based (per mantenere un livello di efficienza, visti dal cliente, elevato) in cui ogni manager server mantiene nella sua memoria una lista ordinata di modifiche da propagare all interno dell anello. In questo modo quando un cliente aggiunge o rimuove un file, il manager aggiunge questa informazione all interno della lista, e quindi un servizio in background provvederà a propagarle in ordine FIFO all interno dell anello: l informazione attraverserà così tutto l anello, raggiungendo tutti i manager partecipanti al sistema, sino a ritornare al manager di partenza che provvederà a distruggerla. Si accetta quindi di avere delle copie tiepide del file system a vantaggio di prestazioni viste dal cliente decisamente migliori (non occorre che il cliente aspetti che l informazione sia propagata nell anello per avere una risposta sull esito della richiesta, ma in un certo senso, il cliente si fida del manager che quindi sarà responsabile di tale compito). Si potrebbe pensare a dei vincoli e/o politiche che evitano a priori questo tipo di inconsistenze, introducendo ad esempio della ridondanza nelle informazioni di modifica del file system. Ad esempio si potrebbe decidere, in modo statico, un numero di manager server verso i quali propagare queste informazioni, prima di dare una risposta al cliente sull esito dell operazione (con ipotesi di guasto singolo, in linea teorica, basterebbe anche propagare l informazione verso il solo manager successivo). In questo modo, se il cliente ha avuto una risposta positiva, allora si avranno almeno due manager che sono a conoscenza della modifica e nel caso uno dei due cada sarà l altro a propagare l informazione nell anello. Questo tipo di approccio non è stato previsto per mantenere un livello di prestazioni il più alto possibile, ma potrebbe essere una eventuale estensione da implementare. Per rendere possibili questi protocolli, occorre che tutti i messaggi scambiati tra i manager siano identificati in modo univoco, e occorre poter stabilire un ordine temporale tra questi: in particolare occorre che i messaggi creati da ciascun manager siano mantenuti in ordine FIFO (aggiunta e rimozione di file dal sistema non devono invertirsi). Per far ciò le informazioni sono marcate in modo univoco con un identificativo composto dalla combinazione di ID del manager che l ha generata e numero di sequenza (un numero progressivo locale a ciascun server e indipendente dagli altri server). Vediamo ora quali protocolli i manager seguono per configurare l anello mantenendo il file system globale consistente. Innanzitutto il numero di manager all interno del sistema può variare in modo dinamico, e quindi occorre prevedere dei protocolli di join e unjoin del manager all interno del sistema: 6

7 Join: quando un manager si vuole registrare al sistema per iniziare a fornire il servizio, deve effettuare la richiesta presso un manager già attivo e operante (locazione presente all interno del file di configurazione del manager). Quest operazione segue il protocollo qui descritto, indicando con server A il manager servitore della richiesta, server B il suo successivo e server C il richiedente: a) il manager C richiede il join al manager A passandogli il proprio identificativo e un vettore contenente per ciascun manager l ID dell ultimo messaggio ricevuto da una eventuale precedente esecuzione (nel caso un manager registrato al sistema, non sia presente in questo vettore, vengono considerati per la ritrasmissione, tutte le modifiche da esso generate); b) il manager A ricevuta la richiesta, attraverso questo vettore, individua e invia le modifiche da trasmettere al manager C in modo che questo abbia il file system consistente con lo stato corrente, e appende all interno del vettore delle modifiche una particolare informazione (InfoJoin) utile avere conoscenza di quali messaggi sono stati inviati al nuovo manager e quali ancora devono essere inviati, e quindi utilizzato per sincronizzare il thread incaricato di eseguire il join con il thread di background di propagazione delle modifiche; tutto in simultanea al normale funzionamento del manager (thread parallelo e indipendente dal normale funzionamento del manager); c) una volta che il manager C si è sincronizzato con il manager A il processo incaricato di servire la richiesta termina depositando all interno dell oggetto InfoJoin la locazione del nuovo manager; d) il servizio di background una volta raggiunto il messaggio InfoJoin (o nel caso lo raggiungesse prima che il thread depositi il nuovo valore, attende questo valore) invia al manager B l ID del manager C che dovrà essere accettato da B come suo precedente, e chiude la connessione con esso. Questa connessione è rimpiazzata con la connessione al manager C che ha richiesto l operazione di join, e invia a quest ultimo la locazione del manager al quale collegarsi per richiudere l anello (locazione del manager B). e) Il manager C si collega così all indirizzo ricevuto che diventa il proprio manager successivo (richiudendo l anello): a questo punto il join può considerarsi concluso. Per ovvi motivi di semplicità d implementazione un manager può eseguire solo un join alla volta (metodi implementati come syncronized): eventuali altre richieste contemporanee sullo stesso manager saranno messe in coda e servite con i dovuti tempi di attesa. Per capire meglio i vari passaggi illustriamo la seguente figura riassuntiva: A a,b d Unjoin: questo protocollo invece è eseguito nel caso un manager intenda deregistrarsi dal sistema: a) Il manager che intende eseguire l operazione invia innanzitutto una richiesta di unjoin ai data server a lui e C B 7

8 registrati e attende che questi si siano deregistrati (chiusura soft delle comunicazioni attendendo la conclusione delle operazioni correntemente in esecuzione senza accettarne delle nuove); b) una volta che tutti i data server hanno terminato di servire i propri clienti pendenti e si sono deregistrati dal sistema, e tutte le modifiche effettuate sul file system sono state propagate, il manager invia una richiesta di unjoin al manager precedente e chiude la connessione con esso e con il manager successivo; c) il manager precedente ricevuta la richiesta di unjoin (o comunque alla chiusura della connessione) si collega al manager successivo del successivo (locazione sempre presente all interno di ciascun manager e aggiornata automaticamente in caso di riconfigurazione dell anello) ripetendo il protocollo di richiesta del vettore identificativo delle ultime modifiche ricevute e ritrasmette eventuali modifiche perse durante la chiusura delle connessioni. Da notare che questo stesso protocollo è eseguito anche nel caso di crash di un manager: in tal caso è il manager precedente a quello caduto che si accorge della non operatività (grazie ai messaggi di heartbeat) e quindi chiude la connessione con il manager successivo e ne apre una nuova con il manager successivo del successivo in modo da escludere, di fatto, il manager caduto (vedi capitolo 7). Per capire meglio i vari passaggi illustriamo la seguente figura riassuntiva: Manager Precedente b c Nuovo manager Manager successivo Da notare che quando l anello viene riconfigurato il manager che ha cambiato il proprio manager successivo deve aggiornare, sul manager precedente, la locazione del proprio manager successivo (che sarà quindi il successivo del successivo per manager precedente), in modo che ciascun manager conosca la locazione sempre aggiornata del manager successivo al successivo, in accordo alla configurazione attuale dell anello. Ovviamente l unjoin di un manager porta alla chiusura di tutti i data server a lui registrati che quindi non potranno svolgere il proprio servizio: tutti i file depositati su di essi, se non replicati presso altre isole di data server gestiti da altri manager, non saranno disponibili sino a quando quel manager e i suoi rispettivi data server a lui registrati non torneranno online. Per ovviare a questo problema si potrebbe prevedere nella configurazione dei data server un manager alternativo che prende in carico la gestione di questi, sin tanto il manager principale non torna online. Anche questo punto di vista non è stato implementato nella realizzazione dell architettura trattata in quest articolo, ma potrebbero essere una estensione che potrebbe essere integrata nel sistema. a b 8

9 5. LOAD-BALANCING L infrastruttura progettata è in grado di ripartire in maniera uniforme il carico di lavoro fra i diversi data server. Tutto ciò in primo luogo favorisce la velocità di risposta percepita dai client, ma consente anche di non sovraccaricare eccessivamente i vari data server, sfruttando al meglio l hardware a disposizione. Il criterio usato per la scelta è diverso secondo l operazione richiesta, infatti, a fronte di una richiesta da parte di un cliente, il manager, nel restituire una locazione, valuta diversi fattori: In caso di download, il manager sceglie, fra i data server sui quali risiede il file richiesto, quello che è meno congestionato. Il livello di congestione, in questo caso, è misurato come il numero di connessioni simultanee già attive in ogni server. Si sceglierà il server per cui questo valore è minimo, controllando anche il vincolo sul valore massimo di connessioni simultanee ammesse, parametro questo scelto dall amministratore del data server. In caso di una richiesta di upload, invece, oltre a controllare il livello di congestione come nel caso di download, sarà necessario individuare quei data server che hanno sufficiente spazio a disposizione per memorizzare il file. Per effettuare la scelta, infatti, si calcola una media pesata fra questi due fattori, considerando come predominante lo spazio a disposizione del data server. Questa scelta di progetto è stata dettata dalla considerazione che, viste le capacità di replicazione del sistema, caricare file su data server con poco spazio disponibile limita fortemente le possibilità di ottimizzazione, descritte nel prossimo paragrafo. Per quanto riguarda invece il bilanciamento di carico tra i vari manager server questo è demandato al middleware di supporto lato cliente che tratteremo nel capitolo REPLICAZIONE Un altra caratteristica fondamentale per assicurare la disponibilità dei dati è la replicazione degli stessi. Il punto cruciale è quello di trovare un compromesso fra una replicazione totale (situazione idealmente perfetta, ma penalizzante dal punto di vista delle performance) e una replicazione parziale e time-based. Nel progetto è stato usato un sistema di replicazione time-based creando un thread di background che analizza la situazione dell intero cluster logico e, dinamicamente, sceglie quali file, presenti nella propria isola di data server, devono essere replicati e in quali data server (privilegiando data server registrati presso altri manager per garantire che in caso il manager vada offline, altri manager server possono rispondere alla richiesta del file) lasciando poi l effettivo onere della replica ai singoli data server coinvolti. Ciò consente di ottenere un buon grado di affidabilità, introducendo un limitato overhead. Il principio è elementare: a ogni intervallo, che è un parametro di progetto, il manager esamina la lista dei file dei data server gestiti, individuando tutte le possibili repliche da eseguire. Nel determinare le operazioni di replica si è seguito un modello gerarchico, ordinando i file in base al numero di proprietari (numero di data server dove effettivamente risiede una copia del file). Sono così processati prima i file con singolo proprietario, e poi man mano quelli con più proprietari. A parità di numero di proprietari si esegue un secondo ordinamento per dimensione decrescente e quindi (seguendo gli algoritmi di load-balancing) si seleziona, per ognuno, il data server dove compiere l upload. 9

10 Seguendo questo principio si tende a replicare prima i file più grandi per cercare di utilizzare al meglio lo spazio disponibile: infatti, se si replicassero prima i file più piccoli, si correrebbe il rischio di non avere più spazio disponibile per replicare quelli grandi, poiché trovare ampi spazi liberi è sen altro meno probabile rispetto a trovarne di piccoli. 7. FAULT-TOLERANCE In un servizio come il file hosting riveste particolare importanza la gestione delle possibili cadute dei diversi server. È quindi necessario predisporre dei meccanismi, il più possibile automatici, in grado di porre rimedio, in un tempo il più breve possibile, a tali eventi negativi. Per quanto riguarda il controllo dei diversi data server, è lo stesso manager che se ne occupa, mediante un thread che invia pacchetti heartbeat a intervalli regolari, consentendo così di verificarne lo stato di esecuzione: in tali thread, è presente un valore di timeout, trascorso il quale il server è ipotizzato caduto. Per minimizzare l eventualità in cui un singolo pacchetto heartbeat sia perso, per motivi non dipendenti dal data server, è prevista una ritrasmissione immediata del pacchetto alla scadenza del timeout, e una successiva violazione dello stesso porta in questo caso alla dichiarazione di caduta del server, con la conseguenza che vengono rimossi dal manager tutti i riferimenti allo stesso. Un altro aspetto riguardante la faulttolerance è gestito durante le operazioni di download/upload dei file. Infatti, il client, in caso di malfunzionamenti nella rete, prevede meccanismi di ritrasmissione. Nel caso, ad esempio, in cui il data server non rispondesse più, il client chiede al manager un altro indirizzo e ricomincia la transazione con quest ultimo. E stato adottato quest approccio perché, la connessione con il manager è mantenuta durante tutta la durata della sessione di operatività, è statisticamente più rapido richiedere un nuovo indirizzo piuttosto che tentare ritrasmissioni con un server probabilmente caduto. Inoltre anche in caso di caduta di un manager il sistema cerca di reagire minimizzando i tempi di recupero. In sostanza quando un manager cade, il suo manager precedente si accorge di tale situazione, mediante l invio di messaggi di heartbeat, e provvede a riconfigurare l anello connettendosi al manager successivo a quello caduto (ogni manager conosce il manager successivo al successivo che viene continuamente aggiornato nel caso l anello venga riconfigurato per l aggiunta o rimozione di eventuali altri manager). Richiede a quest'ultimo il vettore degli ID delle modifiche ritrasmettendo eventuali modifiche perse, escludendo così, di fatto, il manager caduto (da notare che questo protocollo è simile al protocollo di unjoin, con al differenza che non vi è il messaggio iniziale di richiesta, ma è il manager precedente che accortosi della non operatività del manager fa partire il protocollo). Ovviamente tutte le operazioni in corso al manager caduto dovranno riprendere su un altro manager: è il middleware lato cliente che persa la connessione con il manager cercherà un manager alternativo (locazione anch essa contenuta nel file di configurazione e aggiornata a run-time da parte del manager mediante meccanismi di piggybacking). Questo meccanismo garantisce la massima operatività grazie all assunzione esemplificativa di guasto singolo dei server. Un ultima riflessione merita l argomento della concorrenza: l intera architettura server è stata concepita cercando di assicurare un livello ottimo di concorrenza gestendo ogni operazione in maniera transazionale e garantendo quindi le proprietà A.C.I.D. mediante l uso di metodi synchronized e di opportuni meccanismi di rollback, ad esempio nel caso di trasferimenti falliti. 10

11 8. SCALABILITÀ Un alto grado di scalabilità in un servizio come il file hosting è decisivo. Infatti, sia la capacità di memorizzazione, che il numero di richieste simultanee aumentano in maniera quasi esponenziale al crescere del numero di utenti che utilizzano il servizio. Questo problema è stato preso in considerazione fin dall inizio nel progetto, codificando tutta l architettura server in un livello di controllo (manager) e uno di storage (data server). Infatti, variando il numero di macchine che eseguono i data server e i manager server è possibile ottenere ogni livello di potenza (in termini di capacità di memorizzazione e di gestione di richieste simultanee) desiderato. È compito dei manager gestire l ingresso e l uscita di data server in maniera che siano tutti utilizzati al loro massimo potenziale, mostrando invece all utente una visione trasparente dell architettura server, mentre il compito di distribuire il carico sui manager server è rimandato al middleware (ispirato al modello degli smart proxy) in modo che questi scelgano il manager al quale richiedere il servizio seguendo delle politiche più o meno dinamiche: ad esempio attraverso politiche basate sulla località (dividere i clienti in zone geografiche e quindi il manager è responsabile di servire quella determinata zona) o delle politiche statiche in cui in fase di distribuzione del middleware a ciascuno di essi è assegnato in maniera statica un manager, attraverso una politica round robin, ad esempio, o qualsiasi altra politica che ci può venire in mente. I client operano in maniera trasparente rispetto all architettura server, questo perché il middleware esporta loro una semplice interfaccia con le tre primitive delle operazioni fondamentali, oscurando i meri dettagli delle comunicazioni. Nel progetto è stato implementato un middleware per applicazioni grafiche e threadsafe; è tuttavia possibile, implementando l interfaccia base, realizzare versioni alternative sia a livello locale sia nella comunicazione con l architettura server, anche grazie all approccio al provider model adottato nella realizzazione del componente. Inoltre all interno di questo middleware è stato implementato la logica per la gestione del load-balancing dei manager: è compito del middleware decidere a quale manager connettersi, avendo a disposizione una lista di manager, che potrebbe essere aggiornata a runtime attraverso pacchetti di piggybacking inviati dai manager durante l ultima sessione (meccanismi ispirati agli smart proxy utilizzati in j-boss), meccanismo non implementato nella infrastruttura sviluppata in quest articolo. 10. COMPLESSITÀ Ora facciamo delle considerazioni riguardanti l overhead di comunicazione durante le varie operazioni, dovute alla gestione della struttura. Indicando con N il numero di manager server partecipanti al sistema e M il numero di data server registrati verso un generico manager, abbiamo: 9. CLIENT Il client distribuito nel progetto è realizzato come un applicazione grafica che consente di eseguire le operazioni di download, upload e lista file remoti. E possibile però costruire diversi client, magari all interno di applicazioni più complesse, inglobando queste funzionalità grazie al middleware di supporto progettato. 11

12 per ogni operazione di aggiunta file occorrono nel complesso sette messaggi scambiati tra client, manager e data server: Cliente Manager Data Richiesta Loc. DS Ack UP compl. Trasf. file in più sono inviati sulla rete 2*(N 1) messaggi contenente l informazione dell aggiunta nel file system e rispettivi ack scambiati fra gli N manager. per ogni operazione di rimozione file sono inviati sempre 2*(N-1) messaggi tra imanager; 2*R messaggi (dove R è il numero di repliche dove il file risiede) tra manager e data server dove risiede realmente il file; un messaggi di richiesta e risposta tra client e manager, per un totale di 2*(N-1+R) + 2: informazioni di carico di tutti i data server partecipanti; messaggi di controllo dell operatività di ciascun server, sia esso manager che data: come per gli aggiornamenti di stato abbiamo M+N messaggi di heartbeat; per quanto riguarda invece il protocollo di join abbiamo un messaggio di richiesta, 2*Q messaggi di modifica del file system, in relazione alla quantità di modifiche che il nuovo manager deve ricevere per sincronizzarsi con gli altri manager e rispettivi ack. In più abbiamo due messaggi contenente la locazione del manager da inviare sia al manager che vuole registrarsi, sia al manager successivo, ed inoltre un messaggio di richiesta del nuovo manager verso il manager successivo e rispettivo messaggio di ack per il nuovo collegamento: in totale 2*Q+7 Precedente Nuovo Cliente Successivo Ric. join Richiesta Sinc. FS Manager InfoJoin Ack Data Richiesta Rimozione file Ack Ovviamente tutti i protocolli possono subire dei malfunzionamenti, per cui si possono avere delle ritrasmissioni o, nei casi peggiori, dei fallimenti con i dovuti rollback per mantenere il sistema consistente. per gli aggiornamenti sul carico dei vari server sono inviati nel complesso M+N messaggi: M messaggi inviati tra data server e i rispettivi manager server di gestione, e N messaggi per attraversare tutto l anello dei manager partecipanti; in questo modo tutti i manager server hanno 11. CONCLUSIONI E SVILUPPI FUTURI E stata progettata un architettura client/server in grado di gestire un servizio di file hosting affidabile, disponibile e scalabile, garantendo agli utenti la maggior QoS percepita 12

13 possibile in base alle risorse disponibili nell architettura server. Nei test eseguiti su rete locale, si è notato un buon grado di loadbalancing e di affidabilità; è stata osservata anche una risposta sufficientemente rapida a eventi negativi come la caduta di un nodo. E possibile tuttavia tarare questi parametri prestazionali modificando il file di configurazione Config.XML che consente di bilanciare il rapporto costo-prestazioni del sistema in proporzione alle necessità dell amministratore e delle risorse disponibili. Sono molte le estensioni possibili all infrastruttura presentata, ma le principali riguardano la sicurezza. Infatti, non è stato previsto alcun meccanismo di autenticazione e autorizzazione. Potrebbe invece essere utile inserire tali meccanismi sia a livello della comunicazione client server che in quella interna all applicazione server. Per quanto riguarda il primo caso, sarebbe così possibile risalire al proprietario di un file, poterne avere di privati, modificarli o cancellarli e consentire solo agli utenti autorizzati l uso del servizio. Nel secondo caso invece il problema è più subdolo: infatti, non essendoci meccanismi di autenticazione e autorizzazione, chiunque in possesso del codice eseguibile può spacciarsi per manager o data server, ponendosi così nella posizione di portare attacchi di pericolosità crescente alle diverse macchine server legali nonché ai client che possono essere indotti a scaricare file pericolosi invece di ciò che realmente volevano ottenere. Sarebbe utile anche poter disporre di un servizio di nomi che consenta ai client di localizzare in maniera trasparente il proprio manager all interno dell infrastruttura. In alternativa, come visto nel capitolo precedente, si potrebbe aggiornare la lista dei manager nel middleware di supporto mediante piggybacking e quindi implementare politiche dinamiche per fare load-balancing dei manager. 13

Un infrastruttura di supporto per servizi di file hosting

Un infrastruttura di supporto per servizi di file hosting Un infrastruttura di supporto per servizi di file hosting Università degli Studi di Bologna Laurea Specialistica in Ingegneria Informatica Reti di Calcolatori LS Prof. A. Corradi A.A. 2006/2007 Matteo

Dettagli

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY Giampiero Allamprese 0000260193 PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY Reti di Calcolatori LS prof. Antonio Corradi A.A. 2007/2008 ABSTRACT L obiettivo di questo progetto è la realizzazione

Dettagli

Parte II: Reti di calcolatori Lezione 9

Parte II: Reti di calcolatori Lezione 9 Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14 Pietro Frasca Parte II: Reti di calcolatori Lezione 9 Martedì 1-04-2014 1 Applicazioni P2P

Dettagli

Music Everywhere with BT

Music Everywhere with BT Music Everywhere with BT Acquaviva Luca 231767 luca.acquaviva@studio.unibo.it Colombini Gabriele 231491 gabriele.colombini@studio.unibo.it Manservisi Alberto 258370 alberto.manservisi@studio.unibo.it Abstract

Dettagli

BrightSync: progetto di un middleware di sincronizzazione per ambienti eterogenei

BrightSync: progetto di un middleware di sincronizzazione per ambienti eterogenei Corso di Laurea Specialistica in Ingegneria Informatica Reti di Calcolatori LS prof. Antonio Corradi BrightSync: progetto di un middleware di sincronizzazione per ambienti eterogenei di Emanuele Crescentini

Dettagli

Sistemi Operativi (modulo di Informatica II)

Sistemi Operativi (modulo di Informatica II) Sistemi Operativi (modulo di Informatica II) La comunicazione tra processi Patrizia Scandurra Università degli Studi di Bergamo a.a. 2008-09 Sommario Processi cooperanti La comunicazione tra processi Necessità

Dettagli

PROGETTI DISPONIBILI IL CORSO DI PROGETTO DI RETI E SISTEMI INFORMATICI

PROGETTI DISPONIBILI IL CORSO DI PROGETTO DI RETI E SISTEMI INFORMATICI PROGETTI DISPONIBILI IL CORSO DI PROGETTO DI RETI E SISTEMI INFORMATICI 1 Web Link Monitor... 2 2 Database Browser... 4 3 Network Monitor... 5 4 Ghost Site... 7 5 Copy Search... 9 6 Remote Audio Video

Dettagli

Svantaggi della Commutazione di Circuito. Commutazione di Pacchetto. Struttura di un Pacchetto

Svantaggi della Commutazione di Circuito. Commutazione di Pacchetto. Struttura di un Pacchetto Università degli studi di Salerno Laurea in Informatica I semestre / Commutazione di Pacchetto Prof. Vincenzo Auletta auletta@dia.unisa.it http://www.dia.unisa.it/professori/auletta/ Svantaggi della Commutazione

Dettagli

27/03/2013. Contenuti

27/03/2013. Contenuti Corso Sistemi Distribuiti 6 cfu Docente: Prof. Marcello Castellano Contenuti Virtualizzazione - 3 Macchina virtuale - 4 Architetture delle macchine virtuali - 6 Tipi di virtualizzazione - 7 Monitor della

Dettagli

La Document Orientation. Come implementare un interfaccia

La Document Orientation. Come implementare un interfaccia La Document Orientation Come implementare un interfaccia Per eliminare l implementazione di una interfaccia da parte di una classe o documento, occorre tirarla su di esso tenendo premuto il tasto ctrl.

Dettagli

Il clustering. Sistemi Distribuiti 2002/2003

Il clustering. Sistemi Distribuiti 2002/2003 Il clustering Sistemi Distribuiti 2002/2003 Introduzione In termini generali, un cluster è un gruppo di sistemi indipendenti che funzionano come un sistema unico Un client interagisce con un cluster come

Dettagli

Sistemi Web Tolleranti ai Guasti

Sistemi Web Tolleranti ai Guasti Sistemi Web Tolleranti ai Guasti Candidato: Paolo Romano Relatore: Prof. Salvatore Tucci Correlatore: Prof. Bruno Ciciani Sommario Il problema: garantire semantica exactly once alle transazioni Web. Sistema

Dettagli

File System Distribuiti

File System Distribuiti File System Distribuiti Introduzione Nominazione e Trasparenza Accesso ai File Remoti Servizio Con/Senza Informazione di Stato Replica dei File Un esempio di sistema 20.1 Introduzione File System Distribuito

Dettagli

Introduzione. File System Distribuiti. Nominazione e Trasparenza. Struttura dei DFS. Strutture di Nominazione

Introduzione. File System Distribuiti. Nominazione e Trasparenza. Struttura dei DFS. Strutture di Nominazione File System Distribuiti Introduzione Nominazione e Trasparenza Accesso ai File Remoti Servizio Con/Senza Informazione di Stato Replica dei File Un esempio di sistema Introduzione File System Distribuito

Dettagli

Supporto per servizi di File Hosting

Supporto per servizi di File Hosting Supporto per servizi di File Hosting Progetto per il corso di Reti di Calcolatori LS a.a 2005-2006 Valerio Guagliumi 0000236769 Abstract Questa relazione descrive il progetto realizzato di un sistema di

Dettagli

Sistemi Distribuiti. Informatica B. Informatica B

Sistemi Distribuiti. Informatica B. Informatica B Sistemi Distribuiti Introduzione Che cos è un sistema distribuito? Un sistema distribuito è una collezione di computer indipendenti che appare all utente come un solo sistema coerente Da notare: le macchine

Dettagli

Cluster per architetture a componenti

Cluster per architetture a componenti Luca Cabibbo Architetture Software Cluster per architetture a componenti Dispensa ASW 442 ottobre 2014 Un buon progetto produce benefici in più aree. Trudy Benjamin 1 -Fonti [IBM] Clustering Solutions

Dettagli

1.1 - Crittografia sulla infrastruttura trasmissiva tra le stazioni remote Rilheva il centro di telecontrollo

1.1 - Crittografia sulla infrastruttura trasmissiva tra le stazioni remote Rilheva il centro di telecontrollo SISTEMA DI TELECONTROLLO RILHEVA GPRS (CARATTERISTICHE DEL VETTORE GPRS E SICUREZZE ADOTTATE) Abstract: Sicurezza del Sistema di Telecontrollo Rilheva Xeo4 ha progettato e sviluppato il sistema di telecontrollo

Dettagli

A cura di: Dott. Ing. Elisabetta Visciotti. e.visciotti@gmail.com

A cura di: Dott. Ing. Elisabetta Visciotti. e.visciotti@gmail.com A cura di: Dott. Ing. Elisabetta Visciotti e.visciotti@gmail.com Il termine generico rete (network) definisce un insieme di entità (oggetti, persone, ecc.) interconnesse le une alle altre. Una rete permette

Dettagli

Parte II: Reti di calcolatori Lezione 11

Parte II: Reti di calcolatori Lezione 11 Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2014-15 Parte II: Reti di calcolatori Lezione 11 Martedì 14-04-2015 1 Esempio di uso di proxy Consideriamo

Dettagli

SISTEMA DI PREFETCHING CLIENT-SIDE PER TRAFFICO WEB

SISTEMA DI PREFETCHING CLIENT-SIDE PER TRAFFICO WEB UNIVERSITÀ DEGLI STUDI DI ROMA TOR VERGATA Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica Progetto per il corso di Ingegneria del Web SISTEMA DI PREFETCHING CLIENT-SIDE PER

Dettagli

SISTEMI OPERATIVI DISTRIBUITI

SISTEMI OPERATIVI DISTRIBUITI SISTEMI OPERATIVI DISTRIBUITI E FILE SYSTEM DISTRIBUITI 12.1 Sistemi Distribuiti Sistemi operativi di rete Sistemi operativi distribuiti Robustezza File system distribuiti Naming e Trasparenza Caching

Dettagli

La sicurezza secondo skymeeting (data pubblicazione 06/12/2011)

La sicurezza secondo skymeeting (data pubblicazione 06/12/2011) La sicurezza secondo skymeeting (data pubblicazione 06/12/2011) www.skymeeting.net La sicurezza nel sistema di videoconferenza Skymeeting skymeeting è un sistema di videoconferenza web-based che utilizza

Dettagli

Reti di computer. Agostino Lorenzi - Reti di computer - 2008

Reti di computer. Agostino Lorenzi - Reti di computer - 2008 Reti di computer Telematica : termine che evidenzia l integrazione tra tecnologie informatiche e tecnologie delle comunicazioni. Rete (network) : insieme di sistemi per l elaborazione delle informazioni

Dettagli

Sincronizzazione e coordinamento nel distribuito

Sincronizzazione e coordinamento nel distribuito Sincronizzazione e coordinamento nel distribuito Sincronizzazione in sistemi centralizzati uso di primitive basate implicitamente sull esistenza della memoria condivisa Sincronizzazione in sistemi distribuiti

Dettagli

Di seguito ci accingiamo ad analizzare le possibili configurazioni di architettura: Server singolo

Di seguito ci accingiamo ad analizzare le possibili configurazioni di architettura: Server singolo La progettazione dell architettura si concentra sulla scelta dell hardware, dell infrastruttura di rete, e dei componenti software che andranno a costituire il sistema. Gli obbiettivi tecnologici che il

Dettagli

Table of Contents. Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano

Table of Contents. Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Table of Contents Definizione di Sistema Distribuito - 4 Obiettivi Principali di un S.D. - 7 Tipi di Sistemi

Dettagli

Architetture dei WIS. Definizione di WIS. Benefici dei WIS. Prof.ssa E. Gentile a.a. 2011-2012

Architetture dei WIS. Definizione di WIS. Benefici dei WIS. Prof.ssa E. Gentile a.a. 2011-2012 Architetture dei WIS Prof.ssa E. Gentile a.a. 2011-2012 Definizione di WIS Un WIS può essere definito come un insieme di applicazioni in grado di reperire, cooperare e fornire informazioni utilizzando

Dettagli

Introduzione. Livello applicativo Principi delle applicazioni di rete. Stack protocollare Gerarchia di protocolli Servizi e primitive di servizio 2-1

Introduzione. Livello applicativo Principi delle applicazioni di rete. Stack protocollare Gerarchia di protocolli Servizi e primitive di servizio 2-1 Introduzione Stack protocollare Gerarchia di protocolli Servizi e primitive di servizio Livello applicativo Principi delle applicazioni di rete 2-1 Pila di protocolli Internet Software applicazione: di

Dettagli

Table of Contents. Definizione di Sistema Distribuito 15/03/2013

Table of Contents. Definizione di Sistema Distribuito 15/03/2013 Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Table of Contents Definizione di Sistema Distribuito - 4-7 - 13 Definizioni e Principali Caratteristiche

Dettagli

SIDA Multisede online

SIDA Multisede online SIDA Multisede online Manuale tecnico per uso esclusivo dei tecnici installatori e della rete commerciale Sida By Autosoft Versione 2009.1.1 Revisione 1, 11 maggio 2009 Tutti i diritti sono riservati dagli

Dettagli

La Sicurezza delle Reti. La Sicurezza delle Reti. Il software delle reti. Sistemi e tecnologie per la multimedialità e telematica.

La Sicurezza delle Reti. La Sicurezza delle Reti. Il software delle reti. Sistemi e tecnologie per la multimedialità e telematica. Sistemi e tecnologie per la multimedialità e telematica Fabio Burroni Dipartimento di Ingegneria dell Informazione Università degli Studi di Siena burronif@unisi unisi.itit La Sicurezza delle Reti La presentazione

Dettagli

ALLEGATO 1 DESCRIZIONE DEL SERVIZIO

ALLEGATO 1 DESCRIZIONE DEL SERVIZIO ALLEGATO 1 DESCRIZIONE DEL SERVIZIO . IntrodDescrizione del Servizio a) Procedura di accreditamento Il Centro Servizi (CS) che richiede l accreditamento per la fornitura dell accesso fisico al Sistema

Dettagli

31/05/2013. Sistemi Web Distribuiti (parte 2) - Indice dei Contenuti - Naming. Corso Sistemi Distribuiti 6 cfu Docente: Prof. Marcello Castellano

31/05/2013. Sistemi Web Distribuiti (parte 2) - Indice dei Contenuti - Naming. Corso Sistemi Distribuiti 6 cfu Docente: Prof. Marcello Castellano Corso Sistemi Distribuiti 6 cfu Docente: Prof. Marcello Castellano /28 Sistemi Web Distribuiti (parte 2) - Indice dei Contenuti - Naming 3 Sincronizzazione 4 Consistenza e Replica 5 Replica di sistemi

Dettagli

Controllo remoto di SPEEDY

Controllo remoto di SPEEDY UNIVERSITÀ DI BRESCIA FACOLTÀ DI INGEGNERIA Dipartimento di Elettronica per l Automazione Laboratorio di Robotica Avanzata Advanced Robotics Laboratory Corso di Robotica (Prof. Riccardo Cassinis) Controllo

Dettagli

UBIQUITY 6 e Server. Il documento descrive le novità introdotte con la versione 6 della piattaforma software ASEM Ubiquity.

UBIQUITY 6 e Server. Il documento descrive le novità introdotte con la versione 6 della piattaforma software ASEM Ubiquity. UBIQUITY 6 e Server Privato Introduzione Il documento descrive le novità introdotte con la versione 6 della piattaforma software ASEM Ubiquity. Versione Descrizione Data 1 Prima emissione 21/06/2015 Disclaimer

Dettagli

10 argomenti a favore dell over IP

10 argomenti a favore dell over IP Quello che i fornitori di telecamere analogiche non dicono 10 argomenti a favore dell over IP Le telecamere di rete non sono certo una novità, infatti il primo modello è stato lanciato nel 1996. Nei primi

Dettagli

Sistemi Distribuiti. Libri di Testo

Sistemi Distribuiti. Libri di Testo Sistemi Distribuiti Rocco Aversa Tel. 0815010268 rocco.aversa@unina2.it it Ricevimento: Martedì 14:16 Giovedì 14:16 1 Libri di Testo Testo Principale A.S. Tanenbaum, M. van Steen, Distributed Systems (2

Dettagli

ICT (Information and Communication Technology): ELEMENTI DI TECNOLOGIA

ICT (Information and Communication Technology): ELEMENTI DI TECNOLOGIA ICT (Information and Communication Technology): ELEMENTI DI TECNOLOGIA Obiettivo Richiamare quello che non si può non sapere Fare alcune precisazioni terminologiche IL COMPUTER La struttura, i componenti

Dettagli

Internet e il World Wide Web. Informatica di Base A -- Rossano Gaeta 1

Internet e il World Wide Web. Informatica di Base A -- Rossano Gaeta 1 Internet e il World Wide Web 1 Domande chiave 2.1 Quali sono i mezzi di connessione a Internet e qual è la loro velocità? 2.2 Quali sono i tre tipi di provider Internet e quali tipi di servizi offrono?

Dettagli

Laboratorio del corso Progettazione di Servizi Web e Reti di Calcolatori Politecnico di Torino AA 2014-15 Prof. Antonio Lioy

Laboratorio del corso Progettazione di Servizi Web e Reti di Calcolatori Politecnico di Torino AA 2014-15 Prof. Antonio Lioy Laboratorio del corso Progettazione di Servizi Web e Reti di Calcolatori Politecnico di Torino AA 2014-15 Prof. Antonio Lioy Soluzioni dell esercitazione n. 2 a cura di Giacomo Costantini 19 marzo 2014

Dettagli

Utilizzare 4CBOX come centralino significa avere un sistema all inclusive oltre a

Utilizzare 4CBOX come centralino significa avere un sistema all inclusive oltre a Utilizzare 4CBOX come centralino significa avere un sistema all inclusive oltre a IVR risponditore, VoiceMail e gestione delle code operatore. Utilizzare oltre alle tradizionali linee telefoniche, anche

Dettagli

Testo Esame di Stato 2011-2012 YABC ESAME DI STATO DI ISTITUTO TECNICO INDUSTRIALE. CORSO SPERIMENTALE PROGETTO «ABACUS» Indirizzo: INFORMATICA

Testo Esame di Stato 2011-2012 YABC ESAME DI STATO DI ISTITUTO TECNICO INDUSTRIALE. CORSO SPERIMENTALE PROGETTO «ABACUS» Indirizzo: INFORMATICA A.S. 2011-2012 Testo Esame di Stato 2011-2012 YABC ESAME DI STATO DI ISTITUTO TECICO USTRIALE CORSO SPERIMETALE PROGETTO «ABACUS» Indirizzo: IFORMATICA Tema di: SISTEMI DI ELABORAZIOE E TRASMISSIOE DELLE

Dettagli

Capire i benefici di una rete informatica nella propria attività. I componenti di una rete. I dispositivi utilizzati.

Capire i benefici di una rete informatica nella propria attività. I componenti di una rete. I dispositivi utilizzati. LA RETE INFORMATICA NELL AZIENDA Capire i benefici di una rete informatica nella propria attività. I componenti di una rete I dispositivi utilizzati I servizi offerti LA RETE INFORMATICA NELL AZIENDA Copyright

Dettagli

Progetto RE.VE.N.GE. DDS con Fault-tolerance. del Sistema di Consegna

Progetto RE.VE.N.GE. DDS con Fault-tolerance. del Sistema di Consegna Progetto RE.VE.N.GE. DDS con Fault-tolerance del Sistema di Consegna Progetto di: Marco Livini, Luca Nardelli, Christian Pinto Reti di Calcolatori LS 08-09 Prof. Antonio Corradi, Ing. Luca Foschini Relazione

Dettagli

Algoritmi per protocolli peer-to-peer

Algoritmi per protocolli peer-to-peer Algoritmi per protocolli peer-to-peer Introduzione Livio Torrero (livio.torrero@polito.it) 09/2009 Approccio client-server (1/2) Client 1 Client 3 Server Client 2 Client 4 Paradigma molto comune Un client

Dettagli

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14. Pietro Frasca. Parte II Lezione 1

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14. Pietro Frasca. Parte II Lezione 1 Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14 Pietro Frasca Parte II Lezione 1 Martedì 4-03-2014 1 TESTO DI RIFERIMENTO RETI DI CALCOLATORI

Dettagli

INTEGRAZIONE ED ESPANSIONE DEL SISTEMA DI VIDEOSORVEGLIANZA DEL COMUNE DI CASTELLAMMARE DI STABIA TITOLO ELABORATO: MODULO ISOLE WI-FI HOT SPOT

INTEGRAZIONE ED ESPANSIONE DEL SISTEMA DI VIDEOSORVEGLIANZA DEL COMUNE DI CASTELLAMMARE DI STABIA TITOLO ELABORATO: MODULO ISOLE WI-FI HOT SPOT INTEGRAZIONE ED ESPANSIONE DEL SISTEMA DI VIDEOSORVEGLIANZA DEL COMUNE DI CASTELLAMMARE DI STABIA TITOLO ELABORATO: MODULO ISOLE WI-FI HOT SPOT INDICE 1. PREMESSA 4 2. ARCHITETTURA RETI MESH 5 3. DISPOSITIVI

Dettagli

Controllo I/O Costituito dai driver dei dispositivi e dai gestori dei segnali d interruzione.

Controllo I/O Costituito dai driver dei dispositivi e dai gestori dei segnali d interruzione. C6. REALIZZAZIONE DEL FILE SYSTEM Struttura del file system Un file è analizzabile da diversi punti di vista. Dal punto di vista del sistema è un contenitore di dati collegati tra di loro, mentre dal punto

Dettagli

Architettura dei sistemi di database

Architettura dei sistemi di database 2 Architettura dei sistemi di database 1 Introduzione Come si potrà ben capire, l architettura perfetta non esiste, così come non è sensato credere che esista una sola architettura in grado di risolvere

Dettagli

Capitolo 2 - parte 4. Corso Reti ed Applicazioni Mauro Campanella Como 2003

Capitolo 2 - parte 4. Corso Reti ed Applicazioni Mauro Campanella Como 2003 Capitolo 2 - parte 4 Corso Reti ed Applicazioni Mauro Campanella Como 2003 Agenda - Content Distribution Networks (CDN) - Peer to Peer M. Campanella Corso Reti ed Applicazioni - Como 2003 Cap 2-4 pag.

Dettagli

SCP: SCHEDULER LAYER. a cura di. Alberto Boccato

SCP: SCHEDULER LAYER. a cura di. Alberto Boccato SCP: SCHEDULER LAYER a cura di Alberto Boccato PREMESSA: Negli ultimi tre anni la nostra scuola ha portato avanti un progetto al quale ho partecipato chiamato SCP (Scuola di Calcolo Parallelo). Di fatto

Dettagli

Struttura in ambito jspm per garantire continuità di comunicazioni in caso di disastro

Struttura in ambito jspm per garantire continuità di comunicazioni in caso di disastro Struttura in ambito jspm per garantire continuità di comunicazioni in caso di disastro Premesse: Il sistema jspm per la protezione Civile sfrutta per comunicare il protocollo ip. Il protocollo ip. È a

Dettagli

Reti di calcolatori. Condivisione di risorse e comunicazione con gli altri utenti

Reti di calcolatori. Condivisione di risorse e comunicazione con gli altri utenti Reti di calcolatori Condivisione di risorse e comunicazione con gli altri utenti Reti di calcolatori Anni 70: calcolatori di grandi dimensioni, modello time-sharing, centri di calcolo Anni 80: reti di

Dettagli

Security-By-Contract: come usare software scaricato da internet sul proprio telefono senza pentirsene

Security-By-Contract: come usare software scaricato da internet sul proprio telefono senza pentirsene Security-By-Contract: come usare software scaricato da internet sul proprio telefono senza pentirsene Nicola Dragoni Fabio Massacci dragoni@disi.unitn.it Fabio.Massacci@unitn.it www.massacci.org Dipartimento

Dettagli

Processi di business sovra-regionali relativi ai sistemi regionali di FSE. Versione 1.0 24 Giugno 2014

Processi di business sovra-regionali relativi ai sistemi regionali di FSE. Versione 1.0 24 Giugno 2014 Processi di business sovra-regionali relativi ai sistemi regionali di FSE Versione 1.0 24 Giugno 2014 1 Indice Indice... 2 Indice delle figure... 3 Indice delle tabelle... 4 Obiettivi del documento...

Dettagli

Sistema di diffusione Audio/Video su streaming.

Sistema di diffusione Audio/Video su streaming. 1 Sistema di diffusione Audio/Video su streaming. IL Progetto. Il progetto illustrato nel seguito prevede mediante la tecnologia di streaming la diffusione di audio/video su misura del cliente al 100%,

Dettagli

IBM i5/os: un sistema progettato per essere sicuro e flessibile

IBM i5/os: un sistema progettato per essere sicuro e flessibile IBM i5/os garantisce la continua operatività della vostra azienda IBM i5/os: un sistema progettato per essere sicuro e flessibile Caratteristiche principali Introduzione del software HASM (High Availability

Dettagli

Indirizzi Internet e. I livelli di trasporto delle informazioni. Comunicazione e naming in Internet

Indirizzi Internet e. I livelli di trasporto delle informazioni. Comunicazione e naming in Internet Indirizzi Internet e Protocolli I livelli di trasporto delle informazioni Comunicazione e naming in Internet Tre nuovi standard Sistema di indirizzamento delle risorse (URL) Linguaggio HTML Protocollo

Dettagli

Soluzione di videosorveglianza Guida di installazione

Soluzione di videosorveglianza Guida di installazione Guida di installazione Introduzione Considerando che i video vengono registrati e archiviati per riferimento ormai da diverso tempo, non è più possibile considerare quella di sorveglianza una tecnologia

Dettagli

Tecnologie per il web e lo sviluppo multimediale. Reti di Calcolatori e Internet

Tecnologie per il web e lo sviluppo multimediale. Reti di Calcolatori e Internet Tecnologie per il web e lo sviluppo multimediale Reti di Calcolatori e Internet Luca Pulina Corso di Laurea in Scienze della Comunicazione Università degli Studi di Sassari A.A. 2015/2016 Luca Pulina (UNISS)

Dettagli

Reti basate sulla stack di protocolli TCP/IP

Reti basate sulla stack di protocolli TCP/IP Reti basate sulla stack di protocolli TCP/IP Classe V sez. E ITC Pacioli Catanzaro lido 1 Stack TCP/IP Modello TCP/IP e modello OSI Il livello internet corrisponde al livello rete del modello OSI, il suo

Dettagli

Evoluzione dei sistemi operativi (5) Evoluzione dei sistemi operativi (4) Classificazione dei sistemi operativi

Evoluzione dei sistemi operativi (5) Evoluzione dei sistemi operativi (4) Classificazione dei sistemi operativi Evoluzione dei sistemi operativi (4) Sistemi multiprogrammati! più programmi sono caricati in contemporaneamente, e l elaborazione passa periodicamente dall uno all altro Evoluzione dei sistemi operativi

Dettagli

Architettura SW Definizione e Notazioni

Architettura SW Definizione e Notazioni Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Stili Architetturali E. TINELLI Architettura SW Definizione e Notazioni Definizione ANSI/IEEE Std Std1471-2000

Dettagli

La piattaforma di lettura targhe intelligente ed innovativa in grado di offrire servizi completi e personalizzati

La piattaforma di lettura targhe intelligente ed innovativa in grado di offrire servizi completi e personalizzati La piattaforma di lettura targhe intelligente ed innovativa in grado di offrire servizi completi e personalizzati Affidabilità nel servizio precisione negli strumenti Chanda LPR Chanda LPR è una piattaforma

Dettagli

Programmazione modulare 2014-2015

Programmazione modulare 2014-2015 Programmazione modulare 2014-2015 Indirizzo: Informatica Disciplina: SISTEMI E RETI Classe: 5 A e 5 B Docente: Buscemi Letizia Ore settimanali previste: 4 ore (2 teoria + 2 laboratorio) Totale ore previste:

Dettagli

Content Distribution Networks Digital Rights Management

Content Distribution Networks Digital Rights Management Content Distribution Networks Digital Rights Management Angelo Duilio Tracanna LabOne Italia S.r.l. Amministratore Delegato angelo.tracanna@labone.net 23 Novembre 2005 LabOne Stati uniti Brasile Italia

Dettagli

Reti di Calcolatori IL LIVELLO RETE

Reti di Calcolatori IL LIVELLO RETE Reti di Calcolatori IL LIVELLO RETE D. Talia RETI DI CALCOLATORI - UNICAL 3-1 Il Livello RETE Servizi del livello Rete Organizzazione interna Livello Rete basato su Circuito Virtuale Livello Rete basato

Dettagli

Laboratorio di Informatica. Le reti telematiche e Internet

Laboratorio di Informatica. Le reti telematiche e Internet Le reti telematiche e Internet Lezione 6 1 Insieme di cavi, protocolli, apparati di rete che collegano tra loro computer distinti i cavi trasportano fisicamente le informazioni opportunamente codificate

Dettagli

OPTILOG. La soluzione Siemens per la gestione del magazzino in ambito farmaceutico. Pagina 1 Siemens IS IT MES Solutions

OPTILOG. La soluzione Siemens per la gestione del magazzino in ambito farmaceutico. Pagina 1 Siemens IS IT MES Solutions La soluzione Siemens per la gestione del magazzino in ambito farmaceutico Pagina 1 I requisiti di un WMS Certezza operativa Utilizzo pieno dell impianto Conoscenza dello stato impianto Riduzione dei costi

Dettagli

Nuove implementazioni La nuova release del TsGate apporta al protocollo numerose migliorie, sia generali che specifiche per ogni singolo modulo.

Nuove implementazioni La nuova release del TsGate apporta al protocollo numerose migliorie, sia generali che specifiche per ogni singolo modulo. Pro COMMERCIALE (La farmacia può decidere di accettare o meno l allineamento commerciale di un prodotto) ACCETTARE IL PRODOTTO SOSTI- TUTIVO (La farmacia può decidere di accettare o meno il prodotto sostitutivo)

Dettagli

Implementare iphone e ipad Gestione dei dispositivi mobili (MDM)

Implementare iphone e ipad Gestione dei dispositivi mobili (MDM) Implementare iphone e ipad Gestione dei dispositivi mobili (MDM) ios supporta la gestione MDM (Mobile Device Management) consentendo alle aziende di gestire implementazioni su larga scala di iphone e ipad

Dettagli

Capitolo 1: Architettura dei sistemi distribuiti Introduzione

Capitolo 1: Architettura dei sistemi distribuiti Introduzione Capitolo 1: Architettura dei sistemi distribuiti Introduzione Abbiamo visto come negli ultimi anni la crescita esponenziale del Web abbia in qualche modo portato allo sviluppo di servizi fortemente centralizzati,

Dettagli

Classificazione delle tecniche di accesso multiplo

Classificazione delle tecniche di accesso multiplo Classificazione delle tecniche di accesso multiplo Le tecniche di accesso multiplo si dividono in tre classi: Protocolli deterministici o senza contesa: evitano la possibilità che due utenti accedano al

Dettagli

CdL MAGISTRALE in INFORMATICA A.A. 2014-15 corso di Sistemi Distribuiti. 8. Le architetture (prima parte) Prof. S.Pizzutilo

CdL MAGISTRALE in INFORMATICA A.A. 2014-15 corso di Sistemi Distribuiti. 8. Le architetture (prima parte) Prof. S.Pizzutilo CdL MAGISTRALE in INFORMATICA A.A. 2014-15 corso di Sistemi Distribuiti 8. Le architetture (prima parte) Prof. S.Pizzutilo I Sistemi Distribuiti Un Sistema Distribuito è un insieme di processori indipendenti

Dettagli

D3.1 Documento di analisi della visualizzazione 3D in ambiente Cloud e relative problematiche

D3.1 Documento di analisi della visualizzazione 3D in ambiente Cloud e relative problematiche D3.1 Documento di analisi della visualizzazione 3D in ambiente Cloud e relative problematiche Il Cloud Computing La visualizzazione nella Cloud Problematiche Virtualizzazione della GPU Front end Virtualization

Dettagli

Ordinamento degli eventi. Lezione 11. Osservazioni. Relazione verificato prima. Cenni ai sistemi operativi distribuiti 3. Coordinazione distribuita

Ordinamento degli eventi. Lezione 11. Osservazioni. Relazione verificato prima. Cenni ai sistemi operativi distribuiti 3. Coordinazione distribuita Lezione 11 Cenni ai sistemi operativi distribuiti 3. Coordinazione distribuita Ordinamento degli eventi Un sistema monoprocessore Unico clock Unica memoria Ordinamento degli eventi Mutua esclusione Deadlock

Dettagli

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2014-15. Pietro Frasca. Parte II Lezione 1

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2014-15. Pietro Frasca. Parte II Lezione 1 Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2014-15 Parte II Lezione 1 Giovedì 5-03-2015 TESTO DI RIFERIMENTO RETI DI CALCOLATORI E INTERNET un

Dettagli

SISTEMI E RETI. Crittografia. Sistemi distribuiti e configurazione architetturale delle applicazioni WEB.

SISTEMI E RETI. Crittografia. Sistemi distribuiti e configurazione architetturale delle applicazioni WEB. SISTEMI E RETI Crittografia. Sistemi distribuiti e configurazione architetturale delle applicazioni WEB. CRITTOGRAFIA La crittografia è una tecnica che si occupa della scrittura segreta in codice o cifrata

Dettagli

Log Manager. 1 Connessione dell apparato 2. 2 Prima configurazione 2. 2.1 Impostazioni di fabbrica 2. 2.2 Configurazione indirizzo IP e gateway 3

Log Manager. 1 Connessione dell apparato 2. 2 Prima configurazione 2. 2.1 Impostazioni di fabbrica 2. 2.2 Configurazione indirizzo IP e gateway 3 ver 2.0 Log Manager Quick Start Guide 1 Connessione dell apparato 2 2 Prima configurazione 2 2.1 Impostazioni di fabbrica 2 2.2 Configurazione indirizzo IP e gateway 3 2.3 Configurazione DNS e Nome Host

Dettagli

AREA SERVIZI ICT. Servizi di hosting offerti dall'area Servizi ICT. Integrazione con l'anagrafica Unica di Ateneo. hosting.polimi.

AREA SERVIZI ICT. Servizi di hosting offerti dall'area Servizi ICT. Integrazione con l'anagrafica Unica di Ateneo. hosting.polimi. AREA SERVIZI ICT Servizi di hosting offerti dall'area Servizi ICT Integrazione con l'anagrafica Unica di Ateneo hosting.polimi.it Indice 1. Anagrafica unica di Ateneo... 4 1.1. Introduzione all anagrafica

Dettagli

TECNICO SUPERIORE PER IL SISTEMA INFORMATIVO AZIENDALE

TECNICO SUPERIORE PER IL SISTEMA INFORMATIVO AZIENDALE ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE INDUSTRIA E ARTIGIANATO TECNICO SUPERIORE PER IL SISTEMA INFORMATIVO AZIENDALE STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI DESCRIZIONE DELLA

Dettagli

Basi di Dati prof. A. Longheu. 5 Progettazione fisica

Basi di Dati prof. A. Longheu. 5 Progettazione fisica Basi di Dati prof. A. Longheu 5 Progettazione fisica Progettazione Fisica Per effettuare la progettazione fisica, ossia l implementazione reale del modello logico creato nella fase della progettazione

Dettagli

Vs Suite di Encryption

Vs Suite di Encryption Vs Suite di Encryption Introduzione Data at Rest Con il termine Data at Rest si intende qualsiasi tipo di dato, memorizzato in forma di documento elettronico (fogli di calcolo, documenti di testo, ecc.

Dettagli

CORSO EDA Informatica di base. Sicurezza, protezione, aspetti legali

CORSO EDA Informatica di base. Sicurezza, protezione, aspetti legali CORSO EDA Informatica di base Sicurezza, protezione, aspetti legali Rischi informatici Le principali fonti di rischio di perdita/danneggiamento dati informatici sono: - rischi legati all ambiente: rappresentano

Dettagli

Internet e il World Wide Web. Informatica Generale -- Rossano Gaeta 30

Internet e il World Wide Web. Informatica Generale -- Rossano Gaeta 30 Internet e il World Wide Web 30 Tecnologia delle Telecomunicazioni Uso di dispositivi e sistemi elettromagnetici per effettuare la comunicazione a lunghe distanze (telefoni, televisione, radio, etc) Comunicazione

Dettagli

RAMS: la gestione completa delle attività degli Istituti di Vigilanza e Sorveglianza

RAMS: la gestione completa delle attività degli Istituti di Vigilanza e Sorveglianza RAMS: la gestione completa delle attività degli Istituti di Vigilanza e Sorveglianza White Paper 1 Gennaio 2005 White Paper Pag. 1 1/1/2005 La gestione degli Istituti di Vigilanza e Sorveglianza L efficienza

Dettagli

Analisi dei Requisiti

Analisi dei Requisiti Analisi dei Requisiti Pagina 1 di 16 Analisi dei Requisiti Indice 1 - INTRODUZIONE... 4 1.1 - OBIETTIVO DEL DOCUMENTO...4 1.2 - STRUTTURA DEL DOCUMENTO...4 1.3 - RIFERIMENTI...4 1.4 - STORIA DEL DOCUMENTO...4

Dettagli

Progettazione di reti AirPort

Progettazione di reti AirPort apple Progettazione di reti AirPort Indice 1 Per iniziare con AirPort 5 Utilizzo di questo documento 5 Impostazione Assistita AirPort 6 Caratteristiche di AirPort Admin Utility 6 2 Creazione di reti AirPort

Dettagli

Classificazione delle applicazioni multimediali su rete

Classificazione delle applicazioni multimediali su rete Universita' di Verona Dipartimento di Informatica Classificazione delle applicazioni multimediali su rete Davide Quaglia a.a. 2006/2007 1 Sommario Architettura di riferimento Classificazione per funzionalità

Dettagli

ACCESSNET -T IP NMS. Network Management System. www.hytera.de

ACCESSNET -T IP NMS. Network Management System. www.hytera.de ACCESSNET -T IP NMS Network System Con il sistema di gestione della rete (NMS) è possibile controllare e gestire l infrastruttura e diversi servizi di una rete ACCESSNET -T IP. NMS è un sistema distribuito

Dettagli

Progettazione: Tecnologie e ambienti di sviluppo

Progettazione: Tecnologie e ambienti di sviluppo Contratto per l acquisizione di servizi di Assistenza specialistica per la gestione e l evoluzione del patrimonio software della Regione Basilicata. Repertorio n. 11016 del 25/09/2009 Progettazione: Tecnologie

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2010/2011 Questi lucidi sono stati prodotti sulla

Dettagli

Per essere inviato il dato deve essere opportunamente codificato in modo da poter essere trasformato in SEGNALE, elettrico oppure onda luminosa.

Per essere inviato il dato deve essere opportunamente codificato in modo da poter essere trasformato in SEGNALE, elettrico oppure onda luminosa. La trasmissione dell informazione N.R2 La comunicazione tra due calcolatori si realizza tramite lo scambio di dati su un canale di comunicazione, esiste quindi un TRASMETTITORE che invia dei dati e un

Dettagli

1. Caratteristiche generali

1. Caratteristiche generali Allegato 1 (articolo 1, comma 1) ISTRUZIONI TECNICHE DI CUI AL DECRETO N. 108 DEL 11 MAGGIO 2015 1. Caratteristiche generali Premessa Il nucleo informativo dell AIA è costituito dalla Banca Dati Sinistri

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2008/2009 Questi lucidi sono stati prodotti sulla

Dettagli

Distribuire iphone e ipad Gestione dei dispositivi mobili (MDM)

Distribuire iphone e ipad Gestione dei dispositivi mobili (MDM) Distribuire iphone e ipad Gestione dei dispositivi mobili (MDM) ios supporta la gestione MDM (Mobile Device Management) dei dispositivi mobili, che consente alle aziende di gestire distribuzioni di iphone

Dettagli

SUITE PROTOCOLLI TCP/IP ( I protocolli di Internet )

SUITE PROTOCOLLI TCP/IP ( I protocolli di Internet ) PARTE 2 SUITE PROTOCOLLI TCP/IP ( I protocolli di Internet ) Parte 2 Modulo 1: Stack TCP/IP TCP/IP Protocol Stack (standard de facto) Basato su 5 livelli invece che sui 7 dello stack ISO/OSI Application

Dettagli

CLOUD COMPUTING. Che cos è il Cloud

CLOUD COMPUTING. Che cos è il Cloud CLOUD COMPUTING Che cos è il Cloud Durante la rivoluzione industriale, le imprese che si affacciavano per la prima volta alla produzione dovevano costruirsi in casa l energia che, generata da grandi macchine

Dettagli

Corsi di Reti di Calcolatori (Docente Luca Becchetti)

Corsi di Reti di Calcolatori (Docente Luca Becchetti) Corsi di Reti di Calcolatori (Docente Luca Becchetti) NOT : le soluzioni proposte sono volutamente sintetiche. Lo studente dovrebbe fare uno sforzo per risolvere i quesiti in modo autonomo, espandendo

Dettagli