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

Implementazione dei monitor tramite semafori Attesa condizionale Sincronizzazione nei sistemi operativi reali Transazioni atomiche

Implementazione dei monitor tramite semafori Attesa condizionale Sincronizzazione nei sistemi operativi reali Transazioni atomiche Implementazione dei monitor tramite semafori Attesa condizionale Sincronizzazione nei sistemi operativi reali Transazioni atomiche 5.1 Implementazione dei monitor con i semafori Un monitor è un tipo di

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

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

Transazioni. Capitolo 13. Scrittura immediata e scrittura differita. Concorrenza in un DBMS. Una transazione. Gestione delle transazioni

Transazioni. Capitolo 13. Scrittura immediata e scrittura differita. Concorrenza in un DBMS. Una transazione. Gestione delle transazioni Capitolo 13 Gestione delle transazioni Transazioni L esecuzione concorrente dei programmi utente è essenziale per le buone prestazioni del DBMS Poiché gli accessi al disco sono frequenti e relativamente

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

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 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

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

Tecnologia di un Database Server (centralizzato) Introduzione generale

Tecnologia di un Database Server (centralizzato) Introduzione generale Introduzione Basi di Dati / Complementi di Basi di Dati 1 Tecnologia di un Database Server (centralizzato) Introduzione generale Angelo Montanari Dipartimento di Matematica e Informatica Università di

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

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

8. Sistemi Distribuiti e Middleware

8. Sistemi Distribuiti e Middleware 8. Sistemi Distribuiti e Middleware Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 8. Sistemi distribuiti e Middleware 1 / 32 Sommario 1 Sistemi distribuiti

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

Coordinazione Distribuita

Coordinazione Distribuita Coordinazione Distribuita Ordinamento degli eventi Mutua esclusione Atomicità Controllo della Concorrenza 21.1 Introduzione Tutte le questioni relative alla concorrenza che si incontrano in sistemi centralizzati,

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

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

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

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

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

Ingegneria del Software - Il Ciclo Lungo

Ingegneria del Software - Il Ciclo Lungo Ingegneria del Software - Il Ciclo Lungo Alessandro Martinelli alessandro.martinelli@unipv.it 10 Marzo 2014 Il Ciclo Lungo Il Versioning e la Condivisione di Codice Organizzazione dei Pacchetti La Modellazione

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

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

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

APPENDICE. Procedure in SQL (1)

APPENDICE. Procedure in SQL (1) APPENDICE Procedure in SQL Transazioni in SQL Embedded SQL Remote Procedure Call Appendice 1 Procedure in SQL (1) Standard SQL2 permette di definire procedure, associate a singoli comandi SQL, memorizzate

Dettagli

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

1. ABSTRACT 2. INTRODUZIONE PROGETTO DI UN INFRASTRUTTURA GERARCHICA PER SERVIZI DI FILE HOSTING 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

Dettagli

Lezione 10. Scheduling nei sistemi multiprocessori. Esempio: P=2 processori. Scheduling dei processi

Lezione 10. Scheduling nei sistemi multiprocessori. Esempio: P=2 processori. Scheduling dei processi Lezione 10 Cenni ai sistemi operativi distribuiti 2. Gestione della CPU e della memoria nei multiprocessori Gestione dei processi Scheduling Bilanciamento del carico Migrazione dei processi Gestione della

Dettagli

Università degli Studi di Napoli Federico II Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica.

Università degli Studi di Napoli Federico II Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica. Università degli Studi di Napoli Federico II Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica Corso di Sistemi Distribuiti Prof. Stefano Russo Caratterizzazionedei SistemiDistribuiti

Dettagli

Sommario. G. Piscitelli

Sommario. G. Piscitelli Sommario Interprocess Communication Processi (e thread) cooperanti Il paradigma produttore-consumatore Shared Memory e Inter Process Communication (IPC) facility Proprietà caratteristiche della comunicazione

Dettagli

TRANSAZIONI. Una transazione è una successione di operazioni che si può concludere con successo o con insuccesso.

TRANSAZIONI. Una transazione è una successione di operazioni che si può concludere con successo o con insuccesso. Una transazione è una successione di operazioni che si può concludere con successo o con insuccesso. Nel caso di successo, i risultati delle operazioni effettuate devono essere resi definitivi; invece,

Dettagli

Introduzione. Coordinazione Distribuita. Ordinamento degli eventi. Realizzazione di. Mutua Esclusione Distribuita (DME)

Introduzione. Coordinazione Distribuita. Ordinamento degli eventi. Realizzazione di. Mutua Esclusione Distribuita (DME) Coordinazione Distribuita Ordinamento degli eventi Mutua esclusione Atomicità Controllo della Concorrenza Introduzione Tutte le questioni relative alla concorrenza che si incontrano in sistemi centralizzati,

Dettagli

Introduzione ai Sistemi Distribuiti

Introduzione ai Sistemi Distribuiti Università degli Studi di Roma Tor Vergata Facoltà di Ingegneria Introduzione ai Sistemi Distribuiti Corso di Sistemi Distribuiti Valeria Cardellini Anno accademico 2008/09 Definizioni di SD Molteplici

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

Tecnologia di un Database Server (centralizzato) Gestione dell affidabilità

Tecnologia di un Database Server (centralizzato) Gestione dell affidabilità Affidabilità Basi di Dati / Complementi di Basi di Dati 1 Tecnologia di un Database Server (centralizzato) Gestione dell affidabilità Angelo Montanari Dipartimento di Matematica e Informatica Università

Dettagli

La rete è una componente fondamentale della

La rete è una componente fondamentale della automazioneoggi Attenti alle reti La telematica si basa prevalentemente sulle reti come mezzo di comunicazione per cui è indispensabile adottare strategie di sicurezza per difendere i sistemi di supervisione

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

Sincronizzazione nei Sistemi Distribuiti

Sincronizzazione nei Sistemi Distribuiti Sincronizzazione nei Sistemi Distribuiti Sincronizzazione dei Clock In un sistema centralizzato la misurazione del tempo non presenta ambiguità. (ogni computer ha il proprio clock) In un sistema distribuito

Dettagli

Implementazione del File System

Implementazione del File System Implementazione del file system Implementazione del File System Struttura del file system. Realizzazione del file system. Implementazione delle directory. Metodi di allocazione. Gestione dello spazio libero.

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

CAPITOLO 27 SCAMBIO DI MESSAGGI

CAPITOLO 27 SCAMBIO DI MESSAGGI CAPITOLO 27 SCAMBIO DI MESSAGGI SCAMBIO DI MESSAGGI Sia che si guardi al microkernel, sia a SMP, sia ai sistemi distribuiti, Quando i processi interagiscono fra loro, devono soddisfare due requisiti fondamentali:

Dettagli

Università degli Studi di Napoli Federico II Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica.

Università degli Studi di Napoli Federico II Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica. Università degli Studi di Napoli Federico II Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica Corso di Sistemi Distribuiti Prof. Stefano Russo Modellidi SistemiDistribuiti

Dettagli

Sistemi Distribuiti. Il corso: informazioni utili AA 2006/2007. Riferimenti del docente: Ricevimento: Materiale Didattico:

Sistemi Distribuiti. Il corso: informazioni utili AA 2006/2007. Riferimenti del docente: Ricevimento: Materiale Didattico: Sistemi Distribuiti Corso di Laurea Specialistica in Telecomunicazioni AA 2006/2007 Slides del corso Sara Tucci Piergiovanni Il corso: informazioni utili Riferimenti del docente: - sito web: www.dis.uniroma1.it/

Dettagli

SISTEMI OPERATIVI. Realizzazione del file system. Prof. Luca Gherardi Prof.ssa Patrizia Scandurra (anni precedenti) (MODULO DI INFORMATICA II)

SISTEMI OPERATIVI. Realizzazione del file system. Prof. Luca Gherardi Prof.ssa Patrizia Scandurra (anni precedenti) (MODULO DI INFORMATICA II) SISTEMI OPERATIVI (MODULO DI INFORMATICA II) Realizzazione del file system Prof. Luca Gherardi Prof.ssa Patrizia Scandurra (anni precedenti) Università degli Studi di Bergamo a.a. 2012-13 Sommario Realizzazione

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

Seminario di Sistemi Distribuiti: RPC su SOAP

Seminario di Sistemi Distribuiti: RPC su SOAP Corso di Sistemi Distribuiti Prof. S. Balsamo Seminario di Sistemi Distribuiti: RPC su SOAP [ 777775] 1 INTRODUZIONE 3 2 RPC 3 3 SOAP (SIMPLE OBJECT ACCESS PROTOCOL) 3 4 UTILIZZO DI SOAP COME PROTOCOLLO

Dettagli

Coordinamento e sincronizzazione

Coordinamento e sincronizzazione Coordinamento e sincronizzazione Tempo locale e globale Nei sistemi distribuiti non esiste un orologio fisico globale Algoritmi di sincronizzazione e di coordinamento Applicazioni: correttezza di sequenze

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

Sistemi Operativi STRUTTURA DEI SISTEMI OPERATIVI 3.1. Sistemi Operativi. D. Talia - UNICAL

Sistemi Operativi STRUTTURA DEI SISTEMI OPERATIVI 3.1. Sistemi Operativi. D. Talia - UNICAL STRUTTURA DEI SISTEMI OPERATIVI 3.1 Struttura dei Componenti Servizi di un sistema operativo System Call Programmi di sistema Struttura del sistema operativo Macchine virtuali Progettazione e Realizzazione

Dettagli

INTRODUZIONE A RETI E PROTOCOLLI

INTRODUZIONE A RETI E PROTOCOLLI PARTE 1 INTRODUZIONE A RETI E PROTOCOLLI Parte 1 Modulo 1: Introduzione alle reti Perché le reti tra computer? Collegamenti remoti a mainframe (< anni 70) Informatica distribuita vs informatica monolitica

Dettagli

Sistemi Distribuiti. Introduzione Definizione Vantaggi e svantaggi Architetture hardware e software Problemi di progetto. Sistemi Operativi mod.

Sistemi Distribuiti. Introduzione Definizione Vantaggi e svantaggi Architetture hardware e software Problemi di progetto. Sistemi Operativi mod. Sistemi Distribuiti Introduzione Definizione Vantaggi e svantaggi Architetture hardware e software Problemi di progetto 19.1 Introduzione A metà degli anni quaranta inizia l era dei calcolatori elettronici

Dettagli

Introduzione. Sistemi Distribuiti. Introduzione. Introduzione. Definizione di sistema distribuito. Introduzione

Introduzione. Sistemi Distribuiti. Introduzione. Introduzione. Definizione di sistema distribuito. Introduzione Sistemi Distribuiti Definizione Vantaggi e svantaggi Architetture hardware e software Problemi di progetto A metà degli anni quaranta inizia l era dei calcolatori elettronici moderni: grandi, costosi e

Dettagli

File system. Realizzazione del file system. Struttura del file system. Struttura del file system. Realizzazione del file system

File system. Realizzazione del file system. Struttura del file system. Struttura del file system. Realizzazione del file system Realizzazione del file system Struttura del file system Metodi di allocazione: Contigua Concatenata Indicizzata Gestione dello spazio libero Realizzazione delle directory Efficienza e prestazioni Ripristino

Dettagli

Recovery manager Gestore della affidabilità

Recovery manager Gestore della affidabilità Riferimenti Basi di Dati Complementi Parte 2: Tecnologie per DBMS Parte 2.5: Recovery Manager Trasparenze parte Recovery manager Basi di Dati Atzeni et al. - Capitolo 2.1, 2.2 Anche: Garcia Molina, Ullman,

Dettagli

Realizzazione del file system

Realizzazione del file system Realizzazione del file system Struttura del file system Metodi di allocazione: Contigua Concatenata Indicizzata Gestione dello spazio libero Realizzazione delle directory Efficienza e prestazioni Ripristino

Dettagli

Informatica Documentale

Informatica Documentale Informatica Documentale Ivan Scagnetto (scagnett@dimi.uniud.it) Stanza 3, Nodo Sud Dipartimento di Matematica e Informatica Via delle Scienze, n. 206 33100 Udine Tel. 0432 558451 Ricevimento: giovedì,

Dettagli

Introduzione. Laurea magistrale in ingegneria informatica A.A. 2011-2012. Leonardo Querzoni. Versioni al tratto. Versione 3D

Introduzione. Laurea magistrale in ingegneria informatica A.A. 2011-2012. Leonardo Querzoni. Versioni al tratto. Versione 3D Introduzione Versioni al tratto Versione 3D Sistemi La versione negativa Distribuiti 3D prevede l utilizzo dell ombra esclusivamente sul fondo colore Rosso Sapienza. Laurea magistrale in ingegneria informatica

Dettagli

CAPITOLO 1 I SISTEMI OPERATIVI

CAPITOLO 1 I SISTEMI OPERATIVI CAPITOLO 1 I SISTEMI OPERATIVI Introduzione ai sistemi operativi pag. 3 La shell pag. 3 Tipi di sistemi operativi pag. 4 I servizi del sistema operativo pag. 4 La gestione dei file e il file system Il

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

Transazioni. Architettura di un DBMS. Utente/Applicazione. transazioni. Transaction Manager. metadati, statistiche.

Transazioni. Architettura di un DBMS. Utente/Applicazione. transazioni. Transaction Manager. metadati, statistiche. Query/update Query plan Execution Engine richieste di indici, record e file Index/file/record Manager comandi su pagine Query Compiler Buffer Manager Lettura/scrittura pagine Architettura di un DBMS Utente/Applicazione

Dettagli

Mobilità di Codice. Massimo Merro Programmazione di Rete 128 / 144

Mobilità di Codice. Massimo Merro Programmazione di Rete 128 / 144 Mobilità di Codice Abbiamo già visto come un dato host possa trasmettere un oggetto (serializzabile) ad un altro host. Quest ultimo potrà eseguire l oggetto pur non possedendo il bytecode della classe

Dettagli

LAN MAN WAN. Una internet è l'insieme di più reti reti distinte collegate tramite gateway/router

LAN MAN WAN. Una internet è l'insieme di più reti reti distinte collegate tramite gateway/router Rete di reti (interrete, internet) 2 Prof. Roberto De Prisco TEORIA - Lezione 8 Rete di reti e Internet Università degli studi di Salerno Laurea e Diploma in Informatica Una rete di comunicazione è un

Dettagli

Il DNS e la gestione degli indirizzi IP. Appunti a cura del prof. ing. Mario Catalano

Il DNS e la gestione degli indirizzi IP. Appunti a cura del prof. ing. Mario Catalano Il DNS e la gestione degli indirizzi IP Appunti a cura del prof. ing. Mario Catalano Indirizzi fisici e indirizzi astratti Ogni macchina all interno di una rete è identificata da un indirizzo hardware

Dettagli

Introduzione alle applicazioni di rete

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

Dettagli

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

Transazioni - Parte 1

Transazioni - Parte 1 Basi di dati II Lezione 3 09/10/2008 Caputo Domenico Cosimo, Francesco Pichierri Transazioni - Parte 1 Le transazioni hanno a che fare con la programmabilità delle basi di dati. Prima di trattarle è necessaria

Dettagli

Replicazione. Requisisti di consistenza i clienti devono ricevere risposte consistenti e coerenti. Motivazioni

Replicazione. Requisisti di consistenza i clienti devono ricevere risposte consistenti e coerenti. Motivazioni Replicazione Replicazione dei dati: gestione e manutenzione di un insieme di copie dei dati Motivazioni: - disponibilità - tolleranza ai guasti - prestazioni aching diverso da replicazione aching non aumenta

Dettagli

TECNOLOGIE E PROGETTAZIONE DI SISTEMI INFORMATICI E DI TELECOMUNICAZIONI

TECNOLOGIE E PROGETTAZIONE DI SISTEMI INFORMATICI E DI TELECOMUNICAZIONI TECNOLOGIE E PROGETTAZIONE DI SISTEMI INFORMATICI E DI TELECOMUNICAZIONI Confronto tra ISO-OSI e TCP/IP, con approfondimento di quest ultimo e del livello di trasporto in cui agiscono i SOCKET. TCP/IP

Dettagli

Gestione delle transazioni. Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 1

Gestione delle transazioni. Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 1 Gestione delle transazioni Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 1 Transazioni v L esecuzione concorrente dei programmi utente è essenziale per le buone prestazioni del DBMS Poiché

Dettagli

Identità sulla rete protocolli di trasmissione (TCP-IP) L architettura del sistema. Dal livello A al livello B

Identità sulla rete protocolli di trasmissione (TCP-IP) L architettura del sistema. Dal livello A al livello B Identità sulla rete protocolli di trasmissione (TCP-IP) L architettura del sistema contenuto della comunicazione sistema per la gestione della comunicazione sottosistema C sottosistema B sottosistema A

Dettagli

CORSO DI RETI SSIS. Lezione n.3 9 novembre 2005 Laura Ricci

CORSO DI RETI SSIS. Lezione n.3 9 novembre 2005 Laura Ricci CORSO DI RETI SSIS Lezione n.3 9 novembre 2005 Laura Ricci IL LIVELLO TRASPORTO realizza un supporto per la comunicazione logica tra processi distribuiti comunicazione logica = astrazione che consente

Dettagli

Cenni di JBoss Clustering

Cenni di JBoss Clustering Cenni di JBoss Clustering Università di Bologna CdS Laurea Magistrale in Ingegneria Informatica I Ciclo - A.A. 2012/2013 Corso di Sistemi Distribuiti M Cenni di Clustering di Applicazioni in JBoss Application

Dettagli

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

WebRatio. L altra strada per il BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8

WebRatio. L altra strada per il BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 WebRatio L altra strada per il BPM Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 Il BPM Il BPM (Business Process Management) non è solo una tecnologia, ma più a grandi linee una disciplina

Dettagli

INTRODUZIONE. Motivazioni e Obbiettivi

INTRODUZIONE. Motivazioni e Obbiettivi INTRODUZIONE Motivazioni dei sistemi distribuiti Caratteristiche generali Alcuni richiami sui database centralizzati Standardizzazione dei dati (ANSI/SPARC) Funzioni dei DBMS relazionali Problematiche

Dettagli

Navigare verso il cambiamento. La St r a d a. p i ù semplice verso il ca m b i a m e n t o

Navigare verso il cambiamento. La St r a d a. p i ù semplice verso il ca m b i a m e n t o Navigare verso il cambiamento La St r a d a p i ù semplice verso il ca m b i a m e n t o Le caratteristiche tecniche del software La Tecnologia utilizzata EASY è una applicazione Open Source basata sul

Dettagli

SISTEMI OPERATIVI. Sincronizzazione dei processi. Domande di verifica. Luca Orrù Centro Multimediale Montiferru 30/05/2007

SISTEMI OPERATIVI. Sincronizzazione dei processi. Domande di verifica. Luca Orrù Centro Multimediale Montiferru 30/05/2007 2007 SISTEMI OPERATIVI Sincronizzazione dei processi Domande di verifica Luca Orrù Centro Multimediale Montiferru 30/05/2007 Sincronizzazione dei processi 1. Si descrivano i tipi di interazione tra processi?

Dettagli

DB - Cenni sulla gestione delle transazioni

DB - Cenni sulla gestione delle transazioni transazioni Cenni sulla gestione delle transazioni in DBMS transazioni Cenni sulla gestione delle transazioni in DBMS Basato sulle slides di transazioni Cenni sulla gestione delle transazioni in DBMS Basato

Dettagli

ARP SPOOFING - Papaleo Gianluca

ARP SPOOFING - Papaleo Gianluca ARP SPOOFING - Papaleo Gianluca ARP spoofing è un attacco che può essere effettuato solo dall interno di una rete locale o LAN (Local Area Network). Questa tecnica si basa su alcune caratteristiche di

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

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

* Accesso ai file remoti - trasferimento effettivo dei dati mediante RPC - aumento delle prestazioni tramite caching

* Accesso ai file remoti - trasferimento effettivo dei dati mediante RPC - aumento delle prestazioni tramite caching * Sistemi operativi di rete: ambiente composto da risorse remote accessibili esplicitamente con controllo utente. Funzioni principali (demone); - login remoto (telnet) - trasferimento di file remoti (FTP)

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

Appunti di Sistemi Distribuiti

Appunti di Sistemi Distribuiti Appunti di Sistemi Distribuiti Matteo Gianello 27 settembre 2013 1 Indice 1 Introduzione 3 1.1 Definizione di sistema distribuito........................... 3 1.2 Obiettivi.........................................

Dettagli

La rete: modelli di riferimento. La rete: modelli di riferimento. La rete: modelli di riferimento. La rete: modelli di riferimento Indice

La rete: modelli di riferimento. La rete: modelli di riferimento. La rete: modelli di riferimento. La rete: modelli di riferimento Indice Indice 1. Definizioni essenziali 2. Modelli di rete 3. Reti fisiche 4. Protocolli di rete 5. Modelli di riferimento 6. Raffronto tra modelli Architettura degli Elaboratori 2 - T. Vardanega Pagina 275 Definizioni

Dettagli

Tesina esame Programmazione di Sistemi Mobile realizzata da Roberto Giuliani matricola 633688. Sockets e DatagramSocket

Tesina esame Programmazione di Sistemi Mobile realizzata da Roberto Giuliani matricola 633688. Sockets e DatagramSocket Tesina esame Programmazione di Sistemi Mobile realizzata da Roberto Giuliani matricola 633688 Sockets e DatagramSocket Windows Phone prevede un interfaccia di programmazione per garantire agli sviluppatori

Dettagli

Cos è un file system? File system Distribuiti. Cos è un sistema distribuito? Operazioni fondamentali. Struttura di un DFS.

Cos è un file system? File system Distribuiti. Cos è un sistema distribuito? Operazioni fondamentali. Struttura di un DFS. Cos è un file system? File system Distribuiti Corso di Sistemi per Elaborazione dell Informazione Prof. Carpentieri Bruno A.A. 2004/2005 Un file system è il mezzo logico con cui un sistema operativo memorizza

Dettagli

RMI Remote Method Invocation

RMI Remote Method Invocation RMI Remote Method Invocation [Pagina intenzionalmente vuota] (1 12 2004) slide 4:1/18 (p.106) Un applicazione RMI è un applicazione distribuita ad oggetti. Applicazione RMI tipica, strutturata in: server:

Dettagli

CORSO I.F.T.S TECNICHE PER LA PROGETTAZIONE E LA GESTIONE DI DATABASE

CORSO I.F.T.S TECNICHE PER LA PROGETTAZIONE E LA GESTIONE DI DATABASE CORSO I.F.T.S TECNICHE PER LA PROGETTAZIONE E LA GESTIONE DI DATABASE Ing. Mariano Di Claudio Lezione del 24/09/2014 Indice 1. Aspetti di Data Management CouchBase 2. Aspetti Architetturali Infrastruttura

Dettagli

INGEGNERIA DEL SOFTWARE

INGEGNERIA DEL SOFTWARE INGEGNERIA DEL SOFTWARE DESIGN Avvertenza: gli appunti si basano sul corso di Ingegneria del Software tenuto dal prof. Picco della facoltà di Ingegneria del Politecnico di Milano (che ringrazio per aver

Dettagli

Introduzione. Il principio di localizzazione... 2 Organizzazioni delle memorie cache... 4 Gestione delle scritture in una cache...

Introduzione. Il principio di localizzazione... 2 Organizzazioni delle memorie cache... 4 Gestione delle scritture in una cache... Appunti di Calcolatori Elettronici Concetti generali sulla memoria cache Introduzione... 1 Il principio di localizzazione... 2 Organizzazioni delle memorie cache... 4 Gestione delle scritture in una cache...

Dettagli

UDP. Livello di Trasporto. Demultiplexing dei Messaggi. Esempio di Demultiplexing

UDP. Livello di Trasporto. Demultiplexing dei Messaggi. Esempio di Demultiplexing a.a. 2002/03 Livello di Trasporto UDP Descrive la comunicazione tra due dispositivi Fornisce un meccanismo per il trasferimento di dati tra sistemi terminali (end user) Prof. Vincenzo Auletta auletta@dia.unisa.it

Dettagli

Indice dei Contenuti

Indice dei Contenuti Corso Sistemi Distribuiti 6 cfu Docente: Prof. Marcello Castellano /24 Global State - 3 Mutua esclusione e sistemi concorrenti - 7 Algoritmi per la Mutua Esclusione - 10 Algoritmi basati su autorizzazioni

Dettagli

Quando si sa chiaramente come si deve comportare l applicazione si può analizzare una possibile soluzione applicativa.

Quando si sa chiaramente come si deve comportare l applicazione si può analizzare una possibile soluzione applicativa. Introduzione alla tecnologia JMX 1 Viene analizzata l architettura sottostante le Java Managment Extensions (JMX) mostrandone un utilizzo applicativo e analizzando altri possibili scenari d uso di Ivan

Dettagli

Reti di Telecomunicazione Lezione 6

Reti di Telecomunicazione Lezione 6 Reti di Telecomunicazione Lezione 6 Marco Benini Corso di Laurea in Informatica marco.benini@uninsubria.it Lo strato di applicazione protocolli Programma della lezione Applicazioni di rete client - server

Dettagli

Architettura di un calcolatore

Architettura di un calcolatore 2009-2010 Ingegneria Aerospaziale Prof. A. Palomba - Elementi di Informatica (E-Z) 7 Architettura di un calcolatore Lez. 7 1 Modello di Von Neumann Il termine modello di Von Neumann (o macchina di Von

Dettagli

Basi di Dati Distribuite

Basi di Dati Distribuite Basi di Dati Distribuite P. Atzeni, S. Ceri, S. Paraboschi, R. Torlone (McGraw-Hill Italia) Basi di dati: architetture linee di evoluzione - seconda edizione Capitolo 3 Appunti dalle lezioni SQL come DDL

Dettagli

Le transazioni. Dott. Doria Mauro doriamauro@gmail.com

Le transazioni. Dott. Doria Mauro doriamauro@gmail.com Hibernate Le transazioni Dott. Doria Mauro doriamauro@gmail.com Introduzione La demarcazione delle transazioni può essere fatta: In maniera programmatica: demarcazione all interno del codice applicativo.

Dettagli

Archivi e database. Lezione n. 7

Archivi e database. Lezione n. 7 Archivi e database Lezione n. 7 Dagli archivi ai database (1) I dati non sempre sono stati considerati dall informatica oggetto separato di studio e di analisi Nei primi tempi i dati erano parte integrante

Dettagli