Tazio: Una Memoria Software Transazionale Distribuita affidabile per Java

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Tazio: Una Memoria Software Transazionale Distribuita affidabile per Java"

Transcript

1 Tazio: Una Memoria Software Transazionale Distribuita affidabile per Java Andrea Reale ABSTRACT La diffusione rapida di applicazioni distribuite rende necessario lo sviluppo di modelli e tecniche che permettano la comunicazione e l interazione affidabile di processi dislocati su nodi diversi. L astrazione di memoria condivisa distribuita offre una possibile soluzione al requisito di condivisione di informazioni tra le parti di un sistema, ma espone il programmatore all obbligo di soddisfare complessi requisiti di sincronizzazione nell accesso ai dati comuni. Una logica d accesso basato su transazioni può sollevare da questo onere, permettendo il lavoro concorrente e validandone i risultati solo in un secondo momento. Sarà illustrata una implementazione di memoria condivisa distribuita con accesso a semantica transazionale (DSTM) pensata e progettata per garantire un servizio ad alta affidabilità tramite tecniche di clustering. 1. INTRODUZIONE Tazio è un sistema di memoria software transazionale distribuita (DSTM - Distributed Shared Transactional Memory) per sistemi Java pensato per l alta disponibilità e la tolleranza ai guasti e capace di supportare un elevato numero di processi che lavorino contemporaneamente sulla memoria. Obiettivo primario è permettere allo sviluppatore di applicazioni distribuite di condividere informazioni e lavorare su di esse in maniera semplice, offrendogli una astrazione che sia il più possibile vicina a quella di un ambiente Java locale, e proteggendolo da problemi di accesso concorrente grazie all utilizzo di transazioni. L unità di memoria di base è l oggetto Java, e l accesso al suo stato - che avviene tramite gli usuali metodi getter e setter - è reso implicitamente transazionale e disponibile a tutti i clienti del sistema. Aspetto cruciale è il modo in cui tazio gestisce la replicazione della memoria coordinando le transazioni che su di essa avvengono in maniera distribuita: normalmente in una memoria transazionale, tutti i partecipanti prendono parte ad un protocollo di commit atomico per garantire che operazioni concorrenti sulla memoria siano serializzate in maniera consistente: questo porta ad un notevole degrado delle prestazioni quando i processi partecipanti sono numerosi, soprattutto nel caso in cui sia difficile garantire la correttezza e monitorare le prestazioni di tutti. Il sistema proposto affronta questo problema differenziando le garanzie che offre rispetto alla vista della memoria condivisa, in base a due diversi tipi di processi (Replica Manager e Weak Replica Manager). Tazio è inoltre pensato per garantire in maniera nativa alta disponibilià del servizio e resistenza ai guasti, facendo uso di tecniche di clustering ed esplorando un protocollo di terminazione delle transazioni alternativo ai tradzionali protocolli di commit atomico (e.g. 2PC), pensato specificamente per transazini su oggetti replicati. Il documento è organizzato come segue: nella sezione 2 verranno velocemente elencate le assunzioni alla base del failure model del sistema; nella sezione 3 verranno illustrati i concetti e i principi dell architettura del sistema; nella sezione 4 verrà illustrata la scomposizione in parti e responsabilità di tazio, mentre nelle sezioni 5 e 6 saranno dettagliate le sottoporti relative rispettivamente alle comunicazioni client-server e alla gestione delle transazioni, sviluppate da me. Infine nella sezione 7 saranno riportati i risultati dei test sul sistema e nella sezione 8 saranno illustrati possibili sviluppi ed espansioni. 2. ASSUNZIONI In questa breve sezione sono elencate le assunzioni fatte sulle modalità di fallimento delle parti del sistema. Tali assunzioni sono da ritenersi verificate in ogni altra parte del documento e sono necessarie affinché il sistema presenti il comportamento descritto in seguito. Failure dei processi. Tutti i processi del sistema falliscano solo in seguito a crash, e sono completamente immuni da fallimenti di tipo bizantino. I processi andati in crash potranno essere eventualmente ripristinati e tornare a partecipare al sistema. Failure della rete. Il canale di comunicazione tra i RM facenti parte del cluster, è un canale affidabile che garantisca che un messaggio sia consegnato a tutti i processi corretti. In questo momento non si fa nessuna assunzione sull ordinamento dei messaggi, anche e si vedrà come sarà necessario introdurle per la realizzazione del protocollo di commit distribuito. Al contrario non si fa alcun tipo di assunzione riguardo al canale di comunicazione che collega i Weak Replica Manager tra di loro e con i Replica Manager. In questo tipo di comunicazione i messaggi possono essere persi, ritardati e disordinati a piacimento. 3. CONCETTI DI BASE La memoria condivisa di Tazio è organizzata intorno al concetto di Share che definisce il contenitore concettuale in cui vengono memorizzati e resi disponibili gli oggetti condivisi. Esso rappresenta il punto d accesso al sistema per

2 oggetti che legge o scrive, e prima che possa effettuare il commit deve superare una fase di validazione in cui sono rilevati eventuali conflitti con transazioni concorrenti. Per un Replica Manager corretto è garantito che tutte le operazioni effettuate sugli oggetti che esso replica avvengono con semantica strettamente transazionale se una transazione viene eseguita sulla sua memoria, quella stessa transazione verrà eseguita anche da tutti gli altri Replica Manager corretti del sistema Figure 1: Tazio: schematic architecture chiunque voglia usufrirne dei servizi: permette di aggiungere alla memoria nuovi oggetti, recuperare oggetti condivisi da altri clienti, ed eventualmente eliminarli. Lo sviluppatore che voglia usare il servizio deve definire un interfaccia per gli oggetti che vuole utilizzare, e tramite l utilizzo di apposite annotazioni, indicare al sistema quali sono le proprietà per le quali desidera un accesso transazionale. A runtime, la creazione delle istanze di tali oggetti dovrà essere affidata al sistema: questo utilizzerà una implementazione fornitagli dallo sviluppatore, arricchendola con la logica transazionale richiesta tramite l utilizzo di proxy dinamici; automaticamente l oggeto creato sarà aggiunto allo Share. Lo stato dello Share così come quello degli oggetti in esso contenuti, viene mantenuto da un cluster di processi server - i Replica Managers - ciascuno dei quali replica localmente l intera memoria, e si coordina con il resto del gruppo al fine di mantenere la propria copia in uno stato sempre consistente tramite l uso di un protocollo di commit per le transazioni appositamente studiato (vedi sezione 6.2). Alla memoria possono accedere processi client, che forniscono all utilizzatore accesso agli oggetti condivisi e interfaccie per il controllo e la gestione delle transazioni. Tali processi - denominati Weak Replica Manager - non sono direttamente coinvolti nel protocollo di commit atomico sopra citato: in questo modo i server sono liberati dall onere di dover contattare e gestire un numero possibilmente alto di nodi durante la coordinazione per il commit di transazioni (vedi fig. 1. Benché la semantica delle operazioni sulla memoria dal punto di vista dei client non sia strettamente transazionale, il sistema riesce comunque a garantire che tutte le operazioni vengano effettuate su una vista dei dati aggiornata, o che in caso contrario le transazioni che le coinvolgono falliscano. In particolare due diversi insiemi di asserzioni sono garantite riguardo alla consistenza delle copie degli oggetti, sulla base della categoria di processo. Replica Manager Un RM è responsabile di mantenere una copia sempre aggiornata della memoria condivisa e di gestire e rispondere alle richieste di oggetti condivisi da parte dei clienti del sistema. Le transazioni in ogni RM sono gestite sfruttando un protocollo di controllo dei conflitti ottimistico basto sul versioning: ogni transazione agisce su uno snapshot locale degli tutte le transazioni che esso vede, arrivano e sono validate nello stesso ordine di quello visto da ogni altro Replica Manager del sistema. In base a queste assunzioni è facile dimostrare che il gruppo di Replica Managers manterrà uno stato di replicazione in ogni istante consistente (così assicurando la proprietà di one copy serializability), a patto che tutti partano dallo stesso stato iniziale della memoria. Weak Replica Manager Con Weak Replica Manager (WRM) si identifica il componente software utilizzato dalle applicazioni che vogliono accedere al servizio di DSTM. Generalmente un WRM è fisicamente collocato sullo stesso nodo in cui risiede l applicazione che ne fa uso, e può essere visto da essa come una replica locale della memoria offerta dal cluster di RM. Tutti gli accessi alla memoria da parte di un WRM devono avvenire nel contesto di una transazione: l API fornita allo sviluppatore permette di gestire manualmente i suoi confini, ed in caso questo non avvenga il sistema si preoccupa di crearne una ed associarla al thread che vuole accedere ad un oggetto condiviso. Transazioni concorrenti sullo stessa istanza di WRM sono serializzate attraverso l uso di un protocollo simile a quello usato dai Replica Managers: in questo modo i potenziali conflitti tra accessi locali sono rilevati durante una prima fase di validazione. Le transazioni che sopravvivono a questa fase dovranno poi essere validate globalmente dal cluster prima di essere applicate sulla memoria, controllando che esse non confliggano con altre originate da altri nodi. Per un istanza di Weak Replica Manager corretta sono fatte le seguenti garanzie: se un WRM riesce a completare una transazione con successo, allora quella transazione sarà stata completata con successo anche dal gruppo dei RMs una transazione avviata da un WRM non ha mai successo se essa lavora su copie di oggetti non aggiornati rispetto allo stato dei RMs un WRM riceve prima o poi notifica delle modifiche allo stato degli oggetti che avvengono sui RMs da parte del sistema di cache (vedi sezione 4). Si noti che se è vero che il commit di una transazione lato WRM implichi il commit della stessa su RMs, non è garantito che sia vero il contrario: è infatti possibile che una transazione iniziata da un WRM sia completata con successo dai RMs, ma che fallisca sul WRM che l ha iniziata (ad esempio perchè viene perso qualche messaggio scambiato tra WMR e RM - si veda la sezione 2); questa è la violazione principale

3 Figure 2: Struttura di un RM Figure 3: Struttura di un WRM alla semantica transazionale lato Weak Replica Manager, ed è conseguenza diretta della scelta di tener fuori i processi di questo tipo dal protocollo di commit atomico. 4. ORGANIZZAZIONE DEL SISTEMA Nelle figure 2 e 3 è illustrata la scomposizione in sottopoarti di Replica Manager e Weak Replica Manager. Ciascuna delle parti è pensata per assolvere una precisa responsabilità e collabora con le altre per realizzare le funzionalità richieste dal servizio; in questa sezione sarà illustrato brevemente il razionale dietro ciascun layer, e nelle due sezioni successive (5 e 6) verranno dettagliati i sottosistemi di comunicazione client-server (tazio-networking) e di gestione delle transazioni (tazio-transactions). tazio-networking. Realizza la logica di comunicazione tra WRMs e RMs, secondo un modello Client / Server. Obiettivo del sottosistema è fornire un implementazione di server TCP che sia capace di scalare in maniera soddisfacente rispetto al numero di connessioni gestite. Ulteriori dettagli saranno forniti nella sezione 5. tazio-transparency. Ha l obiettivo di realizzare un astrazione uniforme rispetto alle diverse forme di comunicazione per i sottosistemi di più alto livello. Le sue responsabilità possono essere ulteriormente scomposte in tre distinte parti. Group Service: incapsula la logica di comunicazione di gruppo tra i Replica Manager - reallizzata sfruttando JGroups [1] - e si occupa dei problemi relativi alla sua gestione (modifica dinamica della membership del gruppo, network partitions, ecc..). Transparency Layer: si preoccupa di rendere trasparenti le comunicazioni tra WRM e RM, rispetto alla repli- cazione di questi ultimi. In particolare gestisce l eventualità che uno di questi diventi irragiungibile, e - ove permesso dalla logica applicativa - dirotta i messaggi verso un altro RM disponibile. Dispatching Layer: fornisce un servizio ai sottosistemi di più alto livello, permettendo loro di registrarsi per la notifica della ricezione di messaggi in base al loro tipo, e si preoccupa di smistare i loro messaggi al destinatario (remoto o locale) più aprropriato. tazio-ril. Implementa un semplice sistema di RMI tra oggetti remoti che sia capace di sfruttare nativamente la natura replicata del sistema. Lato WRM pemette - sfruttando delle apposite annotazioni - di invocare un metodo su un oggetto remoto localizzato su un RM specificando il tipo di comportamento desiderato rispetto alla replicazione: Invocazione su al più un RM : prova ad eseguire l invocazione sull oggetto remoto desiderato, cercandolo su uno degli RM. In caso di mancata risposta l invocazione fallisce. Invocazione su almeno un RM : prova ad eseugiore l invocazione sull oggetto remoto desiderato, provando prima su un RM ed in caso di mancata risposta prova a rieseguire l invocazione su un diverso RM. Lato RM permette di invocare metodi su un oggetto remoto replicato su tutti i membri del cluster: tale invocazione avviene una volta su ogni replica, e non prevede valori di ritorno. tazio-caching. Si occupa di far sì che le copie degli oggetti condivisi possedute dai WRM siano aggiornate rispetto a quelle degli

4 RM, quando queste sono modificate da transazioni originate da nodi diversi. Realizzando un proxy dinamico intorno alle copie di oggetti condivisi, ne gestisce l invalidazione e l aggiornamento secondo due diversi possibili protocolli (write-update o write-invalidated) tazio-transactions. Realizza la logica transazionale del sistema, comprendendo la gestione della memoria condivisa, l implementazione dei protocolli di controllo di concorrenza per le transazioni, la coordinazione tra WRM e RM nell accesso agli oggetti condivisi, fino alla realizzazione del protocollo di commit atomico utilizzato dal cluster di RM per garantire la correttezza del sistema. Per ulteriori dettagli si veda la sezione TAZIO-NETWORKING Come accennato nella sezione precedente, scopo del sottosistema di C/S networking è implementare un server basato su TCP che sia in grado di gestire un largo numero di connessioni, e di scalare in maniera adeguata all aumentare di queste. Un ulteriore requisito fondante che sta alla base della realizzazione di questo componente è il desiderio di fornire un componente riutilizzabile indipendentemente dal protocollo applicativo utilizzato, e il cui comportamente fosse ampiamente configurabile a seconda dello scenario d suo. In tazio questo componente viene utilizzato principalmente sui Replica Managers per gestire le richieste provenienti dai WRM. Data la natura del sistema, pensato per essere utilizzato da una grande quantità di clienti contemporaneamente, era necessario evitare che si avesse un primo collo di bottaglia a partire dal request handling. Una versione leggera di questo componente gira anche su ogni Weak Replica Manager per permettere al sottosistema di cache di contattarli e notificare loro le eventuali invalidazioni di oggetti condivisi. La scelta di utilizzare TCP come protocollo di comunicazione tra i WRM e gli RM nasce dall analisi dello scenario di deployment tipico per cui il sistema è pensato: un cluster di RM geograficamente vicini (verosimilmente nella stessa LAN), contattati da un numero elevato di WRM sulla cui locazione non si fa nessuna assunzione. Le garanzie che TCP offre riguardo alla consegna e all ordinamento dei messaggi, sebbene non strettamente necessarie per la correttezza del sistema (vedi sezione 6), rappresentano una comoda assunzione di partenza: in questo modo, ad esempio, il sistema può rilevare quando un messaggio non è consegnabile al suo destinatario, ed in tal caso provvedere se necessario a reindirizzarlo ad un altra replica nel cluster. Per soddisfare il requisito di scalabilità rispetto al numero di connessioni, utilizzare il classico schema thread-persocket sarebbe stato largamente inefficiente: all aumentare delle connessioni, ed in modo proporzionale dei thread dedicati a gestirli, si introdurrebbe un pesante collo di bottiglia rappresentato dallo scheduling dei thread. Anziché dedicare un thread all ascolto bloccante di eventi su ogni socket, tazio utilizza uno schema basato sull idea di socket non bloccanti, introdotte dal framework Java NIO [6, 4] : un thread si blocca in attesa di connessioni su una ServerSocket e, una volta creata una Socket connessa con un client, registra il canale ad essa associata su un oggetto dedicato al dispaching delle richieste. Il dispatcher, a sua volta, possiede un thread di controllo che sfrutta il servizio di demultiplexing offerto dal sistema operativo ospite (e.g. la select() nei s.o. unix) per essere notificato di eventi sui canali che gestisce. All arrivo Figure 4: Layout del sottosistema di networking di dati su un canale, poi, metterà in esecuzione un handler utilizzando un thread proveniente da un pool di dimensioni limitate. All handler spetterà di gesitre i dati in ingresso secondo la sua logica ed eventualmente generare una risposta. (Vedi figura 4) Vista la natura a stream delle socket non bloccanti, ovviamente non è detto che all handler associato ad una socket arrivi volta per volta un messaggio intero: in linea di principio spetta a lui bufferizzare i dati ricevuti e riconoscere, a seconda del protocollo applicativo che utilizza, un messaggio completo. Questo può risultare complicato e fastidioso da fare a livello di codice applicativo: siccome il sistema presuppone che i messaggi scambiati siano incapsulati in oggetti java, è stato previsto un handler astratto che gestisce la ricezione e la deserializzazione di oggetti, e che i componenti di più alto livello possono estentedere per aggiungere la loro logica di protocollo. Dualmente sono stati previste delle classi lato cliente che gestiscono la serializzazione dei messaggi da inviare. Ultima caratteristica che vale la pena citare è il fatto che l handler astratto appena citato può essere configurato per ricevere e inviare messaggi compressi utilizzando gzip, rendendo così possibile un considerevole risparmio di traffico di rete. 6. TAZIO-TRANSACTIONS Il sottosistema di transazioni è la parte che in tazio svolge la vera e propria logica del servizio offerto, ossia la gestione degli oggetti condivisi, della loro replicazione, e di tutti gli aspetti che coinvolgono l accesso transazionale ad essi. Le sue responsabilità possono essere riassunte nei seguenti punti: Fornire un API all utente che gli permetta di creare, rimuovere o recuperare oggetti condivisi dallo Share Fornire un API all utente che gli permetta il controllo esplicito dei boundary delle transazioni

5 Figure 6: Il ciclo di vita di una transazione Figure 5: I proxy in tazio Garantire che tutti gli accessi agli oggetti avvengano nel contesto di una transazione Gestire il completo ciclo di vita delle transazioni Per garantire che ogni accesso avvenga in ambito transazionale, tazio utilizza un semplice sistema basato sul proxying dinamico delle istanze degli oggetti transazionali (fig. 5): tutte le chiamatate su metodi getter e setter degli oggetti condivisi vengono dirottate su un proxy che si assicura che esista una transazione associata al thread chiamante. In caso affermativo associa l azione richiesta a quella transazione, mentre in caso contrario si preoccupa di creare una nuova transazione e richiederne il commit subito alla fine della chiamata. (In verità le chiamate vengono prima intercettate da un ulteriore proxy gestito dal sottosistema di cache, che si preoccupa che l oggetto su cui viene effettuata la chiamata sia aggiornato all ultima versione. Questo aspetto però esula dagli scopi di questa relazione, e verrà approfondito nel lavoro del progettista di quel sottosistema). Il controllo per la rilevazione di conflitti tra transazioni concorrenti è gestito sfruttando un approccio basato sul Multiversion Concurrency Control (MVCC). Ogni thread che accede ad oggetti condivisi in maniera transazionale lo fa lavorando su una sua copia locale (d ora in poi riferita come snapshot). Così facendo ci si assicura che una transazione lavori in isolamento sui suoi snapshot, evitando a priori l interferenza di altre transazioni concorrenti. Evidentemente, però, dovrà essere previsto un meccanismo di individuazione e risoluzione dei conflitti al momento del commit delle transazioni. In tazio ciò avviene sfruttando il versioning degli oggetti e l ordinamento delle transazioni basato su un timestamp logico. Tale sistema si basa su una versione riadattata del metodo delle Versioned Box proposta da Joao Cachopo [2], e verrà illustrato descrivendo il ciclo di vita delle transazioni in tazio. 6.1 Ciclo di vita di una transazione Tutte le transazioni sono - impliciatmente o espliciamente - iniziate da un WRM. Idealmente l interfaccia di una transazione esposta all utente è la seguente interface Transacition UUID id long seqno int status void begin() void commit() void rollback() Ogni transazione deve essere globalmente identificabile in tutto il sistema: una possibile soluzione sarebbe far sì che un componente centralizzato assegni un identificativo unico al momento della creazione della transazione. L approccio che è stato scelto, invece, non lascia questa responsabilità ad un server unico, ma è il WRM che generare localmente uno UUID, di cui è garantita l univocità statistica. Inoltre ad ogni transazione è associato un numero di sequenza, che verrà utilizzato come clock logico per identificare il momento nel quale la traansazione ha iniziato la sua esecuzione. La vita di una transazione passa attraverso una serie di stati, corrispondenti ad altrettante fasi, come illustrato in figura 6. Una transazione che riesce ad effettuare un commit con successo passa attraverso tutte le fasi in maniera sequenziale, mentre ciò non è detto per una transazione che viene abortita. BEGINNING. Quando un thread chiama il metodo Transaction.begin(), viene generato un nuovo UUID per la transazione appena creata, e viene inviato un messagio al RM a cui il WRM è attualmente connnesso, informandolo della sua intenzione di iniziare una nuova transazione. Il Replica Manager risponde a questa richiesta ritornando un Initial Sequence Number da assegnare alla transazione: queto numero corrisponde al Sequence Number dell ultima transazione completata con successo che abbia effettutato operazioni di scrittura su quel Replica Manager (i.e. non vengono contate le transazioni di sola lettura per il conteggio). Questo numero rappresenta un clock logico che colloca la transazione appena iniziata in un punto preciso nel tempo, e servirà ad individuare - al momento della verifica dei conflitti - le transazioni che hanno eseguito concorrentemente. Va fatto notare che il Sequence Number assegnato ad una transazione in questa fase non è definitivo, e può cambiare durante la fase di COMMIT come sarà descritto in seguito. Se un messaggio di richiesta di inizio transazione, o la sua risposta, sono persi per qualsiasi motivo il WRM può inviare di nuovo la stessa richiesta allo stesso, oppure ad un altro, RM dato che tale richiesta non altera lo stato interno dei server. Durante questa fase, inoltre, il sistema di cache si assicura che ogni oggetto presente nella cache locale al cliente sia aggiornato alla sua ultima versione, o - in caso negativo - invalidato.

6 Una volta che il client riceve un messaggio di risposta, e la transazione un suo sequence numeber, essa passa nella fase RUNNING. RUNNING. Questa fase coincide con l esecuzione vera e propria della transazione, ed è svolta completamente dal WRM che l ha originata. Al primo accesso ad un oggetto ne viene recuperata un istanza attraverso il sistema di cache, e ne viene immediatamente creato uno snapshot ed associato alla transazione. Tutte le letture e le scritture effettutate sull oggetto condiviso verranno d ora in poi effettuate sullo snapshot, così garantendo l isolamento delle operazioni della transazione. È ovvio però che, dal momento che diverse transazioni possono essere in esecuzione concorrentemente, due (o più) di loro potrebbero voler modificare un insieme di oggetti coincidenti allo stesso tempo: se una di queste fa commit prima delle altre, gli snapshot letti dalle altre transazioni diventano invalidi, e dunque tali transazioni vanno abortite. Questo controllo avviene in due fasi separate, durante le fasi di LOCAL VERIFICATION e GLOBAL VERIFICA- TION. LOCAL VERIFICATION. La fase RUNNING termina non appena ad una transazine viene chiesto di fare commit. A questo punto questa deve essere controllata per individuare conflitti con altre transazioni ad essa sovrapposte. Tale verifica utilizza un protocollo per il controllo dei conflitti all indietro (backward validation): la transazione che si sta verificando viene confrontata contro le sole transazioni che hanno fatto commit con successo mentre essa era nello stato di RUNNING. D ora in poi questo sottoinsieme di transazioni sarà riferito come l insieme delle transazioni overlapping. Come sarà spiegato a breve il meccanismo dei sequence number permette di identificare tale sottoinsieme come quello delle transazioni committed aventi un sequence number strettamente maggiore dell initial sequence numebr della transazione in verifica. La backward validation controlla che una transazione non abbia letto proprietà da oggetti che una delle transazioni overlapping ha scritto durante il loro commit. Più precisamente, ad ogni transazione sono associati due insiemi: un read set (RS), contentente gli identificativi degli oggetti letti un write set (WS), consistente degli identificatori degli oggetti scritti Quando una transazione Tv entra nella fase di verifica essa viene abortita se esiste una transazione overlapping Ti tale che: (Tv.RS intersect Ti.WS) is not empty Durante la fase di LOCAL VERIFICATION questo algoritmo è applicato alle sole transazioni locali al WRM che ha generato la transazione. Per garantire la sua correttezza, l intera verifica va eseguita in una sezione critica. Si noti che, da solo, questo step non assicura che una transazione non sia in conflitto con altre transazioni overlapping originate su altri Weak Replica Manager, e dunque è necessario eseguire una validazione globale. Le transazioni che superano questa verifica passano dunque nello stato di GLOBAL VERIFICATION, le altre vanno direttamente nella fase di ROLLBACK. GLOBAL VERIFICATION. In questa fase il cluster di Replica Manager è informato delle modifiche che una transazione intende apportare alla memoria condivisa, e prova a validarle rispetto a tutte le altre transazioni overlapping del sistema. La fase di GLOBAL VERIFICATION inizia quando un WRM fa una richiesta di commit al Replica Manager al quale è correntemente connesso. Insieme alla richiesta viene serializzato un oggetto che descrive la transazione di cui si vuole fare il commit, comprendente le modifiche da apportare in caso di successo. Questa richiesta deve essere inviata al più ad un Replica Manager del cluster, anche in caso di mancata risposta. Infatti se accadesse che un messaggio di risposta fosse perso, e un WRM reinviasse la richiesta di commit ad un altro Replica Manager, potrebbe accadere che la transazione sia duplicata. Al momento della ricezione, il Replica Manager diventa il Transaction Manager per quella transazione: sarà responsabile di propagare la transazione agli altri RM del cluster, e di informare il suo cliente del risultato del processo di commit. Per raggiungere la proprietà di one-copy serializability (i.e. tutte i RM condividono un ordine in cui serializzare le transazioni) tutte i Replica Manager del cluster devnono validare tutte le transazioni nello stesso ordine ed il risultato della validazione deve coincidere. Questa proprietà è realizzato sfruttando un protocollo di terminazione bastato sull atomic broadcast 1, che verrà meglio illustrato nella sezione 6.2. Il processo di verifica su ciascun Replica Manager riflette del tutto quello descritto per la fase di LOCAL VERIFICA- TION, ma questa volta una transazione è validata rispetto a tutte le transazioni concorrenti presenti nel sistema; se una transazione non passa questa validazione essa va abortita, e passa nella fase di roll back. Al contrario se la verifica termina con successo la transazione è pronta per terminare il suo commit e passa nella fase COMMITTING. COMMITTING. Dopo aver passato la verifica globale una transazione è pronta per fare commit. Si noti che è necessario che le transazioni entrino nella fase di COMMIT nello stesso ordine in cui sono state validate, ed anche in questo caso, devono farlo una alla volta: per questo motivo il codice che esegue le due fasi è racchiuso in un unica sezione critica. La prima operazione durante questa fase è impostare il sequence number definitivo di una transazione: queto corrisponde al suo initial sequence number incrementato di uno se la transazione ha eseguito operazioni di scrittura. Come fatto notare precedentemente, questo passo permette - a tempo di verifica - di identificare immediatamente l insieme delle transazioni che si sovrappongono temporalmente: infatti, siccome il sequence number iniziale di una transazione corrisponde a quello dell ultima transazione conclusa con successo, una transazione già conclusa sarà temporalmente sovrapposta ad un altra se e solo se essa possiede un 1 In questo documento i termini broadcast e multicast vengono usati - impropriamente - in maniera intercambiabile, ma in entrambi i casi ci si riferisce al multicast di un messaggio ai membri del cluster

7 sequence number strettamente maggiore del initial sequence number dell altra. Successivamente, il Replica Manager procede aggiornando gli oggetti nella memoria condivisa: quelli modificati sono marcati con un numero di versione che coincide con il sequence number della transazione che sta facendo il commit, rendendo così possibile capire quale transazione ha modificato per ultimo un oggetto. A questo punto tutti i RM avranno preso una decisione finale (ed uguale) sull esito della transazione, ma il WRM ancora non ha ricevuto un acknowledgment: questo è ciò che discrimina pesantemente i Weak Replica Manager come parte non attiva nelle transazioni distribuite. Infatti se, ad esempio, il client dovesse guastarsi dopo aver inviato una richiesta di commit, la transazione potrebbe concludersi positivamente anche a sua insaputa. In ogni caso, a decisione presa, il Transacion Manager per una transazione informa il WRM che l ha originata sul suo esito con un messaggio di acknowledgment. Come appena sottolineato questo messaggio può venir perso senza compormettere o alterare l esito della transazione, e sta nella logica del Weak Replica Manager investigare sull esito di una transazione di cui non ha ricevuto acknoledgment. Alla fine di questa fase, inoltre, il sistema di cache sarà incarciato di invalidare (o aggiornare) le copie in cache dei WRM che possedevano repliche degli oggetti condivisi appena modificati. ROLLING BACK. Una transazione può entrare nella fase di ROLL BACK per tre diverse ragioni: una chiamata esplicita dell utente al metodo rollback(), un fallimento nella fase di LOCAL VERIFICATION, oppure un fallimento nella fase di GLO- BAL VERIFICATION. Nei primi due casi, siccome la transazione non ha mai abbandonato il WRM che l ha originata, è sufficiente scartare la transazione; nel terzo caso, invece, il Replica Manager che aveva preso in consegna la richiesta di commit deve notificare il WRM proprietario della transazione del fallimento dlla verifica. 6.2 Il protocollo di commit atomico Per coordinare il commit delle transazioni distribuite tra il cluster di Replica Manager, tazio esplora un protocollo di terminazione basato sull atomic broadcats [5], piuttosto che utilizzare un protocollo di coordinazione tradzionale quale 2PC o 3PC. Nel momento stesso in cui un RM riceve una richiesta di commit da un client, procede ad inoltrare tale richiesta a tutti i membri del cluster con un messaggio di broadcast atomico. L uso del broadcast atomico garantisce che: se un RM corretto riceve una richiesta di commit r, allora tutti gli altri membri del gruppo riceveranno r se un RM corretto riceve una richiesta di commit r prima di un altra richiesta r, allora tutti gli altri i membri del gruppo riceveranno r prima di r Queste due proprietà, insieme, garantiscono che tutti i Replica Manager corretti riceveranno lo stesso insieme di richieste di commit, e lo riceveranno nel medesimo ordine. È evidente che in questo modo, validando le transazioni nello stesso ordine in cui sono ricevute, ogni RM le verificherà rispetto allo stesso insieme di transazioni precedenti. Ciò garantisce che tutti i Replica Manager concorderanno sull esito della verifica, e dunque che lo stato della replica della memoria condivisa che gestiscono sarà passo dopo passo consistente con quello delle altre repliche. Il vantaggio di usare un protocollo del genere rispetto all uso di un protocollo di coordinazione tradizionale, è notevole: in primo luogo la sua adozione semplifica incredibilmente la realizzazione della replicazione in quanto, supponendo di disporre di un implementazione dell atomic broadcast, non c è bisogno di scrivere neanche una riga di logica di coordinazione. Inoltre, soprattutto nel caso di un elevato numero di membri del cluster, il numero di messaggi scambiati per raggiungere la terminazione è decisamente minore, soprattutto nel caso in cui il multicast avvenga sfruttando IP Multicast: in tale situazione i messaggi necessari sarebbero 1 messaggio punto punto al sequencer più un singolo messaggio di broadcast. Uno svantaggio evidente dell implementazione di atomic broadcast basata su sequencer è l introduzione di un importante collo di bottiglia sul nodo che riveste il ruolo di sequencer, ma evidentemente il problema è rimandato all implementazione della primitiva di broadcast ad ordinamento totale, e nulla vieta di implementarla usando algoritmi a sequencer mobile, oppure ad ordinamento distribuito, che - pur aumentando i messaggi scambiati - risolvono il problema del collo di bottiglia. 7. VALUTAZIONE Abbiamo provato il primo prototipo del sistema su 7 macchine ciascuna dotata di un processore Intel Core2 Duo E7400 (2.80 Ghz), 2Gb di memoria primaria, sistema operativo Ubuntu Linux 9.04 (kernel linux 2.6.x a 64 bit), e Java HotSpot 64-Bit Server VM nella implementazione della Sun. Tutte le macchine erano connesse via Ethernet alla stessa rete locale. Purtroppo sia il numero limitato di macchine che il fatto che esse fossere collegate ad una stessa LAN non si prestano bene all analisi di un sistema che tra ha come primo obiettivo la scalabiltà rispetto ad un elevato numero di clienti, e che vuole riuscire a fornire una qualità del servizio soddisfacente anche a clienti fisicamente localizzati lontano dai cluster. Nonostante ciò sono stati eseguiti una serie di test per valutare il comportamento del sistema sotto diversi punti di vista. Tutti i sottosistemi di tazio sono predisposti per esporre un interfaccia di management a runtime, sfruttando la tecnologia Java Management Extensions (JMX): in particolare ogni nodo pubblica una serie di MBean che espongono all esterno diversi indicatori sul funzionamento runtime del sistema, tra cui statistiche sulle prestazioni ed informazioni sulla configurazione. Alla fine di ogni prova effettuata un nodo si è preoccupato di raccogliere i dati dagli MBean Server delle macchine sotto test, e di farne il log su file in un formato convenientemente importabile 2 Il codice di tutti i test svolti si basa sull uso di un semplicissimo tipo di oggetto transazionale, che vuole mimare la semantica di un semplice contatore mettendo a disposizione nella sua intefaccia una sola semplice proprietà di tipo intero read-write: 2 Tutti i risultati dei test sono disponibili all indirizzo todj6c8ndak7zofntye6wha&output=html

8 Figure 7: Un contatore per ogni WRM, numero di commit medio al secondo Figure 8: Un contatore per ogni WRM, tempo di commit medio lato public interface Counter int void setvalue(int newvalue); } A seconda dei risultati che si intendeva validare e verificare, tale oggetto viene usato in maniera diversa e con accessi a diversi livelli di concorrenza dalle applicazioni sui Weak Replica Manager. 1RM vs 2RM - Niente concorrenza. Il primo test è volto a verificare l influenza della numerosità di membri del cluster di Replica Manger sulle prestazioni del sistema. Per questo motivo è stato predisposto uno scenario a concorrenza di transazioni nulla, evitando così che la presenza di rollback inficiasse i risultati. L applicazione sui nodi dei WRM consiste in un ciclo senza attese che - dopo aver aggiunto un istanza di Counter (ciascuna diversa per ogni nodo) nella memoria condivisa - lo incrementa ad ogni iterazione fino a fargli raggiungere il valore di 300. Il test è stato ripetuto prima con un solo RM e variando il numero di WRM contemporaneamente attivi (da 1 a 5), poi aggiungendo un secondo Replica Manager nel cluster e ripetendo le stesse prove. Il primo grafico (fig. 7) mostra il numero medio di transazioni per secondo completate dai Weak Replica Manager. Come prevedibile all aumentare del numero di WRM connessi le prestazioni degradano leggermente ma comunque si mantengono tra i 13 e i 14.5 commit al secondo. Interessante è notare come l aggiunta di un secondo nodo nel cluster, lasci praticamente inalterate le prestazioni del sistema, confermando come il protocollo di commit utilizzato effettivamente non pesi in gran misura sulle prestazioni. Di più le prestazioni con 2 RM risultano essere anche leggermente migliori, probabilmente a cuasa del fatto che il carico delle connessioni client-server con i WRM è distribuito tra i due nodi. La figura 8 invece mostra il tempo medio di verifica e commit di una transazione lato RM, sempre al variare del numero di WRM e RM. Anche in questo caso le differenze di tempistiche tra la configurazione con 1 e 2 RM sono minime (meno di 3 Figure 9: Un contatore condiviso, percentuale di transazioni con commit millisecondi), ed ancora la configurazione con due Replica Manager si dimostra migliore. 2RM - Alta Concorrenza. Un secondo interessante test è quello volto a misurare gli effetti di uno scenario ad alta concorrenza sulle prestazioni del sistema. In questo caso le applicazioni sui nodi dei WRM condivodono un singolo contatore, ed iterativamente provano ad incrementare il suo valore fino al valore massimo di 300. Per simulare un utilizzo più realistico del sistema tra una transazione e l altra ogni WRM si ferma e attende un valore casuale di tempo compreso tra 0 e 500 millisecondi. Nel primo grafico (fig. 9) è mostrata la percentuale di transazioni concluse con successo rispetto al totale di transazioni iniziate. Non sorprende che, in uno scenario ad alta contesa del contatore come questo, all aumentare del numero di clienti questa percentuale cali fin sotto il 60%. In figura 11 sono mostrati i dati rilevati circa il tempo medio di durata di una transazione su un WRM (a partire dal begin() fino alla ricezione di una risposta da un RM). Si confrontino questi dati con quelli riportati in figura 10, che mostra lo stesso tipo di rilevazione in uno scenario di test privo di conflitti tra transazioni simile al precedente: la du-

9 Figure 10: Un contatore per ogni WRM, durata delle transazioni medio lato WRM Figure 12: Un contatore condiviso, divisione dei commit tra i WRM connessi al sequencer e gli altri Figure 11: Un contatore condiviso, durate delle transazioni medio lato WRM rata media di una transazione in presenza di conflitti risulta in generale peggiore. Ciò è facilmente attribuibile all intervento del sistema di cache, che deve invalidare e aggiornare il valore del contatore quando è modificato da altri nodi. Questo test si è inoltre rivelato essere particolarmente degno di nota, in quanto ha messo in luce una interessante conseguenza dell implementazione del multicast ad ordinamento totale utilizzata. Come accennato precedentemente il prototipo sviluppato utilizza un multicast atomico basato sull uso di un sequencer fisso: questo ruolo è rivestito da uno dei Replica Manager che il framework JGroups elegget a coordinatore del cluster. Il grafico in figura 12 mostra a confronto la percentuale di transazioni totali completate con successo dai WRM connessi al sequencer, contro quelle completate con successo dagli altri. Si vede come il 64% degli incrementi al contatore sono effettuati dai primi. Investigando i motivi di questa disparità, si è scoperto che effettivamente i nodi del sequencer effettuavano un numero di richieste di commit decisamente maggiore rispetto a quelle degli altri nodi (figura 13), all incirca nella stessa percentuale del numero di commit completati. Questo rappresenta evidentemente un pesante squilibrio rispetto alla qualità del servizio offerta ai clienti del sistema, che risulta pesantemen- Figure 13: Un contatore condiviso, richiest di commit tra i WRM connessi al sequencer vs gli altir te dipendente dal RM a cui si è connessi. Sebbene ciò non vada comunque ad inficiare la funzionalità del sistema, si tratta comunque di una proprietà poco desiderabile: possibili soluzioni sono l uso di un nodo dedicato al solo ruolo di sequencer (i.e. che non accetta transazioni), usare un implementazione con sequencer mobile, oppure un multicast atomico con responsabilità di ordinamento distribuito [3]. 1RM - 2WRM - Alta Concorrenza Locale. L ultimo test vuole verificare la bontà e l effettiva utilità della fase di LOCAL VERIFICATION, in cui transazioni di cui si rilevano conflitti locali sono abortite prima di essere inviate ai RM remoti. Sono state sviluppate due varianti della verifica locale: la prima esegue l algoritmo di validazione e la richiesta di commit remoto in un unica sezione critica; ciò significa che una transazione alla volta (per ogni WRM) può essere in commit su un RM. La seconda variante, invece, separa la fase di verifica locale dalla richiesta remota che in questo modo può essere effettuata in parallelo per più di una transazione. La seconda viarante, rispetto alla prima, ha lo svantaggio di non riuscire

10 Figure 14: Efficacia della verifica di conflitti locali: percentuale di conflitti rilevati localmente Figure 15: Efficacia della verifica di conflitti locali: tempo totale di test a rilevare tutti i conflitti che sorgono localmente siccome una transazione che è in GLOBAL VERIFICATION non viene inclusa nel set di transazioni overlapping nella fase di validazione. Al contrario della prima variante però permette di parallelizzare le richieste di rete, comunque garantendo la correttezza del sistema dal momento che i conflitti non rilevati globalmente vengono comunque individuati nella fase di GLOBAL VERIFICATION remota. Questo test vuole mettere a confronto le due alternative, e per fare ciò utilizza un deployment costituito da un singolo Replica Manager, e due Weak Replica Manager che tentano di incrementare concorrentamente un singolo contatore condiviso. In più su ciascun WRM l incrementare del contatore è portato avanti da una serie di thread che lavorano a loro voltaconcorrentemente, generando conflitti locali. Il grafico in figura 14 mostra il rapporto tra il numero di rollback locali, ed il numero totale di rollback; la linea rossa si riferisce alla variante con una singola sezione critica, mentra quella azzura a quella con due parti separate. Come previdibile la variante ad una singola sezione critica riesce sempre a rilevare un maggior numero di conflitti localmente, anche se all esplodere del numero di thread la differenza diventa non troppo marcata. In realtà però la differenza di prestazioni in termini di tempo totale di test non si è rivelata così evidente, in quanto la possibilità di parallelizzare le richieste riesce a sopperire al numero di conflitti non rilevati localmente. La figura 15 illustra chiaramente questo fenomeno, ed in più fa notare come all aumentare dei thread per WRM, aumentando il numero dei conflitti, il tempo totale di test inizia a crescere rapidamente, dopo essere stato inizialmente avvantaggiato dalla parallelizzazione delle operazioni. 8. CONLUSIONI Lo sviluppo di applicazioni fortemente distribuite impone forti requisiti di coordinazioni tra i nodi partecipanti alle applicazioni. L astrazione di una memoria distribuita con semantica transazionale, abilita la comunicazione e la coordinazione tra processi remoti in maniera semplice e priva delle difficoltà inerenti alla programmazione concorrente. Il sistema proposto si pone come una valida soluzione al probleme di condividere informazioni ed accedervi in maniera concorrente in questo tipo di scenari, in più implementanto meccanismi ad hoc che permettono di offrire un servizio ad alta affidabilità ai propri clienti. Inoltre la distinzione che introduce tra i partecipanti alla memoria condivisa gli permette di rendere il sistema adottabile anche da un numero considerevole di partecipanti senza per questo imporre forti limitazioni sulle garanzie offerte. Nonostante gli ottimi risultati dimostrati nei test effettuati sul sistema, rimangono tuttavia ampi margini di miglioramento per il sistema, e numerose varianti da esplorare. Tra queste l uso di diverse implementazioni di multicast atomico, la valutazione di diversi protocolli per la comunicazione tra WRM e RM, e la valuatazione di diversi tipi di deployment. Inoltre il sistema rimane immaturo per quanto riguarda la gestione di situazioni problematiche come la rilevazione di failure di Replica Manager, il ripristino di Replica Manager dopo un crash, e la gestione di network partitions. Si spera di riuscire presto a colmare questi vuoti. 9. REFERENCES [1] T. Abdellatif, E. Cecchet, and R. Lachaize. Evaluation of a group communication middleware for clustered J2EE application servers. Lecture Notes in Computer Science, pages , [2] J. Cachopo and A. Rito-Silva. Versioned boxes as the basis for memory transactions. Science of Computer Programming, 63(2): , [3] X. Défago, A. Schiper, and P. Urbán. Total order broadcast and multicast algorithms: Taxonomy and survey. ACM Computing Surveys (CSUR), 36(4): , [4] R. Hitchens. Java Nio. O Reilly & Associates, Inc. Sebastopol, CA, USA, [5] F. Pedone, R. Guerraoui, and A. Schiper. Exploiting atomic broadcast in replicated databases. Lecture Notes in Computer Science, pages , [6] D. Schmidt. Reactor: an object behavioral pattern for concurrent event demultiplexing and event handler dispatching

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

Inter Process Communication. Laboratorio Software 2008-2009 C. Brandolese

Inter Process Communication. Laboratorio Software 2008-2009 C. Brandolese Inter Process Communication Laboratorio Software 2008-2009 C. Brandolese Introduzione Più processi o thread Concorrono alla relaizzazione di una funzione applicativa Devono poter realizzare Sincronizzazione

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

Middleware Laboratory. Dai sistemi concorrenti ai sistemi distribuiti

Middleware Laboratory. Dai sistemi concorrenti ai sistemi distribuiti Dai sistemi concorrenti ai sistemi distribuiti Problemi nei sistemi concorrenti e distribuiti I sistemi concorrenti e distribuiti hanno in comune l ovvio problema di coordinare le varie attività dei differenti

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

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

Utilizzo del server SMTP in modalità sicura

Utilizzo del server SMTP in modalità sicura Utilizzo del server SMTP in modalità sicura In questa guida forniremo alcune indicazioni sull'ottimizzazione del server SMTP di IceWarp e sul suo impiego in modalità sicura, in modo da ridurre al minimo

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

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

Università degli Studi di Parma. Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica

Università degli Studi di Parma. Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica A.A. 2007-08 CORSO DI INGEGNERIA DEL SOFTWARE Prof. Giulio Destri http://www.areasp.com (C) 2007 AreaSP for

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

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

MIB PER IL CONTROLLO DELLO STATO DI UN SERVER FTP

MIB PER IL CONTROLLO DELLO STATO DI UN SERVER FTP Università degli Studi di Pisa Facoltà di Scienze Matematiche,Fisiche e Naturali Corso di Laurea in Informatica Michela Chiucini MIB PER IL CONTROLLO DELLO STATO DI UN SERVER

Dettagli

Business Process Modeling and Notation e WebML

Business Process Modeling and Notation e WebML Business Process Modeling and Notation e WebML 24 Introduzione I Web Service e BPMN sono standard de facto per l interoperabilità in rete a servizio delle imprese moderne I Web Service sono utilizzati

Dettagli

Introduzione. E un sistema EAI molto flessibile, semplice ed efficace:

Introduzione. E un sistema EAI molto flessibile, semplice ed efficace: Overview tecnica Introduzione E un sistema EAI molto flessibile, semplice ed efficace: Introduce un architettura ESB nella realtà del cliente Si basa su standard aperti Utilizza un qualsiasi Application

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

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

Le funzionalità di un DBMS

Le funzionalità di un DBMS Le funzionalità di un DBMS Sistemi Informativi L-A Home Page del corso: http://www-db.deis.unibo.it/courses/sil-a/ Versione elettronica: DBMS.pdf Sistemi Informativi L-A DBMS: principali funzionalità Le

Dettagli

Sistemi Operativi. Interfaccia del File System FILE SYSTEM : INTERFACCIA. Concetto di File. Metodi di Accesso. Struttura delle Directory

Sistemi Operativi. Interfaccia del File System FILE SYSTEM : INTERFACCIA. Concetto di File. Metodi di Accesso. Struttura delle Directory FILE SYSTEM : INTERFACCIA 8.1 Interfaccia del File System Concetto di File Metodi di Accesso Struttura delle Directory Montaggio del File System Condivisione di File Protezione 8.2 Concetto di File File

Dettagli

Introduzione alla Programmazione ad Oggetti in C++

Introduzione alla Programmazione ad Oggetti in C++ Introduzione alla Programmazione ad Oggetti in C++ Lezione 1 Cosa è la Programmazione Orientata agli Oggetti Metodologia per costruire prodotti software di grosse dimensioni che siano affidabili e facilmente

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

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

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

END-TO-END SERVICE QUALITY. LA CULTURA DELLA QUALITÀ DAL CONTROLLO DELLE RISORSE ALLA SODDISFAZIONE DEL CLIENTE

END-TO-END SERVICE QUALITY. LA CULTURA DELLA QUALITÀ DAL CONTROLLO DELLE RISORSE ALLA SODDISFAZIONE DEL CLIENTE END-TO-END SERVICE QUALITY. LA CULTURA DELLA QUALITÀ DAL CONTROLLO DELLE RISORSE ALLA SODDISFAZIONE In un mercato delle Telecomunicazioni sempre più orientato alla riduzione delle tariffe e dei costi di

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

Lezione n.19 Processori RISC e CISC

Lezione n.19 Processori RISC e CISC Lezione n.19 Processori RISC e CISC 1 Processori RISC e Superscalari Motivazioni che hanno portato alla realizzazione di queste architetture Sommario: Confronto tra le architetture CISC e RISC Prestazioni

Dettagli

B.P.S. Business Process Server ALLEGATO C10

B.P.S. Business Process Server ALLEGATO C10 B.P.S. Business Process Server ALLEGATO C10 REGIONE BASILICATA DIPARTIMENTO PRESIDENZA DELLA GIUNTA REGIONALE UFFICIO SISTEMA INFORMATIVO REGIONALE E STATISTICA Via V. Verrastro, n. 4 85100 Potenza tel

Dettagli

AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Unified Process. Prof. Agostino Poggi

AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Unified Process. Prof. Agostino Poggi AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma Unified Process Prof. Agostino Poggi Unified Process Unified Software Development Process (USDP), comunemente chiamato

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

MODBUS-RTU per. Specifiche protocollo di comunicazione MODBUS-RTU per controllo in rete dispositivi serie. Expert NANO 2ZN

MODBUS-RTU per. Specifiche protocollo di comunicazione MODBUS-RTU per controllo in rete dispositivi serie. Expert NANO 2ZN per Expert NANO 2ZN Specifiche protocollo di comunicazione MODBUS-RTU per controllo in rete dispositivi serie Expert NANO 2ZN Nome documento: MODBUS-RTU_NANO_2ZN_01-12_ITA Software installato: NANO_2ZN.hex

Dettagli

Architettura dei Calcolatori

Architettura dei Calcolatori Architettura dei Calcolatori Sistema di memoria parte prima Ing. dell Automazione A.A. 2011/12 Gabriele Cecchetti Sistema di memoria parte prima Sommario: Banco di registri Generalità sulla memoria Tecnologie

Dettagli

Universita' di Ferrara Dipartimento di Matematica e Informatica. Algoritmi e Strutture Dati. Rappresentazione concreta di insiemi e Hash table

Universita' di Ferrara Dipartimento di Matematica e Informatica. Algoritmi e Strutture Dati. Rappresentazione concreta di insiemi e Hash table Universita' di Ferrara Dipartimento di Matematica e Informatica Algoritmi e Strutture Dati Rappresentazione concreta di insiemi e Hash table Copyright 2006-2015 by Claudio Salati. Lez. 9a 1 Rappresentazione

Dettagli

Il linguaggio SQL: transazioni

Il linguaggio SQL: transazioni Il linguaggio SQL: transazioni Sistemi Informativi T Versione elettronica: 4.8.SQL.transazioni.pdf Cos è una transazione? Una transazione è un unità logica di elaborazione che corrisponde a una serie di

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

SAI QUANTO TEMPO IMPIEGHI A RINTRACCIARE UN DOCUMENTO, UN NUMERO DI TELEFONO O UNA E-MAIL?

SAI QUANTO TEMPO IMPIEGHI A RINTRACCIARE UN DOCUMENTO, UN NUMERO DI TELEFONO O UNA E-MAIL? archiviazione ottica, conservazione e il protocollo dei SAI QUANTO TEMPO IMPIEGHI A RINTRACCIARE UN DOCUMENTO, UN NUMERO DI TELEFONO O UNA E-MAIL? Il software Facile! BUSINESS Organizza l informazione

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

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

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

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

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

Agilent OpenLAB Chromatography Data System (CDS)

Agilent OpenLAB Chromatography Data System (CDS) Agilent OpenLAB Chromatography Data System (CDS) EZChrom Edition e ChemStation Edition Requisiti hardware e software Agilent Technologies Informazioni legali Agilent Technologies, Inc. 2013 Nessuna parte

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

Note e informazioni legali

Note e informazioni legali Note e informazioni legali Proprietà del sito; accettazione delle condizioni d uso I presenti termini e condizioni di utilizzo ( Condizioni d uso ) si applicano al sito web di Italiana Audion pubblicato

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

Il Business Process Management: nuova via verso la competitività aziendale

Il Business Process Management: nuova via verso la competitività aziendale Il Business Process Management: nuova via verso la competitività Renata Bortolin Che cosa significa Business Process Management? In che cosa si distingue dal Business Process Reingeneering? Cosa ha a che

Dettagli

FileMaker Server 12. Guida introduttiva

FileMaker Server 12. Guida introduttiva FileMaker Server 12 Guida introduttiva 2007 2012 FileMaker, Inc. Tutti i diritti riservati. FileMaker, Inc. 5201 Patrick Henry Drive Santa Clara, California 95054 FileMaker e Bento sono marchi di FileMaker,

Dettagli

CORSO DI ALGORITMI E PROGRAMMAZIONE. JDBC Java DataBase Connectivity

CORSO DI ALGORITMI E PROGRAMMAZIONE. JDBC Java DataBase Connectivity CORSO DI ALGORITMI E PROGRAMMAZIONE JDBC Java DataBase Connectivity Anno Accademico 2002-2003 Accesso remoto al DB Istruzioni SQL Rete DataBase Utente Host client Server di DataBase Host server Accesso

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

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

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

I componenti di un Sistema di elaborazione. CPU (central process unit)

I componenti di un Sistema di elaborazione. CPU (central process unit) I componenti di un Sistema di elaborazione. CPU (central process unit) I componenti di un Sistema di elaborazione. CPU (central process unit) La C.P.U. è il dispositivo che esegue materialmente gli ALGORITMI.

Dettagli

Mobile Messaging SMS. Copyright 2015 VOLA S.p.A.

Mobile Messaging SMS. Copyright 2015 VOLA S.p.A. Mobile Messaging SMS Copyright 2015 VOLA S.p.A. INDICE Mobile Messaging SMS. 2 SMS e sistemi aziendali.. 2 Creare campagne di mobile marketing con i servizi Vola SMS.. 3 VOLASMS per inviare SMS da web..

Dettagli

Massimo Paolucci (paolucci@dist.unige.it) DIST Università di Genova. Metodi per supportare le decisioni relative alla gestione di progetti

Massimo Paolucci (paolucci@dist.unige.it) DIST Università di Genova. Metodi per supportare le decisioni relative alla gestione di progetti Project Management Massimo Paolucci (paolucci@dist.unige.it) DIST Università di Genova Project Management 2 Metodi per supportare le decisioni relative alla gestione di progetti esempi sono progetti nell

Dettagli

Oggetti Lezione 3. aspetti generali e definizione di classi I

Oggetti Lezione 3. aspetti generali e definizione di classi I Programmazione a Oggetti Lezione 3 Il linguaggio Java: aspetti generali e definizione di classi I Sommario Storia e Motivazioni Definizione di Classi Campi e Metodi Istanziazione di oggetti Introduzione

Dettagli

Il ciclo di vita del software

Il ciclo di vita del software Il ciclo di vita del software Il ciclo di vita del software Definisce un modello per il software, dalla sua concezione iniziale fino al suo sviluppo completo, al suo rilascio, alla sua successiva evoluzione,

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

Manuale Operativo IL SOFTWARE PER LA GESTIONE CENTRALIZZATA DEL SISTEMA DELLE SEGNALAZIONI E DEI RECLAMI DELL ENTE

Manuale Operativo IL SOFTWARE PER LA GESTIONE CENTRALIZZATA DEL SISTEMA DELLE SEGNALAZIONI E DEI RECLAMI DELL ENTE Manuale Operativo IL SOFTWARE PER LA GESTIONE CENTRALIZZATA DEL SISTEMA DELLE SEGNALAZIONI E DEI RECLAMI DELL ENTE Il presente documento applica il Regolamento sulla gestione delle segnalazioni e dei reclami

Dettagli

Le variabili. Olga Scotti

Le variabili. Olga Scotti Le variabili Olga Scotti Cos è una variabile Le variabili, in un linguaggio di programmazione, sono dei contenitori. Possono essere riempiti con un valore che poi può essere riletto oppure sostituito.

Dettagli

INFORMATIVA SUI COOKIE

INFORMATIVA SUI COOKIE INFORMATIVA SUI COOKIE I Cookie sono costituiti da porzioni di codice installate all'interno del browser che assistono il Titolare nell erogazione del servizio in base alle finalità descritte. Alcune delle

Dettagli

Architetture CISC e RISC

Architetture CISC e RISC FONDAMENTI DI INFORMATICA Prof. PIER LUCA MONTESSORO Facoltà di Ingegneria Università degli Studi di Udine Architetture CISC e RISC 2000 Pier Luca Montessoro (si veda la nota di copyright alla slide n.

Dettagli

Sistemi di supporto alle decisioni Ing. Valerio Lacagnina

Sistemi di supporto alle decisioni Ing. Valerio Lacagnina Cosa è il DSS L elevato sviluppo dei personal computer, delle reti di calcolatori, dei sistemi database di grandi dimensioni, e la forte espansione di modelli basati sui calcolatori rappresentano gli sviluppi

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

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

Metadati e Modellazione. standard P_META

Metadati e Modellazione. standard P_META Metadati e Modellazione Lo standard Parte I ing. Laurent Boch, ing. Roberto Del Pero Rai Centro Ricerche e Innovazione Tecnologica Torino 1. Introduzione 1.1 Scopo dell articolo Questo articolo prosegue

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

Elementi di UML (7): Diagrammi dei componenti e di deployment

Elementi di UML (7): Diagrammi dei componenti e di deployment Elementi di UML (7): Diagrammi dei componenti e di deployment Università degli Studi di Bologna Facoltà di Scienze MM. FF. NN. Corso di Laurea in Scienze di Internet Anno Accademico 2004-2005 Laboratorio

Dettagli

Termini di servizio di Comunicherete

Termini di servizio di Comunicherete Termini di servizio di Comunicherete I Servizi sono forniti da 10Q Srls con sede in Roma, Viale Marx n. 198 ed Ancitel Spa, con sede in Roma, Via Arco di Travertino n. 11. L utilizzo o l accesso ai Servizi

Dettagli

IL LIVELLO APPLICAZIONI DNS, SNMP e SMTP

IL LIVELLO APPLICAZIONI DNS, SNMP e SMTP Reti di Calcolatori IL LIVELLO APPLICAZIONI DNS, SNMP e SMTP D. Talia RETI DI CALCOLATORI - UNICAL 6-1 Applicazioni di Rete Domain Name System (DNS) Simple Network Manag. Protocol (SNMP) Posta elettronica

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

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

Fig. 1 - L apparato radio CNR2000

Fig. 1 - L apparato radio CNR2000 EO ESCLUSIVA L articolo descrive la strategia seguita nella progettazione e realizzazione della funzionalità di Frequency Hopping per un apparato radio preesistente: la radio tattica CNR2000, di produzione

Dettagli

Dal punto di vista organizzativo sono possibili due soluzioni per il sistema di rete.

Dal punto di vista organizzativo sono possibili due soluzioni per il sistema di rete. Premessa. La traccia di questo anno integra richieste che possono essere ricondotte a due tipi di prove, informatica sistemi, senza lasciare spazio ad opzioni facoltative. Alcuni quesiti vanno oltre le

Dettagli

Web Conferencing and Collaboration tool

Web Conferencing and Collaboration tool Web Conferencing and Collaboration tool La piattaforma Meetecho Piattaforma di Web Conferencing e Collaborazione on line in tempo reale Caratteristiche generali Soluzione client-server progettata per essere

Dettagli

LA PROGETTAZIONE Come fare un progetto. LA PROGETTAZIONE Come fare un progetto

LA PROGETTAZIONE Come fare un progetto. LA PROGETTAZIONE Come fare un progetto LA PROGETTAZIONE 1 LA PROGETTAZIONE Oggi il raggiungimento di un obiettivo passa per la predisposizione di un progetto. Dal mercato al terzo settore passando per lo Stato: aziende, imprese, organizzazioni,

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

più del mercato applicazioni dei processi modificato. Reply www.reply.eu

più del mercato applicazioni dei processi modificato. Reply www.reply.eu SOA IN AMBITO TELCO Al fine di ottimizzare i costi e di migliorare la gestione dell'it, le aziende guardano, sempre più con maggiore interesse, alle problematiche di gestionee ed ottimizzazione dei processi

Dettagli

Sicurezza delle reti wireless. Alberto Gianoli alberto.gianoli@fe.infn.it

Sicurezza delle reti wireless. Alberto Gianoli alberto.gianoli@fe.infn.it Sicurezza delle reti wireless Alberto Gianoli alberto.gianoli@fe.infn.it Concetti di base IEEE 802.11: famiglia di standard tra cui: 802.11a, b, g: physical e max data rate spec. 802.11e: QoS (traffic

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

SISSI IN RETE. Quick Reference guide guida di riferimento rapido

SISSI IN RETE. Quick Reference guide guida di riferimento rapido SISSI IN RETE Quick Reference guide guida di riferimento rapido Indice generale Sissi in rete...3 Introduzione...3 Architettura Software...3 Installazione di SISSI in rete...3 Utilizzo di SISSI in Rete...4

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

Plesk Automation. Parallels. Domande tecniche più frequenti

Plesk Automation. Parallels. Domande tecniche più frequenti Parallels Plesk Automation Primo trimestre, 2013 Domande tecniche più frequenti Questo documento ha come scopo quello di rispondere alle domande tecniche che possono sorgere quando si installa e si utilizza

Dettagli

corso di Sistemi Distribuiti 4. IPC (Inter Process Communication) (parte 1): le forme ed i modelli della comunicazione tra processi

corso di Sistemi Distribuiti 4. IPC (Inter Process Communication) (parte 1): le forme ed i modelli della comunicazione tra processi CdL MAGISTRALE in INFORMATICA A.A. 2014-2015 corso di Sistemi Distribuiti 4. IPC (Inter Process Communication) (parte 1): le forme ed i modelli della comunicazione tra processi Prof. S.Pizzutilo Elementi

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

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

Corso di Amministrazione di Sistema Parte I ITIL 3

Corso di Amministrazione di Sistema Parte I ITIL 3 Corso di Amministrazione di Sistema Parte I ITIL 3 Francesco Clabot Responsabile erogazione servizi tecnici 1 francesco.clabot@netcom-srl.it Fondamenti di ITIL per la Gestione dei Servizi Informatici Il

Dettagli

La suite Dental Trey che semplifica il tuo mondo.

La suite Dental Trey che semplifica il tuo mondo. La suite Dental Trey che semplifica il tuo mondo. impostazioni di sistema postazione clinica studio privato sterilizzazione magazzino segreteria amministrazione sala di attesa caratteristiche UNO tiene

Dettagli

Il modello client/server consente a due processi di condividere risorse e di cooperare per il raggiungimento di un obiettivo.

Il modello client/server consente a due processi di condividere risorse e di cooperare per il raggiungimento di un obiettivo. In una rete di ampie dimensioni, ciascuna sottorete (es. LAN, WAN) è connessa ad altre sottoreti tramite router. Internet è un insieme di reti connesse tra loro. Essenzialmente, in una rete alcune macchine

Dettagli

RESPONS.In.City - Methodology

RESPONS.In.City - Methodology RESPONS.In.City - Methodology THE METHODOLOGY OF A RESPONSIBLE CITIZENSHIP PROMOTION Metodologia di Promozione della Cittadinanza come Responsabilità Condivisa 1 Premessa La possibilità di partecipare

Dettagli

ATLAS 2.X IL MANAGER NON SI AVVIA

ATLAS 2.X IL MANAGER NON SI AVVIA ATLAS 2.X IL MANAGER NON SI AVVIA Avvio di Atlas 2.x sul server CONTESTO La macchina deve rispecchiare le seguenti caratteristiche MINIME di sistema: Valori MINIMI per Server di TC con 10 postazioni d'esame

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

Guida alle offerte di finanziamento per le medie imprese

Guida alle offerte di finanziamento per le medie imprese IBM Global Financing Guida alle offerte di finanziamento per le medie imprese Realizzata da IBM Global Financing ibm.com/financing/it Guida alle offerte di finanziamento per le medie imprese La gestione

Dettagli

Descrizioni VHDL Behavioral

Descrizioni VHDL Behavioral 1 Descrizioni VHDL Behavioral In questo capitolo vedremo come la struttura di un sistema digitale è descritto in VHDL utilizzando descrizioni di tipo comportamentale. Outline: process wait statements,

Dettagli

Software Emeris Communication Manager

Software Emeris Communication Manager ecm Software Emeris Communication Manager Manuale operativo Fantini Cosmi S.p.A. Via dell Osio 6 20090 Caleppio di Settala MI Tel 02.956821 - Fax 02.95307006 e-mail: info@fantinicosmi.it http://www.fantinicosmi.it

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

Rational Asset Manager, versione 7.1

Rational Asset Manager, versione 7.1 Rational Asset Manager, versione 7.1 Versione 7.1 Guida all installazione Rational Asset Manager, versione 7.1 Versione 7.1 Guida all installazione Note Prima di utilizzare queste informazioni e il prodotto

Dettagli

È nata una nuova specie di avvocati. Liberi.

È nata una nuova specie di avvocati. Liberi. È nata una nuova specie di avvocati. Liberi. LIBERI DI NON PENSARCI Basta preoccupazioni per il back-up e la sicurezza dei tuoi dati. Con la tecnologia Cloud Computing l archiviazione e la protezione dei

Dettagli

Sistemi Operativi Sincronizzazione tra Processi

Sistemi Operativi Sincronizzazione tra Processi Sistemi Operativi Processi Docente: Claudio E. Palazzi cpalazzi@math.unipd.it Crediti per queste slides al Prof. Tullio Vardanega 1 Processi indipendenti possono avanzare concorrentemente senza alcun vincolo

Dettagli

Test di comunicazione tra due LOGO! 0BA7: Master - Master

Test di comunicazione tra due LOGO! 0BA7: Master - Master Industry Test di comunicazione tra due LOGO! 0BA7: Master - Master Dispositivi utilizzati: - 2 LOGO! 0BA7 (6ED1 052-1MD00-0AB7) - Scalance X-208 LOGO! 0BA7 Client IP: 192.168.0.1 LOGO! 0BA7 Server IP:

Dettagli

Applicazione: Share - Sistema per la gestione strutturata di documenti

Applicazione: Share - Sistema per la gestione strutturata di documenti Riusabilità del software - Catalogo delle applicazioni: Gestione Documentale Applicazione: Share - Sistema per la gestione strutturata di documenti Amministrazione: Regione Piemonte - Direzione Innovazione,

Dettagli