CAPITOLO 1: INTRODUZIONE

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "CAPITOLO 1: INTRODUZIONE"

Transcript

1 SEI: CAPITOLO 1 -> INTRODUZIONE COSTANTE LUCA GIARDINO DANIELE PALO UMBERTO CAPITOLO 1: INTRODUZIONE Un sistema distribuito è una collezione di computer indipendenti che appaiono come un singolo sistema coerente ai suoi utenti, indipendentemente dal punto di accesso. Gli utenti e le applicazioni possono interagire con un sistema distribuito in modo consistente ed uniforme, indipendentemente da dove e quando l interazione ha luogo. I sistemi distribuiti dovrebbero anche essere relativamente facili da espandere e scalabili. Un sistema distribuito organizzato è come un middleware. Il layer del middleware si estende su diverse macchine ed offre ad ogni applicazione la stessa interfaccia. Anche se si utilizzano sistemi operativi diversi, l infrastruttura deve tenere conto di queste differenze ed offrire agli utenti lo stesso servizio. OBIETTIVI Gli obiettivi di un sistema distribuito sono: Facilitare l accesso a risorse remote per facilitare la condivisione (sicurezza e privacy): far si che ci sia una facilità nell accesso a determinate risorse per lo più hardware. Questo concetto fa si che il sistema distribuito tiene conto degli standard. I due tipici problemi di cui si cerca di tener conto sono da un lato la sicurezza e dall altro la privacy. Si deve evitare che qualcuno possa ottenere delle informazioni sensibili riservate. Nascondere che le risorse siano distribuite sulla rete (trasparenza): ci sono varie forme di trasparenza quali: o Trasparenza degli accessi: dovrebbe essere nascosta qualsiasi differenza sulla rappresentazione e su come una risorsa può essere acceduta. Bisogna definire le interfacce. Un sistema distribuito ben progettato permette lo spostamento di una risorsa in modo del tutto trasparente. o Trasparenza della locazione: nascondere dove una risorsa è allocata. o Trasparenza della migrazione: nascondere che una risorsa può essere spostata in un altra locazione. o Trasparenza della rilocazione: nascondere che una risorsa può essere spostata mentre è in uso. o Trasparenza della replicazione: nascondere che una risorsa è replicata. o Trasparenza della concorrenza: nascondere che una risorsa può essere usata da utenti concorrenti. o Trasparenza dei fallimenti: nascondere i fallimenti e il recupero delle risorse. Bisogna pensare in questo caso al concetto di replica, aumentando i costi ma giungendo ad un buon compromesso. Apertura (standard): in un sistema distribuito devono essere ben definite le interfacce dei servizi offerti. Se questo lavoro viene effettuato con precisione, si raggiunge il concetto di precisione. Si parla anche di interoperabilità e di portabilità. Un altra problematica è quella legata alla cache distribuita. 1

2 SEI: CAPITOLO 1 -> INTRODUZIONE COSTANTE LUCA GIARDINO DANIELE PALO UMBERTO Vi sono diversi problemi legati alla cache quali la coerenza, ossia l aggiornamento dei dati. Interoperabilità significa che 2 implementazioni di sistemi o componenti di 2 diversi produttori possono coesistere e collaborare, basandosi univocamente su reciproci servizi specificati da uno standard comune. Portabilità significa che un applicazione sviluppata per il sistema operativo A può essere eseguita senza modifica su un SO B differente che implementa le stesse interfacce di A. Scalabilità: un sistema distribuito come idea di base deve essere scalabile. Le 3 forme di scalabilità hanno dei problemi connessi: o Scalabilità rispetto alla dimensione: possibilità che il sistema cresca di dimensione. Es. un servizio centralizzato posto su un singolo server per tutti gli utenti. o Scalabilità geografica: possibilità di aggiungere altri host. Una delle ragioni principali per cui è difficile pensare alla scalabilità di sistemi distribuiti progettati per una rete locale è che essi si basano sulla comunicazione sincrona. La comunicazione su reti geografiche, invece, è inaffidabile e praticamente sempre punto a punto. o Scalabilità di tipo amministrativo: nell aggiunta di host possono crearsi problemi di amministrazione. Es. il problema degli algoritmi centralizzati che cercano di intercettare i flussi per stabilire delle regole. Un problema intrinseco di un algoritmo centralizzato è che si dovrebbero collezionare tutti i dati del sistema e mandare il tutto ad un unico server dove gira il nostro algoritmo. In un sistema molto grande questo è del tutto impossibile e non va utilizzato. In questo caso si usano algoritmi decentralizzati le cui caratteristiche principali sono: Nessuna macchina deve avere le informazioni complete sullo stato del sistema; Le macchine possono avere delle decisioni basate soltanto su informazioni locali; I fallimenti su una macchina non devono interrompere l algoritmo; Non ci sono assunzioni implicite che esista un clock globale. Tecniche di scalabilità Esistono essenzialmente 3 tecniche di scaling: 1. Nascondere le latenze nella comunicazione: è importante per ottenere la scalabilità dal punto di vista geografico. Essenzialmente significa usare solo la comunicazione asincrona. Esistono tuttavia molte applicazioni che non possono usufruire della comunicazione asincrona. In questi casi la soluzione migliore è quello di evitare che il carico venga effettuato tutto dal server ma spostarne qualcuno lato client. 2. Distribuzione: consiste nel prendere un componente, spezzarlo in parti più piccole e distribuire tali parti nel sistema. Un esempio eccellente è il DNS. 3. Repliche: la replica non solo incrementa la disponibilità delle risorse ma aiuta anche a bilanciare il carico, migliorando cosi le prestazioni. Il caching è una forma speciale di replica che consiste nel fare una copia di una risorsa di solito vicino al client che la deve utilizzare. Il caching e la replica causano problemi di consistenza. 2

3 SEI: CAPITOLO 1 -> INTRODUZIONE COSTANTE LUCA GIARDINO DANIELE PALO UMBERTO Tranelli Errori classici nella progettazione di un applicazione distribuita sono: La rete è affidabile; La rete è sicura; La rete è omogenea; La topologia non cambia; La latenza è zero; Ampiezza di banda infinita; Il costo di trasporto è zero; C è un solo amministratore. TIPI DI SISTEMI DISTRIBUITI Per calcolo parallelo: CLUSTER. L hardware sottostante è costituito da un insieme di workstation connesse da una rete locale ad alta velocità. Ogni nodo ha lo stesso SO. o o Beowulf: ogni cluster è costituito da una collezione di nodi di calcolo controllati ed accessibili per mezzo di un singolo nodo principale; Mosix: in alternativa all organizzazione gerarchica di Beowulf, Mosix cerca di dare l immagine di un sistema singolo al cluster; il che significa che un cluster offre ad un processo la trasparenza alla distribuzione sembrando un singolo computer. L alto grado di trasparenza permette ai processi di migrare dinamicamente tra i nodi. 3

4 SEI: CAPITOLO 1 -> INTRODUZIONE COSTANTE LUCA GIARDINO DANIELE PALO UMBERTO Grid: presenta un grado elevato di eterogeneità. È utilizzato per sfruttare la potenza di calcolo di macchine dislocate sul territorio. L architettura si compone di 4 livelli: o Fabric layer: fornisce le interfacce alle risorse locali in uno specifico sito; o Connectivity layer: si compone di protocolli di comunicazione per il supporto delle transazioni grid che richiedono l'uso di molteplici risorse. o Resource layer: gestisce le singole risorse. Usa le funzioni fornite dal connectivity layer e richiama direttamente le interfacce fornite dal fabric layer. o Collective layer: si occupa di gestire l accesso a risorse multiple e si compone di servizi per il rilevamento di risorse, l allocazione e la pianificazione di attività, la replica, ecc. o Application layer: è costituito dalle applicazioni che operano all interno di un organizzazione virtuale e che fanno uso della tecnologia grid. Sistemi transazionali Le operazioni su una base di dati sono solitamente portate a termine sotto forma di transazioni. Le caratteristiche principali di una transazione sono: 1. Atomiche: per il mondo esterno, la transazione è indivisibile. 2. Consistenti: le transazioni non violano le invarianti del sistema. 3. Isolate: transazioni concorrenti non interferiscono le une con le altre. 4. Durature: una volta che la transazione ha reso effettive le modifiche, esse sono permanenti. Le transazioni annidate sono importanti nei sistemi distribuiti, in quanto forniscono un metodo naturale di distribuzione di una transazione su molteplici macchine. Il componente che consiste nel punto cruciale per integrare le applicazioni a livello del server o della base dati era chiamato transaction processing monitor o TP monitor. Esistono molti tipi di middleware di comunicazione. Con le chiamate a procedura remota RPC, era come se la chiamata fosse locale. Con il diffondersi della programmazione ad oggetti, sono state sviluppate delle 4

5 SEI: CAPITOLO 1 -> INTRODUZIONE COSTANTE LUCA GIARDINO DANIELE PALO UMBERTO tecniche per consentire la chiamata ad oggetti remoti, portando a ciò che è conosciuto come invocazione di un metodo remoto RMI. RMI e RPC hanno lo svantaggio che sia il chiamante sia il chiamato devono essere attivi al momento della comunicazione. Sistemi distribuiti pervasivi Siamo oggi alle prese con sistemi distribuiti in cui l instabilità è il comportamento normale. In tali sistemi, che noi chiamiamo sistemi distribuiti pervasivi, i dispositivi sono spesso piccoli, a batteria, mobili e con una connessione esclusivamente senza fili. Sono state identificati 3 requisiti essenziali per un applicazione pervasiva: 1. Accettare i cambi di contesto 2. Incoraggiare la composizione ad hoc 3. Riconoscere la condivisione come default. Sistemi elettronici per l assistenza sanitaria Una importante classe di sistemi pervasivi sono quelle relative all assistenza sanitaria. I sistemi per l assistenza sanitaria personale sono spesso equipaggiati da vari sensori organizzati in una body-area network BAN. Da questo sistema derivano 2 architetture ovvie come mostrato in figura. Nella prima un hub centrale è parte della BAN e raccoglie le informazioni quando necessario. Nel secondo scenario, la BAN è continuamente agganciata a una rete esterna, attraverso una connessione senza fili, alla quale invia i dati monitorati. Per ragioni di efficienza, i dispositivi e le body-area network devono consentire l elaborazione dei dati interna, il che significa ad esempio, che i dati monitorati dovranno essere aggregati prima di essere memorizzati permanentemente o di essere inviati ad un medico. Reti di sensori Un ultimo esempio di sistemi pervasivi è quello delle reti di sensori. Una rete di sensori di solito è costituita da molti nodi relativamente piccoli. Le limitate risorse, le ristrette capacità di comunicazione e il consumo di batteria vincolato, richiedono che in fase di progettazione l efficienza sia uno degli obiettivi principali. La relazione con i sistemi distribuiti diviene chiara considerando le reti di sensori come basi di dati distribuite. Una rete di sensori può essere organizzata come una base di dati distribuita a partire da un 5

6 SEI: CAPITOLO 1 -> INTRODUZIONE COSTANTE LUCA GIARDINO DANIELE PALO UMBERTO modello in cui i sensori non cooperano, ma semplicemente inviano i loro dati a una base di dati centralizzata posizionata dove si trova l operatore, fino ad arrivare ad un modello in cui si inoltrano le interrogazioni ai sensori rilevanti e si lascia che ciascuno di loro elabori una risposta, richiedendo all operatore di aggregare correttamente le risposte ricevute. L elaborazione interna (in-network), come già abbiamo visto nel caso precedente, è realizzabile in molti modi ma quello ovvio è di inoltrare una richiesta a tutti i nodi attraverso un albero che li racchiude tutti e aggregare successivamente i risultati. 6

7 SEI: CAPITOLO 2 -> ARCHITETTURE COSTANTE LUCA GIARDINO DANIELE PALO UMBERTO CAPITOLO 2: ARCHITETTURE L'organizzazione dei sistemi distribuiti è per lo più relativa ai componenti software che costituiscono il sistema. Queste architetture software esprimono l'organizzazione e l'interazione dei vari componenti software. L'effettiva realizzazione di un sistema distribuito richiede che i componenti software siano architetture di sistema posizionati e istanziati su macchine reali. Ci sono diverse scelte possibili nel portare avanti questo compito. L'istanziazione finale di un'architettura software è spesso chiamata architettura di sistema. STILI ARCHITETTURALI Lo stile architetturale si esprime in termini di componenti, nel modo in cui sono connesse, dei dati scambiati tra loro ed infine di come questi elementi sono configurati congiuntamente in un sistema. Un componente è un'unità modulare con interfacce richieste e fornite ben definite, sostituibile nel suo ambiente. Il connettore è un meccanismo che media la comunicazione, la coordinazione o la cooperazione tra componenti. Gli stili più importanti sono: 1. architetture a livelli (layered); 2. architetture basate sugli oggetti; 3. architetture centrate sui dati; 7

8 SEI: CAPITOLO 2 -> ARCHITETTURE COSTANTE LUCA GIARDINO DANIELE PALO UMBERTO 4. architetture basate sugli eventi. Nello stile a livelli i componenti sono organizzati a strati in cui il componente di livello L i può richiamare componenti al livello sottostante L i-1 ma nessun altro vicino. Le architetture basate sugli oggetti seguono un'organizzazione meno rigida. Ogni oggetto corrisponde a ciò che abbiamo definito come componente e tali componenti sono connesse attraverso un meccanismo di chiamata a procedura remota. Questa architettura software corrisponde esattamente a quella clientserver. Le architetture basate sui dati si sviluppano attorno all'idea che i processi comunicano attraverso un repository comune. Nelle architetture basate sugli eventi i processi comunicano essenzialmente attraverso la propagazione di eventi. Per i sistemi distribuiti la propagazione di eventi generalmente è associata ai sistemi conosciuti come sistemi publish/subscribe. Il vantaggio principale è che i processi sono blandamente accoppiati. Non hanno necessità di riferirsi l'uno all'altro. Si dice anche che sono disaccoppiati nello spazio. Le varie architetture si possono combinare. ARCHITETTURE DI SISTEMA Architetture centralizzate Una classica architettura centralizzata è quella client-server. In questo modello i processi sono suddivisi in due gruppi. Un server è un processo che implementa uno specifico servizio. Un client è un processo che richiede un servizio a un server inviandogli una richiesta e aspettando una risposta. Tale comunicazione si può implementare per mezzo di un protocollo senza connessione se la rete sottostante è affidabile, nel qual caso è molto efficiente. Invece se i pacchetti vengono persi o corrotti non è banale rendere il protocollo di comunicazione affidabile. Infatti a volte è indispensabile che il messaggio arrivi al server ed arrivi una sola volta! Questa problematica deve essere gestita dal protocollo, per questo motivo molti sistemi client-server utilizzano un protocollo orientato alla connessione. Esistono anche operazioni, dette idempotenti, che possono essere eseguite più volte senza causare danni. Molte applicazioni client-server sono mirate a consentire ad un utente l'accesso a una base di dati, quindi è stata teorizzata una differenziazione basata su tre livelli, che segue essenzialmente lo stile architetturale: 1. il livello dell'interfaccia utente; 2. il livello applicativo; 3. il livello dei dati. 8

9 SEI: CAPITOLO 2 -> ARCHITETTURE COSTANTE LUCA GIARDINO DANIELE PALO UMBERTO Il livello dell'interfaccia utente contiene tutto ciò che è necessario per interfacciarsi direttamente con l'utente, come la gestione della visualizzazione. Il livello applicativo di solito contiene le applicazioni, mentre il livello dei dati gestisce i dati effettivi su cui si agisce. Per esempio consideriamo un motore di ricerca. L'interfaccia utente è molto semplice: un utente digita una stringa di parole chiave e gli viene di conseguenza mostrata una lista di titoli di pagine web. Il cuore del motore di ricerca è un programma che trasforma la stringa dell'utente in una o più interrogazioni della base di dati. Successivamente esso dispone in ordine i risultati in una lista, trasformandola in una serie di pagine html. Architetture multilivello La suddivisione in tre livelli logici suggerisce varie possibilità di distribuire fisicamente un'applicazione client-server su molte macchine. L'organizzazione più semplice si basa su due tipi di macchine: 1. una macchina client contenente solo i programmi che implementano il livello dell'interfaccia utente (o parte di esso); 2. una macchina server contenente il resto. È possibile avere configurazioni alternative spostando i livelli (o parti di essi) tra la macchina client e la macchina server. Per molti anni c'è stata una forte tendenza ad allontanarsi dalle configurazioni in cui il software client è posizionato sulle macchine dell'utente finale, in quanto la gestione di tali macchine è più complicata. Distinguendo solo i client dai server si perde di vista il fatto che un server può avere l'esigenza di agire anche da client, arrivando all'architettura a tre livelli fisici. In questa architettura i programmi che costituiscono parte del livello applicativo risiedono su un server diverso, ma possono anche essere parzialmente distribuiti sulle macchine client e server. 9

10 SEI: CAPITOLO 2 -> ARCHITETTURE COSTANTE LUCA GIARDINO DANIELE PALO UMBERTO Architetture decentralizzate L'elaborazione distribuita equivale a organizzare un'applicazione client-server come un'architettura multilivello. Questo tipo di distribuzione viene detta distribuzione verticale. La sua caratteristica principale è che viene ottenuta posizionando componenti logicamente diversi su macchine diverse. Nelle architetture moderne è spesso la distribuzione dei client e dei server che conta, il che viene definito come distribuzione orizzontale. In questo tipo di distribuzione, un client od un server possono essere suddivisi fisicamente in parti logicamente equivalenti che operano sull'insieme completo dei dati, ottenendo così un buon bilanciamento del carico. Una classe di architetture di sistema moderne che supportano la distribuzione orizzontale sono conosciute come sistemi peer-to-peer. In questi sistemi l'interazione tra processi è quasi tutta simmetrica: ogni processo agisce come client e come server allo stesso tempo (servent). Architetture peer-to-peer strutturate Viene creata una rete overlay tramite una procedura deterministica, che di solito è la creazione di una hash table distribuita (DHT). In un sistema basato su DHT ai dati viene assegnata una chiave casuale in uno spazio di identificatori grande (128, 160 bit). Allo stesso modo, anche ai nodi del sistema viene assegnato un numero casuale preso dallo stesso spazio. Nel sistema Chord i nodi sono logicamente organizzati in un anello tale per cui un dato con chiave k è mappato in un nodo con il più piccolo identificatore id >= k. Questo nodo è chiamato il successore della chiave k ed è indicato come succ(k). La ricerca di una chiave non segue l'organizzazione logica dei nodi nell'anello, ma ogni nodo mantiene dei collegamenti (shortcut) agli altri nodi in modo tale che la ricerca possa essere generalmente fatta in un numero di passi pari a O(log(N)), dove N è il numero di nodi della rete. Quando un nodo vuole unirsi al sistema, inizia col generare un identificatore casuale id. Quindi può semplicemente fare una ricerca dell'id che restituirà l'indirizzo di rete di succ(id). A questo punto il nodo che si sta unendo al rete può semplicemente contattare succ(id) e il suo predecessore ed inserirsi nell'anello. Ogni dato associato alla chiave id viene trasferito a succ(id). L'uscita dall'anello prevede che il nodo uscente id informi il proprio predecessore ed il proprio successore e trasferisce i suoi dati a succ(id). Il sistema Content Addressable Network (CAN) fornisce uno spazio di coordinate cartesiane d- dimensionale. Per esempio consideriamo uno spazio a due dimensioni [0,1]x[0,1] suddiviso tra sei nodi. Ogni nodo ha una regione associata. 10

11 SEI: CAPITOLO 2 -> ARCHITETTURE COSTANTE LUCA GIARDINO DANIELE PALO UMBERTO Ogni dato sarà assegnato a un unico punto in questo spazio, dopodiché è anche chiaro quale nodo è responsabile per quel dato. Quando un nodo P vuole unirsi al sistema, prende un punto arbitrario nello spazio di coordinate e successivamente crea il nodo Q nella cui regione cade il punto scelto. Il nodo Q quindi suddivide la propria regione in due metà e una di queste è assegnata al nodo P. L'uscita dal sistema è più problematica in quanto è chiaro che non è possibile semplicemente unire due regioni (una del nodo uscente, l'altra del nodo che si prenderà cura della zona) ed ottenere un rettangolo. Dovrà essere quindi eseguito periodicamente un processo in background per ripartizionare l'intero spazio. Architetture peer-to-peer non strutturate Uno degli obiettivi di molti sistemi peer-to-peer non strutturati è la costruzione di una rete overlay simile a un grafo disordinato. Il modello di base prevede che ogni nodo mantenga una lista di c vicini. La lista dei vicini è chiamata vista parziale. Ogni elemento nella lista identifica un altro nodo nella rete e ha un'età associata che indica da quanto tempo esiste il riferimento a quel nodo. Si usano due thread: Ci sono due modi di costruire una nuova vista. Il primo è che i due nodi decidano di scartare gli elementi che si sono inviati. Il secondo approccio è scartare quanto più elementi vecchi possibile. I protocolli che usano solo la modalità push o la modalità pull possono portare abbastanza facilmente a reti overlay disconnesse. In altre parole gruppi di nodi rimarranno isolati. Gestione della topologia di una rete overlay Un'osservazione chiave è che selezionando e scambiando attentamente gli elementi delle viste parziali è possibile costruire e mantenere delle reti overlay con topologie specifiche. Questa gestione delle topologie è ottenuta con un approccio a due livelli. Il livello più basso passa le sue viste parziali al livello più alto dove ha luogo una ulteriore selezione degli elementi. Ciò porta quindi ad una seconda lista di vicini corrispondenti alla topologia desiderata. 11

12 SEI: CAPITOLO 2 -> ARCHITETTURE COSTANTE LUCA GIARDINO DANIELE PALO UMBERTO Superpeer I sistemi precedenti possono avere grossi problemi di scalabilità. Per cercare di risolvere questo problema, molti sistemi peer-to-peer hanno proposto l'impiego di nodi speciali che mantengano un indice dei dati o che agiscano da intermediari, i superpeer. Ci si aspetta che i superpeer siano processi a lunga vita ed altamente stabili, per questo si introduce il problema della selezione dei nodi candidati ad essere superpeer. Archietture ibride Sistemi edge-server Una classe importate di sistemi distribuiti, organizzata come un'architettura ibrida, è costituita dai sistemi edge-server. Questi sistemi sono impiegati su Internet dove i server sono posizionati ai bordi della rete. Tali bordi sono costituiti dai confini tra la rete aziendale ed Internet vera e propria, come previsto, ad esempio, da un Internet Service Provider (ISP). Lo scopo principale di un edge-server è quello di fornire contenuti, eventualmente dopo aver applicato filtri e funzioni di transcodifica. Sistemi distribuiti collaborativi Nelle strutture ibride la questione principale è di entrare nel sistema, cosa per cui è spesso usato uno schema client-server tradizionale. BitTorrent è un sistema peer-to-peer per scaricare file. L'idea di base è che quando un utente finale cerca un file, di fatto scarica dei pezzi di file da altri utenti, finché i pezzi scaricati non possono essere assemblati per ottenere il file completo. Per scaricare un file, un utente deve accedere ad una directory globale che contiene i riferimenti ai cosiddetti file.torrent. Un file.torrent contiene le informazioni necessarie a scaricare uno specifico file o un insieme di file ed in particolare informazioni sul tracker, che è un server che mantiene un resoconto accurato dei nodi attivi che possiedono il file richiesto. Una volta identificati i nodi da cui scaricare i pezzi del file, il nodo che effettua il download diventa effettivamente attivo e sarà costretto ad aiutare gli altri fornendo pezzi del file che sta scaricando. BitTorrent combina soluzioni centralizzate a soluzioni decentralizzate ed è evidente che il collo di bottiglia è costituito dal tracker. 12

13 SEI: CAPITOLO 2 -> ARCHITETTURE COSTANTE LUCA GIARDINO DANIELE PALO UMBERTO Globule è molto simile all'architettura edge-server. Gli utenti finali, ma anche le aziende, forniscono volontariamente Web server avanzati capaci di collaborare nella replica di pagine Web. Nella sua forma più semplice, ciascuno di questi server ha i seguenti componenti: 1. un componente che può redirigere le richieste dei client ad altri server; 2. un componente per analizzare i pattern di accesso; 3. un componente per gestire la replica delle pagine Web. ARCHITETTURE E MIDDLEWARE A CONFRONTO Avere un middleware plasmato in base a un dato stile architetturale offre il vantaggio di rendere più facile lo sviluppo delle applicazioni. Un ovvio inconveniente è che un middleware può non essere più ottimale per quello che ha in mente lo sviluppatore. Interceptor Concettualmente un interceptor non è altro che un costrutto software che interrompe il normale flusso di controllo e consente ad altro codice di essere eseguito: 1. all'oggetto A viene fornita un'interfaccia locale esattamente uguale a quella fornita dall'oggetto B. A semplicemente richiama il metodo disponibile nell'interfaccia; 2. la chiamata di A è trasformata in un'invocazione a un oggetto generico, resa possibile attraverso un'interfaccia generale per l'invocazione di un oggetto messa a disposizione dal middleware della macchina dove risiede A; 3. l'invocazione a un oggetto generico viene trasformata in un messaggio inviato attraverso l'interfaccia di rete al livello di trasporto fornita dal sistema operativo di A. Approcci generali al software adattivo In realtà gli interceptor offrono un mezzo per adattare il middleware. La necessità di adattare nasce dal fatto che l'ambiente in cui le applicazioni distribuite sono eseguite cambia di continuo. Queste forti 13

14 SEI: CAPITOLO 2 -> ARCHITETTURE COSTANTE LUCA GIARDINO DANIELE PALO UMBERTO influenze hanno portato molti progettisti di middleware a prendere in considerazione la costruzione di software adattivo. Si distinguono tre tecniche per ottenere software adattivo: separazione degli ambiti; riflessione computazionale; progettazione basata su componenti. La separazione degli ambiti è legata al metodo tradizionale di rendere i sistemi modulari: separare le parti che implementano le funzionalità da quelle che si occupano d'altro. Il problema principale è che non si possono separare facilmente queste extrafunzionalità per mezzo della modularizzazione. Riflessione computazionale si riferisce alla capacità di un programma di controllare se stesso e, se necessario, di adattare il proprio comportamento. La progettazione basata su componenti consente di ottenere software adattivo per mezzo della composizione. Un sistema può essere configurato staticamente in fase di progettazione o dinamicamente durante l'esecuzione. Quest'ultima possibilità richiede supporto per il binding tardivo, una tecnica applicata con successo negli ambienti dei linguaggi di programmazione, ma anche nei sistemi operativi in cui i moduli possono essere caricati e scaricati a piacimento. Il processo rimane lento per i sistemi distribuiti, specialmente se si considera che la sostituzione di un componente richiede che se ne conoscano gli effetti sugli altri componenti. AUTOGESTIONE NEI SISTEMI DISTRIBUITI Modello a controllo dei feedback Un sistema autogestito ha il presupposto che gli adattamenti hanno luogo tramite uno o più cicli di controllo dei feedback. Il nucleo di un sistema a controllo dei feedback è costituito dai componenti che devono essere gestiti. Si suppone che questi componenti siano pilotabili attraverso parametri di input controllabili, ma il loro comportamento può essere influenzato da ogni tipo di input non controllabile. In molti casi misurare il comportamento può essere complicato. Ad esempio il tempo di risposta su Internet può variare moltissimo e dipenda anche da ciò che esattamente si sta misurando. In questi casi stimare accuratamente il tempo di risposta andata e ritorno può essere molto difficile. Ancora più complicato quando un nodo deve calcolare la latenza tra altri due nodi senza possibilità di intromettersi tra loro. Per questo motivo un ciclo di controllo dei feedback di solito contiene un componente per la stima metrica. Astrolabe Astrolabe è un sistema che può supportare il monitoraggio di sistemi distribuiti molto grandi. Organizza un gran numero di host in una gerarchia di zone. Ogni host esegue un processo Astrolabe, chiamato agente, che raccoglie le informazioni sulle zone in cui è contenuto tale host. Ogni host mantiene un insieme di attributi per la raccolta delle informazioni locali. Le informazioni raccolte da ogni macchina possono essere viste come un record in una base di dati e l'insieme di questi record costituiscono una relazione. Tuttavia le informazioni per zona possono solo essere calcolate dai record di base mantenuti dagli host. Le 14

15 SEI: CAPITOLO 2 -> ARCHITETTURE COSTANTE LUCA GIARDINO DANIELE PALO UMBERTO informazioni aggregate sono ottenute attraverso funzioni di aggregazione programmabili, molto simili a quelle disponibili in SQL. Globule Globule si basa su server di utenti finali collegati in Internet e sul fatto che questi server collaborino per ottimizzare le prestazioni attraverso la replica delle pagine Web. Nella forma più semplice Globule presume che Internet sia rappresentabile come un sistema edge-server. Il server d'origine cerca il server replicato esistente più vicino che possa agire come edge-server per il client e successivamente calcola la latenza verso quel server insieme alla massima ampiezza di banda. Una volta raccolte richieste sufficienti di una pagina, il server d'origine esegue una semplice analisi cosa-se. Tale analisi si riduce a una valutazione di diverse politiche di replica, dove una politica descrive dov'è replicata una pagina e come tale pagina venga mantenuta consistente. La percentuale di previsioni errate dipende dalla lunghezza della serie di richieste usata per predire e selezionare la politica successiva. L'errore nella previsione della politica migliore cresce se la traccia non è sufficientemente lunga, dal che si deduce la necessità di un numero sufficiente di richieste per fare una valutazione appropriata. L'errore tuttavia cresce anche se si usano troppe richieste: una traccia troppo lunga cattura infatti un numero così elevato di cambiamenti nei pattern d'accesso che predire la miglior politica da seguire diventa difficile se non impossibile. Esempio: gestione della riparazione automatica dei componenti in Jade Nel caso di cluster di computer diventa importate semplificare i problemi di gestione. Un metodo applicabile ai server costruiti usando un approccio basato sui componenti è di rilevare i malfunzionamenti dei componenti e sostituirli automaticamente. Jade segue quest'approccio. Le politiche sono definite esplicitamente e sono portate avanti in base al malfunzionamento rilevato. Supponiamo che sia stato rilevato il malfunzionamento di un nodo. In questo caso la politica di riparazione potrebbe indicare l'esecuzione dei seguenti passi: 1. chiudere ogni collegamento tra i componenti su nodi funzionanti e il componente sul nodo che non funziona; 2. richiedere al gestore dei nodi di far partire e di aggiungere al dominio un nuovo nodo; 3. configurare il nuovo nodo esattamente con gli stessi componenti del nodo che subito il crash; 4. ristabilire tutti i collegamenti che sono stati terminati. 15

16 SEI: CAPITOLO 3 -> PROCESSI COSTANTE LUCA GIARDINO DANIELE PALO UMBERTO CAPITOLO 3: I PROCESSI THREAD Un processo è un classico programma in esecuzione. Ogni qual volta vi è una comunicazione tra 2 processi utilizzando qualsiasi forma di IPC, quello che accade a livello fisico è che vi sono una serie di cambi di contesto dove la CPU cambia valori nei registri (switch contest). Si deve cercare di evitare i cambi di contesto. L idea del thread è di avere un oggetto che limita i cambi di contesto. Se il cambio avviene a livello di comunicazione, questo viene effettuato dal thread che utilizza memoria condivisa eliminando il cambio di contesto. L effetto può essere un sorprendente miglioramento delle prestazioni. Utilizzo dei thread nei sistemi non distribuiti La differenza è che nel processo il controllo è a carico del SO mentre in caso di thread il controllo è a carico dei programmatori. Ci sono 2 filosofie di base per la gestione dei thread con pregi e difetti. Il primo consiste nel creare una libreria che viene eseguita completamente a livello utente apportando diversi vantaggi quali: la creazione e la distruzione dei thread è meno costosa, il cambiamento di contesto tra thread può essere fatto spesso in poche istruzioni portando però lo svantaggio che se la chiamata è bloccante, allora il processo bloccherà tutti i thread ad esso appartenenti. Il secondo approccio consiste nel lasciare che il kernel sia conscio dei thread e si occupi del loro scheduling: in questo caso la creazione di un thread da parte del kernel porterà ad una chiamata di sistema e un cambiamento di contesto dei thread sarà costoso come quello di un processo. Una soluzione sta nell uso di una forma ibrida chiamata LWP lightweight processes. Un processo leggero viene eseguito nel contesto di un singolo processo pesante; per ogni processo pesante ci possono essere più processi leggeri fornendo anche un pacchetto di thread. La questione importante è che il pacchetto di thread è implementato completamente nello spazio utente; in altre parole tutte le operazioni sui thread vengono portate avanti senza l intervento del kernel. Questo significa che ogni processo leggero può eseguire il suo thread a livello utente. Uno svantaggio dei processi sono i processi bloccanti: molte chiamate quando vengono invocate bloccano l intero processo mentre potendo dividere un processo in svariati thread si può decidere di bloccare un solo thread e far continuare il lavoro degli altri. Un vantaggio del multithread è la possibilità di sfruttare il parallelismo quando si esegue il programma su sistemi multiprocessore. Quando si crea un processo leggero con una chiamata di sistema, gli si assegna un suo stack e lo si istruisce affinché esegua la routine di scheduling in cerca di un thread da eseguire. Se ci sono molti processi leggeri, ciascuno di loro eseguirà lo scheduler. Quando un processo leggero trova un thread eseguibile, cambia contesto su questo thread. Thread nei sistemi distribuiti In caso di un sistema distribuito, il discorso è leggermente più ampio. In più si possono avere 2 differenti approcci: usare lo schema multithread a livello client o server. Un browser web è un classico esempio di uso 16

17 SEI: CAPITOLO 3 -> PROCESSI COSTANTE LUCA GIARDINO DANIELE PALO UMBERTO client-thread. Il tipico metodo è quello di far partire tanti thread quanto sono gli oggetti presenti nella pagina facendo si che il browser non si blocchi su una determinata risorsa anche se l attesa può essere derivata da diverse particolarità del server. Se invece anche la parte server è multithread, questa situazione può apportare svariati vantaggi. Quello che accade è che le varie richieste a livello client, saranno divise in repliche che andranno ad occuparsi della richiesta. Un operazione onerosa bloccante è l accesso ad un file server: attraverso il multithread il dispatcher riceve dal client da un porta ben nota la richiesta di lettura di un file, affida il compito ad un determinato thread che esegue il suo compito mentre il dispatcher continua nella scelta di altri thread per altri compiti senza aspettare che il primo finisca il suo. Ci sono 3 modelli principali che può adottare un server: 1. Multithreads: vi è il parallelismo e le chiamate restano ancora bloccanti 2. Single threaded process: non vi è il parallelismo e le chiamate restano ancora bloccanti 3. Macchine a stati finiti: vi è il parallelismo e le chiamate diventano non bloccanti. VIRTUALIZZAZIONE Ruolo della virtualizzazione dei sistemi distribuiti Parlando dei processi, diventa naturale parlare di virtualizzazione. Bisogna vedere il server come se fosse dotato di n processori ognuno dedicato al singolo processo. La generalizzazione di questo concetto porta alla definizione di virtualizzazione. Ogni sistema distribuito offre in pratica un interfaccia di programmazione per il software più di alto livello come mostrato nella figura (a). In sostanza la virtualizzazione estende o sostituisce l interfaccia esistente cosi da imitare il comportamento di un altro sistema come si può notare dalla figura (b). Architetture delle macchine virtuali Ci sono 4 tipi di interfaccia: 1. interfaccia tra l hardware ed il software che consiste di istruzioni macchina che possono essere richiamate da ogni programma; 17

18 SEI: CAPITOLO 3 -> PROCESSI COSTANTE LUCA GIARDINO DANIELE PALO UMBERTO 2. interfaccia tra l hardware ed il software che consiste di istruzioni macchina che possono essere richiamate solo da programmi privilegiati, come un SO; 3. interfaccia che consiste di chiamate di sistema messe a disposizione dal SO; 4. interfaccia che consiste di chiamate di libreria che costituiscono quelle che in genere sono definite application programming interface (API). In molti casi le sopra citate chiamate di sistema sono nascoste da un API. L essenza della virtualizzazione è di imitare il comportamento di queste interfacce. La virtualizzazione può aver luogo in diversi modi: a partire da un hardware e da un sistema operativo, posso avere N runtime system, ciascuno dei quali fornisce essenzialmente un insieme di istruzioni astratte da impiegare per l esecuzione di applicazioni. Abbiamo un unico processo che offre al sistema sovrastante una propria architettura hardware completa (a). L altra alternativa un pò più forte è quella di vedere non più sistemi a runtime ma di avere un virtual machine monitor (VMM) che poggia direttamente sull hardware. Offre servizi di virtualizzazione che permettono ad N SO di vedere un proprio hardware (b). Sembra che le differenze siano minime ma il valore aggiunto di questa soluzione è che le N macchine possono essere spostate con elevata facilità da una macchina all altra (trasparenza massima). La virtualizzazione è nata perché ci si è resi conto che la velocità a cui andava l hardware era maggiore rispetto ai sistema legacy. Il problema era legato al funzionamento di questi software. Successivamente dato che i SO sono diminuiti di numero, la virtualizzazione ha iniziato a perdere piede sul commercio fino a quando l aumento vertiginoso delle risorse e della potenza ha di nuovo reso possibile la virtualizzazione. CLIENT Interfaccia utente di rete Quando i client sono distanti tra di loro e si ha una comunicazione tramite la rete, la comunicazione di solito avviene a livello applicazione (a). Un altra soluzione è quello della presenza di un middleware che gestisce un protocollo indipendente. Si cerca man mano che i collegamenti diventano più affidabili, di far si che le applicazioni prevedano un carico maggiore lato server e che il client effettui una computazione minima (b). 18

19 SEI: CAPITOLO 3 -> PROCESSI COSTANTE LUCA GIARDINO DANIELE PALO UMBERTO L esempio tipico è il sistema X-Window, nato a causa delle basse velocità di bande. L idea di base è che tutto risiede lato server e la comunicazione avviene tramite librerie lato client (Xlib). La parte interessante di questo approccio è che la comunicazione interessa soltanto lo scambio di comandi mentre l esecuzione avviene totalmente trasparente al client. Questo metodo è molto comodo perché ha necessità di poca banda per il funzionamento (thin client). L altro concetto tipico dei sistemi X è il concetto di documento composto. Nel momento in cui non ho una logica lato client, le mie applicazioni sono concepite come sotto-applicazioni. Software client per la trasparenza alla distribuzione Una questione tipica è che spesso si richiede di spostare una parte dell elaborazione lato client piuttosto che lato server applicando il concetto di distribuzione. Lato client c è uno stub che è un modulo software il quale a partire dalla definizione dell interfaccia descrive cosa il server ha da offrire. Lo stub fornisce la stessa interfaccia disponibile sul server, ma nasconde le possibili differenze nelle architetture delle macchine, così come la comunicazione reale. Le modalità di gestione della trasparenza all ubicazione, alla migrazione e al riposizionamento sono diverse. Nel caso in cui si voglia attuare una trasparenza alla replica, immaginiamo un sistema con server replicati. La replica può essere ottenuta inviando una richiesta a ogni server. Il software client può raccogliere in maniera trasparente tutte le risposte e passare una singola risposta all applicazione client. SERVER Progettazione lato server Un server concorrente, gestisce ogni richiesta attraverso un thread o una fork. Il tipico problema che si pone è quello di conoscere un determinato servizio offerto da un server. Vi sono sostanzialmente 2 soluzioni: 1. Un processo viene indirizzato ad una porta nota del server. Lato server, un daemon rimane in attesa su quella porta fino a quando non giunge una richiesta. Dato che su un server vi sono vari servizi, una soluzione è quella di avere un daemon su una determinata porta ben nota che tenga traccia di tutti i servizi associati alle rispettive porte (a). 2. Un altra soluzione è quella del superserver. Il client chiede il servizio al superserver il quale crea di volta in volta il server specifico che continua la comunicazione diretta con il client. Tale soluzione potrebbe essere adottata quando vi sono poche richieste (b). 19

20 SEI: CAPITOLO 3 -> PROCESSI COSTANTE LUCA GIARDINO DANIELE PALO UMBERTO È possibile effettuare una distinzione tra server con stato e senza stato. Un server senza stato non tiene traccia delle richieste precedenti e una richiesta dallo stesso client viene percepita come 2 richieste differenti, mentre un server con stato tiene traccia di alcune informazioni per ottimizzare richieste successive. Progettando un server, la scelta tra un progetto con stato e senza stato non dovrebbe influenzare i servizi forniti da quel server. Cluster di server Una famiglia particolare di server sono i CLUSTER SERVER. Sono una serie di macchine connesse attraverso una rete, che offrono servizi. I cluster server che consideriamo qui sono quelli in cui le macchine sono connesse attraverso una rete locale che offre una buona ampiezza di banda e bassi tempi di latenza. Di solito i client vedono questi server come un unica macchina. Un problema che nasce da questa configurazione è legato all indirizzamento delle richieste. Il primo livello consiste in uno switch che gestisce le richieste (gli switch a livello di trasporto accettano per esempio richieste di connessione TCP, oppure un web browser che accetta connessioni http, ecc), il secondo livello si occupa dell erogazione dei servizi e quindi del lato applicativo (di solito questi server sono eseguiti su hardware ad alte prestazioni dedicato a fornire capacità di calcolo) e vi è un terzo livello che si occupa della gestione e dell organizzazione dei dati (esempio servizi di streaming che utilizzano 3 tier), nel caso in cui cluster di server aziendali hanno la necessità che le applicazioni debbano essere eseguite su macchine relativamente di basso profilo. Il collo di bottiglia non è la capacità di calcolo richiesta ma l accesso alle unità di elaborazione. Il collo di bottiglia presente nel 1 livello, è lo switch, il cui compito risulta oneroso. Deve gestire le richieste da indirizzare a più server su più porte. Un altro problema è la gestione del carico di lavoro e la possibilità di migrare il codice da una macchina all altra per bilanciare il carico. Un tipico approccio per la gestione dello switch è noto come TCP handoff, che è costituito dalle seguenti fasi: quando un client effettua una richiesta, questa viene inoltrata allo switch; quest ultimo identifica il server cui è destinata la richiesta e la inoltra. D ora in avanti, la comunicazione sarà diretta tra client e server senza che lo switch prenda più parte della comunicazione. 20

21 SEI: CAPITOLO 3 -> PROCESSI COSTANTE LUCA GIARDINO DANIELE PALO UMBERTO Server distribuiti Nei server distribuiti possono sorgere alcune problematiche in quanto i punti di accesso possono essere modificati varie volte. Bisogna rendere trasparente ai client che il punto di accesso possa essere diverso ogni volta ed una soluzione può essere ad esempio il DNS. L idea di base è il concetto di Domain Name System in cui il server fa parte di una rete con indirizzo statico. Un DNS può restituire molti indirizzi, tutti associati allo stesso host name anche se in questo caso non si risolve il problema della richiesta di punti d accesso statici. L idea di base di un server distribuito è che i client traggano vantaggio da un server robusto, stabile e dalle alte prestazioni. Il concetto si può ottenere facendo uso dei servizi di rete disponibili (es. il supporto alla mobilità offerta da IPv6 MIPv6). Ogni nodo mobile appartiene ad una home network associandogli un indirizzo statico. Questa rete ha associato un router speciale conosciuto come home agent che si prende carico del traffico verso il nodo mobile quando questo è assente. A tal fine, quando un nodo mobile si sposta in un altra rete, gli viene assegnato un indirizzo fittizio (care of address). Questo indirizzo viene riportato all home agent del nodo che provvederà ad effettuare il redirect. Il client comunica virtualmente con il server ma comunica direttamente con l Home Agent. Gestione dei cluster di server PlanetLab Un esempio è il sistema PlanetLab. È un sistema particolare costituito da centinaia di computer che mettono a disposizione delle risorse. Queste risorse devono essere configurate in maniera simile formando un cluster server di 1 livello in cui l accesso, l elaborazione e la memorizzazione possono aver luogo su ogni nodo individualmente. Ogni nodo è organizzato come segue: 21

22 SEI: CAPITOLO 3 -> PROCESSI COSTANTE LUCA GIARDINO DANIELE PALO UMBERTO Le componenti importanti sono 2: a. Da un lato abbiamo un Virtual Machine Monitor (in questo caso è il SO Linux esteso). b. Dall altro abbiamo un vserver. Un vserver può essere visto come un ambiente separato in cui può essere eseguito un gruppo di processi. I processi in vserver diversi sono completamente indipendenti. Il VMM assicura che i vserver sono separati e per attuare ciò mette a disposizione dei tool. Una volta definiti i vserver, bisogna definire una slice che è un insieme di vserver ciascuno in esecuzione su un nodo diverso. Una slice può essere pensata come un cluster di server virtuali, implementato come una collezione di macchine virtuali. 3 sono le questioni principali: 1 I nodi appartengono ad aziende diverse. 2 Gli strumenti di monitoraggio disponibili sono vari, ma tutti si basano su una combinazione di hardware e software molto specifica. 3 I programmi che sono su slice differenti ma che girano sullo stesso nodo, non devono interferire con gli altri. Deve esserci la necessità di un entità che prenda delle decisioni: Gestore del nodo: ogni nodo dispone di tale gestore il cui unico compito è di creare altri vserver sul nodo che gestisce e di controllare l allocazione delle risorse. Service provider: ha il compito di contattare una slice authority a cui chiederà di creare una slice su un insieme di nodi. Il SP sarà riconosciuto dalla Slice Authority. Slice authority: ha il diritto di chiedere la creazione di una slice. Avrà permessi di accesso a un insieme di nodi. Management authority: mentre una SA si occupa solo della gestione di una slice, un MA deve controllare i nodi ed in particolare deve assicurare che i nodi sotto il suo regime eseguano il software di base e si attengano alle regole imposte da PlanetLab. Le relazioni sono quelle indicate di seguito: 1. Il proprietario di un nodo mette il proprio nodo sotto il regime di un MA per la gestione, forse limitandone l uso in modo appropriato. 2. La MA fornisce il software necessario per aggiungere un nodo a PlanetLab. 3. Un service provider si registra a una authority per la gestione, fidandosi che essa fornisca nodi che si comportino correttamente. 4. Un SP contatta una SA per creare una slice su un insieme di nodi. 5. La slice authority deve autenticare il service provider. 6. Il proprietario del nodo a questo punto mette a disposizione un servizio per la creazione di una slice affinché una SA possa crearle; esso essenzialmente delega la gestione delle risorse alla SA. Può far creare da quella slice authority una o più slice. 7. La MA delega ufficialmente la creazione delle slice a una SA. 22

23 SEI: CAPITOLO 3 -> PROCESSI COSTANTE LUCA GIARDINO DANIELE PALO UMBERTO MIGRAZIONE DEL CODICE Un ultima problematica è quella della migrazione del codice. Nel momento in cui ho più macchine, voglio avere la possibilità di poter migrare il codice, sia da server verso client che viceversa. Ci sono situazioni particolari in cui addirittura prima che un client chieda un servizio, può avere la necessità di una porzione di codice per la configurazione. Quindi accede al repository, scarica il codice e solo successivamente inizia la comunicazione con il server. Il vantaggio importante di questo modello di scaricare dinamicamente il software lato client è che, per comunicare con i server, non è necessario che i client abbiano tutto il software preinstallato. Un altro vantaggio è che, finché le interfacce sono standardizzate, possiamo cambiare il protocollo client/server e la sua implementazione quando vogliamo. Una problematica che può sorgere riguarda la sicurezza. Modelli per la migrazione del codice Vi sono dei modelli tipici partendo dal concetto di migrazione. Migrazione del codice nel suo senso più ampio si riferisce allo spostamento di programmi tra macchine, con l intenzione di eseguirli sulla macchina destinataria (target). La prima differenza si fa tra mobilità debole e forte. Attraverso la mobilità leggera (o debole) si può migrare solo il codice, mentre con la mobilità forte si può migrare anche il segmento dell esecuzione effettuando una migrazione anche dei dati in uso. In quest ultimo caso, quando un processo viene bloccato per effettuare la migrazione, l esecuzione riprende dal punto in cui era stata interrotta. Le problematiche che intervengono sono leggermente diverse. In quella iniziata dal mittente (sender), la migrazione inizia sulla macchina dove il codice attualmente risiede o è in esecuzione. Nel caso della mobilità leggera, fa anche differenza se il codice migrato è eseguito dal processo target o se viene avviato da un processo separato. Il vantaggio di questo approccio è che non è necessario avviare un processo separato, evitando quindi la comunicazione alla macchina target. L inconveniente principale è che il processo target deve essere protetto da esecuzioni di codice dolose o involontarie. Nella migrazione avviata dal destinatario, l iniziativa per la migrazione del codice è presa dalla macchina target. 23

24 SEI: CAPITOLO 3 -> PROCESSI COSTANTE LUCA GIARDINO DANIELE PALO UMBERTO Nella mobilità forte si può avere o la migrazione o la clonazione del processo. La clonazione produce una copia esatta del processo originale che in quel momento è in esecuzione su un altra macchina. Migrazione e risorse locali Le risorse, la 3 componente, sono un po più complicate da gestire. Queste possono essere più o meno collegate alla macchina. La tabella tiene conto di una sorta di collegamenti tra processi e risorse identificate per ID (come ad esempio una URL per riferirsi a uno specifico sito WEB), valore (quando si fa affidamento a librerie standard. Tali librerie dovrebbero essere sempre localmente disponibili, ma la loro posizione esatta nel file system locale può cambiare da sito a sito) o tipo (è esemplificato dai riferimenti a dispositivi locali, come monitor, stampanti e così via). Una problematica riguarda come queste risorse possono essere collegate alla macchina. I vari tipi di collegamento sono: non è collegabile (unattached); a seconda delle dimensioni (fastened); fissate (fixed). Nel caso in cui si ha un collegamento per tipo, es un collegamento hardware, devo per forza effettuare una rebind. Le risorse unattached possono essere facilmente spostate (MV o GR) tra macchine diverse e di solito sono file (di dati) associati solo al programma che deve essere migrato. Diversamente, può essere possibile spostare o copiare una risorsa fastened, ma solo ad un costo relativamente alto. Infine le risorse fisse sono intimamente collegate a una macchina o a un ambiente specifici e non possono essere spostate. Quando la risorsa è unattached, di solito è bene spostarla con il codice da migrare. Migrazione nei sistemi eterogenei La migrazione di sistemi eterogenei è intrinsecamente complicata. Il concetto di macchina virtuale, diventa essenziale in questi casi per effettuare una migrazione. In questo caso normalmente si possono avere migrazioni in base a situazioni diverse: spingere le pagine di memoria sulla nuova macchina e inviare nuovamente quelle modificate durante il processo di migrazione; stoppare la macchina virtuale, effettuare la migrazione totale e riavviare la VM; in parallelo faccio nascere la macchina virtuale e man mano che ci sono delle modifiche, le pagine che effettivamente vengono utilizzate devono essere caricate. 24

25 SEI: CAPITOLO 4 -> COMUNICAZIONE CAPITOLO 4: COMUNICAZIONE La comunicazione tra processi è un fattore essenziale di un sistema distribuito. Essenzialmente le 3 tipologie per la comunicazione sono: 1. RPC 2. MOM 3. Stream L approccio relativo alla comunicazione si basa sui protocolli (regole) tra Ricevente e Trasmittente. In particolare un messaggio è costituito come segue: Bisogna capire che ogni livello aggiunge informazioni fino a quando il messaggio non viene trasferito. I 2 protocolli tipici sono TCP e IP. Quello che succede nella realtà è che spesso sono fusi insieme a livello middleware per far si che alcuni controlli tipici non facciano parte del livello applicativo, quali problematiche legate al commit di più processi, ecc. Il middleware è un applicazione che risiede logicamente a livello applicativo, che contiene molti protocolli specifici che giustificano l esistenza di un livello proprio indipendentemente da altre applicazioni più specifiche. I protocolli per supportare una grande varietà di servizi middleware sono numerosi: ci sono per esempio molti modi per stabilire l autenticazione. I protocolli di autenticazione non sono strettamente legati ad un applicazione specifica ma possono essere integrati in un sistema middleware come servizio generale. Hanno tendenzialmente una natura generale ed indipendente dall applicazione anche i protocolli 25

26 SEI: CAPITOLO 4 -> COMUNICAZIONE di Commit i quali stabiliscono che in un gruppo di processi una certa operazione sia portata a termine da tutti oppure non sia affatto portata a termine. Questo fenomeno è anche chiamato atomicità ed è ampiamente applicata nelle transazioni. Tipi di comunicazione Quando vi è una comunicazione C/S, può esservi da un lato comunicazione sincrona/asincrona oppure persistente/transiente. Con la comunicazione persistente un messaggio immesso, per essere trasmesso, viene memorizzato dal middleware per la comunicazione per tutto il tempo che gli serve a consegnarlo al destinatario. Con la comunicazione transiente un messaggio viene memorizzato dal sistema di comunicazione solo finché le applicazioni mittente e destinatario sono in esecuzione. La caratteristica della comunicazione asincrona è che un mittente continua l elaborazione subito dopo aver sottomesso il suo messaggio. Questo significa che il messaggio viene temporaneamente memorizzato dal middleware immediatamente dopo la sottomissione. Con la comunicazione sincrona il mittente è bloccato finché la sua richiesta non viene accettata. Ci sono essenzialmente 3 punti in cui la sincronizzazione può aver luogo: 1. Il mittente può essere bloccato finché il middleware non comunica che prenderà il controllo della trasmissione della richiesta 2. Il mittente si può sincronizzare quando la sua richiesta è stata consegnata al destinatario indicato. 3. La sincronizzazione può avvenire lasciando che il mittente attenda finché la sua richiesta non sia stata completamente elaborata cioè fino al momento in cui il destinatario non restituisca una risposta. In pratica si verificano varie combinazioni di persistenza e sincronizzazione. Le più note sono: la persistenza in combinazione con la sincronizzazione alla sottomissione della richiesta, uno schema comune per molti sistemi a code per lo scambio di messaggi. È molto usata anche la comunicazione transiente con la sincronizzazione dopo che la richiesta è stata completamente elaborata. Questo schema corrisponde alle chiamate a procedure remote RPC: RPC L idea di base è quella di implementare la trasparenza riguardo l esecuzione di alcune procedure che non vengono eseguite su quella macchina fisica. Si deve fare in modo che le istruzioni appaiano come se fossero eseguite in locale anziché in remoto. Quando un processo sulla macchina A richiama una procedura sulla macchina B, il processo chiamante su A viene sospeso ed ha luogo su B l esecuzione della procedura chiamata. Le informazioni possono essere 26

27 SEI: CAPITOLO 4 -> COMUNICAZIONE trasportate dal chiamante al chiamato attraverso i parametri e possono tornare indietro attraverso il risultato della procedura. L idea alla base delle RPC è di rendere una chiamata a procedure remota il più simile possibile ad una chiamata locale. Vogliamo che le RPC siano trasparenti ovvero la procedura chiamante non deve essere conscia che la procedura chiamata è in esecuzione su una macchina diversa o viceversa. In una chiamata RPC dovranno essere specificati i parametri, un indirizzo di ritorno e alcune altre variabili utili per l esecuzione. Già a livello locale possiamo vedere la trasparenza tra una chiamata a una funzione e una funzione che all interno ha una system call. In una chiamata verso un server, un client effettua l invocazione di una procedura remota ed attenda che gli verranno restituiti dei risultati. Uno stub è un pezzo di codice che prende in input la chiamata a funzione, impacchetta le informazioni, le invia alla rete. Vi è poi un server stub che spacchetta le informazioni e le elabora. Il client effettua una chiamata al client stub Il client stub effettua una costruzione del messaggio e richiama il SO locale Il SO del client invia il messaggio al SO remoto Il SO remoto passa il messaggio al server stub Il server stub spacchetta i parametri e richiama il server Il server effettua l operazione e ritorna i valori ottenuti allo stub Il server stub li impacchetta in un messaggio e richiama il suo SO Il SO del server invia il messaggio al SO del client Il SO del client riceve il messaggio e lo passa al client stub Lo stub spacchetta il risultato e lo restituisce al client 27

28 SEI: CAPITOLO 4 -> COMUNICAZIONE Per passare i parametri ad una funzione vi sono 2 modalità: passaggio per valore e passaggio per riferimento. È proprio in quest ultimo caso che vi sono più problemi. Un passaggio per riferimento prevede il passaggio del riferimento alla zona di memoria locale dove è posizionato il dato. Bisogna quasi rendere un passaggio per riferimento come un passaggio per valore grazie al meccanismo di copia/ripristino. Passaggio per valore L operazione di impacchettare i parametri in un messaggio è detto marshaling dei parametri. Finché le macchine client e server sono identiche e tutti i parametri e i risultati sono di tipo scalare non ci sono problemi. Tuttavia in un grande sistema distribuito spesso avviene che ci siano molti tipi di macchine. Ogni macchina ha spesso la sua rappresentazione di numeri, caratteri ed altri dati. Per esempio i mainframe IBM usano la codifica EBCDic per i caratteri mentre i PC IBM usano l ASCII. Di conseguenza, non è possibile passare un parametro di tipo carattere da un client PC IBM ad un server mainframe IBM usando il semplice schema della figura sopra. Il server interpreterebbe il carattere in maniera scorretta. Problemi simili possono verificarsi con la rappresentazione degli interi e dei numeri a virgola mobile. Un altro problema si deve al fatto che alcune macchine come il Pentium Intel numerano i loro byte da destra a sinistra (little endian) mentre altre come la SPARC della SUN li numerano al contrario (big endian). Per risolvere il problema un approccio ovvio ma scorretto è semplicemente di invertire i byte in ogni parola dopo che sono stati ricevuti. Il problema è che gli interi sono invertiti dal diverso ordinamento dei byte ma non le stringhe. Quindi senza informazioni aggiuntive su che cosa sia una stringa e che cosa sia un interno non c è modo di riparare il danno. Passaggio per riferimento Domanda: come vengono passati i puntatori o i riferimenti in generale?? Una strategia evidente è quella di copiare le strutture linkate ed inviarle al server. Quindi il passaggio di parametri per riferimento è sostituito dal meccanismo di copia/ripristino. Nascondere una chiamata di procedura remota richiede che il chiamante e il chiamato concordino il formato dei messaggi che si scambiano e che seguano gli stessi passi quando si tratta di passare strutture dati complesse. Definire il 28

29 SEI: CAPITOLO 4 -> COMUNICAZIONE formato di messaggi è uno degli aspetti di un protocollo RPC ma è anche necessario che il client ed il server concordino la rappresentazione di semplici strutture dati come gli interi, caratteri, booleani, ecc. RPC Asincrona Il problema di fondo dell RPC è che sono intrinsecamente sincrone. In una comunicazione asincrona, i componenti che vi partecipano possono anche non essere contemporaneamente on-line. Le RPC asincrone nascono proprio per dare la possibilità ai client di fare qualche altra cosa mentre il server elabora la risposta in situazioni in cui spesso non è necessario attenderla. Per supportare tali situazioni, i sistemi RPC possono fornire alcune funzionalità per le cosiddette RPC asincrone. Con le RPC asincrone, il server invia al client una risposta non appena riceve la richiesta di RPC, dopodiché chiama la procedura richiesta. La notifica serve al client per sapere che il server sta per processare la RPC. Non appena riceve questa conferma (acknowledgment) da parte del server, il client continuerà senza ulteriori blocchi. Le RPC asincrone, possono essere utili quando viene restituita una risposta ma il client non è preparato ad attenderla rimanendo attivo. In questi casi, ha senso organizzare la comunicazione attraverso 2 RPC asincrone. La 2 chiamata è fatta dal server che richiama il client. La combinazione di 2 RPC asincrone è chiamata RPC SINCRONA DIFFERITA. Esiste anche una variante delle RPC asincrone in cui il client non attende la notifica dell accettazione della richiesta da parte del server. Queste RPC vengono chiamate RPC A SENSO UNICO. Il problema di tale approccio è che quando l affidabilità non è garantita, il client non può essere certo che la sua richiesta venga elaborata. 29

30 SEI: CAPITOLO 4 -> COMUNICAZIONE DCE RPC Il DCE (Distributed Computing Environment) è uno specifico sistema RPC che fu sviluppato dalla Open Software Foundation OSF. Questo sistema è un vero e proprio middleware che si pone tra il SO da un lato e l applicazione dall altro in quanto progettato per essere eseguito come un livello di astrazione tra i SO (in rete) esistenti e le applicazioni distribuite. I servizi che fanno parte di DCE sono: 1. File services distribuiti: file system globale che offre un modo trasparente di accedere nello stesso modo a qualunque file nell intero sistema. 2. Directory service: impiegato per tenere traccia della posizione di tutte le risorse nel sistema 3. Security service: offre protezione per ogni tipo di risorsa del sistema. 4. Time service distribuito: servizio che cerca di mantenere sincronizzati i clock su diverse macchine. In un sistema Client/Server, il collante è la definizione dell interfaccia specificata in IDL. Quest ultimo consente la dichiarazione delle procedure in una forma molto vicina ai prototipi di funzioni dell ANSI C. I file IDL possono anche contenere definizioni di tipi, dichiarazioni di costanti e altre informazioni necessarie per fare correttamente il marshal dei parametri e l unmarshal dei risultati. Il primo passo nello scrivere un applicazione C/S consiste nel chiamare i programmi UUIDGEN richiedendo loro di generare un prototipo di file IDL contenente un identificatore di interfaccia. Va garantito che non verrà più usato in alcuna interfaccia ovunque generata con UUIDGEN. L univocità è assicurata codificando nell identificatore la posizione, data e ora di creazione. Il passo successivo è la scrittura del file IDL compilando i nomi delle procedure remote e i loro parametri. Quando il file IDL è completo, viene richiamato il compilatore IDL per processarlo. Il suo output consiste di 3 file cliente stub il server stub l header. Si arriva ad avere interfacce ben definite. Per consentire ad un client di richiamare un server, è necessario che il server sia registrato e pronto ad accettare chiamate in arrivo. C è bisogno di localizzare l host e il servizio sull host. Per gestire questa attività viene utilizzato un modello in cui a livello di un singolo server vi è un DCE daemon che tiene traccia dei servizi/porta offerti di un server. 30

31 SEI: CAPITOLO 4 -> COMUNICAZIONE Il server registra il servizio in una macchina directory dove il client si collega e contatta la directory machine per ricercare il server. Localizzato il server, contatta il DCE daemon per collegarsi al servizio desiderato. Ottenute le informazioni, effettua una chiamata RPC al Server. COMUNICAZIONE ORIENTATA AI MESSAGGI La comunicazione orientata ai messaggi non è sempre un task di comunicazione asincrona, ma vi sono 2 eccezioni in generale: una che si basa sui socket (attraverso i socket Berkeley) e l altra su code di messaggi. I socket Berkeley sono costituiti dalle seguenti primitive: Il server esegue le prime 4 primitive, di solito nell ordine stabilito dalla tabella. Quando richiama la primitiva socket, il chiamante crea una nuova porta di comunicazione per un protocollo di trasporto specifico. La primitiva bind associa un indirizzo locale con la socket appena creata. Listen viene richiamata solo nel caso di comunicazione orientata alla connessione: è una chiamata non bloccante che consente al SO locale di riservare un buffer per le connessioni che è disposta ad accettare. Una chiamata alla accept blocca il chiamante finché non arriva una richiesta di connessione. Anche dal lato client, deve essere innanzitutto creata una socket. La primitiva connect richiede che il chiamante specifichi l indirizzo a livello del trasporto a cui va inviata la richiesta di connessione. Il client è bloccato finché una connessione non viene stabilità con successo; dopodiché entrambi i lati possono iniziare a scambiarsi informazioni attraverso le primitive send e receive. Infine attraverso la primitiva close si provvede alla chiusura della connessione (l unica chiamata sincrona). Le prime 5 operazioni, vengono generalmente utilizzate per la creazione e all instaurazione di una connessione. Fatto ciò, si effettuano le varie operazioni che come sappiamo sono le ultime 3 della tabella. La necessità di essere indipendenti dall hardware e dalla piattaforma ha portato alla definizione di uno standard per lo scambio di messaggi chiamato INTERFACCIA PER LO SCAMBIO DI MESSAGGI o MPI (Message Passing Interface). L evoluzione è stata quella dovuta al fatto che la sincronia non è sempre utilizzabile a causa di vari fattori. In questo caso vi è una modalità di comunicazione dove non vi è più la 31

32 SEI: CAPITOLO 4 -> COMUNICAZIONE necessità di sincronia ma vi è la possibilità di depositare da qualche parte le informazioni a cui successivamente l altra parte potrà accedervi. Il cuore di MPI è costituito da primitive per lo scambio di messaggi per supportare la comunicazione transiente. La comunicazione transiente asincrona è supportata attraverso la primitiva MPI_bsend: il mittente invia un messaggio che generalmente viene anzitutto copiato in un buffer locale al sistema runtime di MPI. Tale sistema cancellerà il messaggio dal suo buffer e si prenderà cura della trasmissione non appena un destinatario richiamerà la receive. Esiste anche un operazione di invio bloccante chiamata MPI_send. La comunicazione sincrona per cui il mittente si blocca finché la sua richiesta non è accettata, è disponibile attraverso la primitiva MPI_ssend. Viene anche supportata la forma più forte di comunicazione sincrona con la primitiva MPI_sendrecv mediante la quale il mittente invia una richiesta al destinatario e si blocca finché quest ultimo non restituisce una risposta. Fondamentalmente questa primitiva corrisponde ad una normale RPC. Con la MPI_isend il mittente invia un puntatore al messaggio, dopodiché il sistema runtime MPI si occupa della comunicazione. Come con MPI_isend non viene specificato se il messaggio è stato realmente trasferito al destinatario o se è stato solamente copiato in un buffer interno. Analogamente con la MPI_issend il mittente invia solo un puntatore al sistema runtime di MPI ma ha la garanzia che il destinatario abbia accettato il messaggio e ci stia lavorando. La MPI_recv viene chiamata per ricevere il messaggio; essa blocca il chiamante finché non arriva il messaggio. Esiste anche una variante asincrona, MPI_irecv. Message Queuing Model I sistemi a code di messaggi, o semplicemente middleware orientato ai messaggi, forniscono un ampio supporto alla comunicazione asincrona persistente, in quanto offrono la possibilità di memorizzare i messaggi a medio termine, senza che il mittente e il destinatario siano attivi durante la trasmissione del messaggio. L'idea alla base di un sistema a code per lo scambio dei messaggi è che le applicazioni comunicano inserendo i messaggi in code specifiche. È un modello generale che permette di racchiudere casistiche diverse. Nella figura (a) sia il mittente che il destinatario sono in esecuzione durante l'intera trasmissione del messaggio. Nella (b) solo il mittente è in esecuzione, mentre il destinatario è passivo, ovvero in uno stato in 32

33 SEI: CAPITOLO 4 -> COMUNICAZIONE cui la consegna del messaggio non è consentita. Ad ogni modo, il mittente può mandare il messaggio. La comunicazione tra un mittente passivo e un destinatario in esecuzione è mostrata nella (c); in questo caso il destinatario può leggere i messaggi che gli sono stati inviati, ma non è necessario che i rispettivi mittenti siano in esecuzione. Infine nella (d) possiamo vedere la situazione in cui il sistema memorizza (ed eventualmente trasmette) i messaggi anche se il destinatario e il mittente sono passivi. Le primitive utilizzate sono implementate con un livello di astrazione molto alto: La Put viene richiamata da un mittente per passare al sistema sottostante un messaggio da aggiungere in una specifica coda, chiamata non bloccante. La get è una chiamata bloccante attraverso la quale un processo autorizzato può rimuovere dalla coda specificata il messaggio pendente da più tempo. Il processo si blocca solo se la coda è vuota. Variazioni di questa chiamata consentono di cercare nella coda uno specifico messaggio, usando per esempio la priorità o un pattern di corrispondenza. La variante non bloccante è fornita dalla primitiva poll; se la coda è vuota o se uno specifico messaggio non può essere trovato, il processo chiamante semplicemente va avanti. Molti sistemi di code consentono anche a un processo di installare un handler sotto forma di funzione di callback, che viene automaticamente chiamato quando un messaggio è inserito dentro una specifica coda. Una delle restrizioni è che i messaggi possono essere inseriti solo in code locali al mittente, ovvero code sulla stessa macchina o nel peggiore dei casi su una macchina vicina, come il caso di una sulla stessa LAN efficientemente raggiungibile con una RPC. Una coda di questo tipo è chiamata coda sorgente. Analogamente i messaggi possono essere letti solo da code locali. Le code sono gestite dai gestori delle code, che di solito interagiscono direttamente con l'applicazione che sta inviando o ricevendo un messaggio. Esistono anche gestori speciali che agiscono da router o relay: essi inoltrano i messaggi in ingresso ad altri gestori, in questo modo un sistema a code per lo scambio di messaggi può gradualmente crescere fino a diventare una rete overlay. In sistemi di grandi dimensioni questo approccio può causare rapidamente problemi di gestione della rete. Una soluzione possibile è di utilizzare alcuni router che conoscano la topologia della rete. Quando un mittente A inserisce nella sua coda locale un messaggio per il destinatario B, questo messaggio è innanzitutto trasferito al router più vicino, R1. A questo punto il router sa che cosa fare del messaggio e lo inoltra in direzione di B. In questo modo è necessario aggiornare soltanto i router quando vengono aggiunte o rimosse delle code, mentre tutti gli altri gestori devono solo sapere dove si trova il router più vicino. Una terza alternativa utilizza i broker di messaggi. Un'applicazione importante dei sistemi a code di messaggi è l'integrazione di applicazioni nuove ed esistenti in un unico sistema distribuito coerente. L'integrazione richiede che le applicazioni possano interpretare i messaggi che ricevono. In pratica ciò comporta che i messaggi in uscita dal mittente siano nello stesso formato di quelli del destinatario. 33

34 SEI: CAPITOLO 4 -> COMUNICAZIONE Sebbene siano stati definiti alcuni formati di messaggi comuni per specifici domini applicativi, l'approccio generale è di imparare a convivere con i diversi formati e provare a rendere la conversione il più semplice possibile. In un sistema a code di messaggi la conversione è gestita da nodi speciali della rete chiamati broker di messaggi. Questi nodi agiscono da gateway a livello applicativo ed hanno l'obiettivo di convertire i messaggi in ingresso in modo tale che siano comprensibili dall'applicazione destinataria. IBM WebSphere MQ In WebSphere, tutte le code sono gestite da gestori delle code. Un gestore deve rimuovere i messaggi dalle sue code d invio e inoltrarli ad altri gestori. I gestori delle code sono connessi a coppie attraverso dei canali di messaggi (message-channel), un'astrazione delle connessioni a livello di trasporto. Un canale di messaggi è una connessione unidirezionale e affidabile tra un gestore di una coda d'invio e uno di una coda di ricezione, attraverso la quale vengono trasportati i messaggi in coda. Ciascuno dei due lati del canale è gestito da un agente del canale di messaggi (MCA). Un MCA di invio non fa altro che controllare le code d'invio per vedere se c'è un messaggio, confezionarlo in un pacchetto a livello di trasporto e inviarlo attraverso la connessione all'mca di ricezione associato. Analogamente il compito di un MCA di ricezione è stare in ascolto per vedere se arriva un pacchetto, liberarlo dall'involucro e successivamente memorizzare il messaggio contenuto nella coda appropriata. WebSphere fondamentalmente rispetta il modello in base al quale un'applicazione può accedere solo a code locali. La modalità è del tutto asincrona. Una componente importante è costituita dai canali di messaggi. Ogni canale ha associato esattamente una coda d'invio dalla quale preleva i messaggi che deve trasferire dall'altra parte. Ogni MCA ha un insieme di attributi associati che determinano il comportamento generale del canale. Si distinguono attributi non negoziabili e negoziabili. I primi, una volta specificati, devono valere per tutti (ad esempio se un MCA vuole che la consegna dei messaggi avvenga secondo la politica FIFO, l'altro deve 34

35 SEI: CAPITOLO 4 -> COMUNICAZIONE adattarsi) mentre i secondi sono quegli attributi che possono essere anche discussi (lunghezza massima dei messaggi). Per trasferire un messaggio da un gestore a un altro (eventualmente remoto) è necessario che ogni messaggio porti con se il proprio indirizzo di destinazione. Gli itinerari sono esplicitamente salvati all'interno di un gestore in una tabella di routing. Un elemento di questa tabella è costituito dalla coppia (destqm, sendq), dove destqm è il nome del gestore delle destinazioni e sendq è il nome della coda d'invio locale in cui deve essere inserito il messaggio per quel gestore. Un elemento della tabella di routing in MQ è chiamato alias. È importante notare che ogni gestore ha un nome univoco a livello del sistema, effettivamente usato come identificatore per quel gestore. Il problema nell'uso di questi nomi è che la sostituzione di un gestore, o il cambiamento del suo nome, influenzeranno tutte le applicazioni che gli inviano messaggi. La situazione può essere migliorata utilizzando alias locali per il nome dei gestori. Un alias definito all'interno di un gestore M1 è un altro nome per il gestore M2, utilizzabile solo dalle applicazioni che si interfacciano con M1. L'uso degli alias consente l'utilizzo dello stesso nome logico per una coda anche se il suo gestore o la coda stessa cambiano. L'utilizzo delle tabelle di routing permette di vedere il sistema in modo disaccoppiato. A livello applicativo non è necessario sapere l allocazione di LA1 o LA2 ma ciò che bisogna sapere è il responsabile del QMA-B-C- D. Quest'approccio basato sulle tabelle di routing e sugli alias porta a un'interfaccia di programmazione fondamentalmente abbastanza semplice, chiamata interfaccia per le code di messaggi (MQI). Per inserire i messaggi in una coda, un'applicazione richiama la primitiva MQopen specificando una coda di destinazione all'interno di uno specifico gestore. Quando un'applicazione ha finito di usare la coda, deve chiuderla richiamando la MQclose. I messaggi possono essere scritti su o letti da una coda usando MQput e MQget. COMUNICAZIONE ORIENTATA AGLI STREAM Nei tipi di comunicazione visti finora sono scambiate unità d'informazione più o meno indipendenti e complete. La loro caratteristica principale è che non ha importanza in quale particolare istante avviene la comunicazione. Sebbene un sistema possa essere troppo lento o troppo veloce, questo non ha nessun effetto sulla correttezza. Esistono anche forme di comunicazione in cui il tempo ha un ruolo fondamentale. Consideriamo ad esempio uno stream audio costituito da una sequenza di campioni da 16 bit, ciascuno rappresentante l'ampiezza dell'onda sonora. Supponiamo che tale stream abbia la qualità di un CD, ovvero 35

36 SEI: CAPITOLO 4 -> COMUNICAZIONE con frequenza di campionamento di 44100Hz. Per riprodurre il suono originale è essenziale che i campioni nello stream audio siano eseguiti nell'ordine in cui appaiono nello stream, ma anche a intervalli di esattamente 1/44100 secondi. Eseguirli a velocità diversa produrrebbe una versione scorretta del suono originale. Dal punto di vista dei sistemi distribuiti, ci sono diversi elementi necessari per supportare gli stream. Esistono due tipi di stream: live e di dati memorizzati. Nel primo caso i dati sono raccolti in tempo reale e inviati ai destinatari attraverso la rete, offre meno possibilità di messa a punto rispetto allo stream non live. Un'architettura client-server per il supporto di stream multimediali continui è mostrata nella figura seguente: I dati memorizzati, soprattutto video ed in misura minore audio, devono essere compressi significativamente, al fine di ridurre lo spazio di memoria richiesto e specialmente la capacità della rete. Dal punto di vista della comunicazione è più importante controllare la qualità della trasmissione e le questioni relative alla sincronizzazione. Qualità del servizio I requisiti di tempo, ed altri requisiti non funzionali, sono in genere espressi come requisiti della qualità del servizio (QoS). Dal punto di vista applicativo, questo si traduce in poche importanti proprietà: 1. il bit rate a cui devono essere trasportati i dati; 2. il tempo massimo di set up di una sessione (cioè quanto un'applicazione può iniziare a inviare dati); 3. il tempo di trasporto massimo (cioè quanto tempo ci mette un'unità di dati per arrivare a un destinatario); 4. la varianza massima del tempo di trasmissione o jitter; 5. il tempo massimo di risposta. Per garantire la QoS un metodo particolarmente utile è di usare i buffer per ridurre lo jitter. Supposto che il tempo di trasmissione dei pacchetti sulla rete abbia una certa varianza, il destinatario semplicemente memorizzerà i pacchetti in un buffer per un certo tempo massimo. Ciò consentirà al destinatario di passare i pacchetti all'applicazione con una velocità costante, sapendo che ci saranno sempre abbastanza pacchetti in ingresso nel buffer per mantenere questa velocità. Ovviamente può succedere che le cose non vadano per il meglio. Ad esempio può accadere che un pacchetto tardi ad arrivare fino a far svuotare il buffer di ricezione e causare un vuoto nel flusso dell'applicazione. L'unica soluzione è aumentare la dimensione del buffer, ma ciò comporta l'aumento del ritardo con cui 36

37 SEI: CAPITOLO 4 -> COMUNICAZIONE l'applicazione può iniziare ad utilizzare i dati contenuti nei pacchetti. Possono essere usate anche altre tecniche, come quelle di correzione degli errori. Un problema che può presentarsi è che un singolo pacchetto contenga molti frame audio e video. Di conseguenza, quando un pacchetto viene perso, il destinatario può realmente percepire un ampio vuoto nella riproduzione dei frame. Tale effetto può essere mitigato con l'uso dei frame interleaving, ovvero i frame vengono suddivisi tra più pacchetti e non inviati consecutivamente nello stesso pacchetto. In questo modo, quando viene perso un pacchetto, il vuoto risultante nei frame successivi viene distribuito nel tempo. Si noti, tuttavia, che quest'approccio richiede un buffer più largo rispetto alla trasmissione noninterleaved e quindi impone un ritardo maggiore nell'inizio dell'applicazione destinataria. Sincronizzazione degli stream Un elemento importante dei sistemi multimediali è che diversi stream, eventualmente sotto forma di uno stream complesso, sono sincronizzati l'uno con l'altro. La sincronizzazione degli stream è relativa al mantenimento delle relazioni temporali tra stream. Un tipo di sincronizzazione impegnativa è quello tra stream di dati continui, come ad esempio la rappresentazione di un film in cui lo stream video deve essere sincronizzato con l'audio, comunemente conosciuta come lip synchronization. Un altro esempio consiste nel riprodurre uno stream audio stereo costituito da due substream, uno per ogni canale. Una riproduzione corretta richiede che i due substream siano strettamente sincronizzati: una differenza di più di 20 microsecondi può distorcere l'effetto stereo. Nelle trasmissioni live è conveniente perdere pacchetti che richiederne la ritrasmissione, in quanto aspettare un pacchetto creerebbe un ritardo nella trasmissione. Per esempio nelle videoconferenze, un ritardo anche piccolo non è accettabile in quanto rovinerebbe l'interazione tra i partecipanti. Vengono quindi usati algoritmi di compressione efficienti, che prevedono di inviare solo le modifiche tra un frame e l'altro. La qualità è accettabile nel caso di immagini statiche, mentre decade con immagini in movimento. Inoltre viene privilegiata la trasmissione dell'audio. Queste tecniche consentono di avere videoconferenze di qualità anche su linee ISDN. Sul Web è tutto più difficile in quanto non c'è una banda minima garantita. La sincronizzazione ha luogo a livello delle unità di dati di cui è fatto uno stream. I meccanismi di sincronizzazione possono essere visti a molti livelli di astrazione. Al livello più basso, la sincronizzazione viene fatta operando esplicitamente sulle unità di dati degli stream semplici. Un processo che esegue semplicemente operazioni di lettura e scrittura su molti stream semplici, assicurando che queste operazioni rispettino degli specifici vincoli di tempo e di sincronizzazione. 37

38 SEI: CAPITOLO 4 -> COMUNICAZIONE L'inconveniente di un simile approccio è che l'applicazione è completamente responsabile dell'implementazione della sincronizzazione, anche se ha a disposizione solo funzionalità di basso livello. Un approccio migliore è di fornire all'applicazione un'interfaccia che le consenta di controllare più facilmente gli stream e i dispositivi: sistemi middleware multimediali. I middleware per i media offrono una serie di interfacce per il controllo degli stream audio e video, incluse quelle per controllare dispositivi come monitor, macchine fotografiche, microfoni e così via. Un altro aspetto da considerare è la distribuzione dei meccanismi di sincronizzazione. Il lato ricevente di uno stream complesso costituito da substream che devono essere sincronizzati, deve sapere esattamente come procedere, deve avere una specifica della sincronizzazione completa e disponibile localmente. Nella pratica comune queste informazioni vengono fornite implicitamente trasmettendo in multiplex i diversi stream in un unico stream contenente tutte le unità di dati, comprese quella per la sincronizzazione (MPEG). COMUNICAZIONE MULTICAST Per molti anni questo argomento è stato parte del dominio dei protocolli di rete, in cui sono state implementate e valutate numerose proposte di soluzioni a livello della rete o a livello di trasporto. La questione principale in tutte le soluzioni era di creare i communication path per la diffusione delle informazioni. Con l'avvento della tecnologia peer-to-peer e della gestione strutturata degli overlay è diventato più facile creare i communication path. Multicasting applicativo L'idea di base del multicasting applicativo è che i nodi sono organizzati in una rete overlay usata per diffondere le informazioni tra i propri membri; i router non sono membri dei gruppi. Per la costruzione della rete overlay esistono due approcci: i nodi si possono organizzare direttamente in un albero, il che significa che c'è un percorso tra ogni coppia di nodi; i nodi si organizzano in una rete a maglia in cui ogni nodo ha molti vicini, in generale esistono molti percorsi tra ogni coppia di nodi. Il secondo approccio è quello più robusto in quanto se cade un collegamento c'è ancora il modo di distribuire l'informazione senza riorganizzare l'overlay. 38

39 SEI: CAPITOLO 4 -> COMUNICAZIONE In questa figura il nodo A costituisce la radice di un albero multicast. Quando A invia in multicast un messaggio agli altri nodi, si vede che questo messaggio attraversa due volte ciascuno dei collegamenti <B,Rb>, <Ra, Rb>, <Rc, Rd> e <D, Rd>. La rete overlay sarebbe stata più efficiente se non avessimo costruito un collegamento da B a D e lo avessimo invece costruito da A a C. La qualità di un albero multicast applicativo è misurata in genere da tre diverse metriche: stress del collegamento, stretch e costo dell'albero. Lo stress del collegamento è definito per collegamento e conta quante volte un pacchetto attraversi lo stesso collegamento. Lo stretch o relative delay penalty (RDP) misura il rapporto tra il tempo di trasferimento tra due nodi nell'overlay e il tempo di trasferimento cui questi due nodi sarebbero soggetti nella rete sottostante. Gossip Una tecnica sempre più importante per la distribuzione delle informazioni consiste nell'affidarsi ai comportamenti epidemici. L'obiettivo principale di questi protocolli epidemici è la rapida propagazione delle informazioni in un grande insieme di nodi, usando solo informazioni locali. Non esiste un componente centrale che coordina le operazioni. Un modello di propagazione diffuso è quello dell'anti-entropia. In questo modello un nodo P prende a caso un altro nodo Q e successivamente scambia gli aggiornamenti con Q. Esistono tre approcci: 1. push: P manda soltanto i suoi aggiornamenti a Q (peggiore); 2. pull: P si prende soltanto i nuovi aggiornamenti da Q; 3. push-pull: P e Q si mandano reciprocamente gli aggiornamenti. Quando è necessario diffondere rapidamente gli aggiornamenti, solo l'approccio push non risulta essere una buona scelta. Gli aggiornamenti possono essere propagati solo dai nodi infetti. Tuttavia se molti nodi sono infetti, la probabilità che ciascuno di loro scelga un nodo suscettibile è relativamente bassa. Di conseguenza, c'è la possibilità che un particolare nodo rimanga suscettibile a lungo perché non viene scelto da un nodo infetto. L'approccio pull lavora meglio quando ci sono molti nodi infetti in quanto la diffusione degli aggiornamenti è scatenata dai nodi suscettibili. Se e soltanto se un nodo è infetto gli aggiornamenti si diffonderanno rapidamente su tutti i nodi usando entrambe le forme di anti-entropia, anche se la strategia push-pull rimane la migliore. Una specifica variante a quest'approccio è chiamata diffusione del rumore o gossip. Se un nodo P è appena stato aggiornato con il dato x, esso contatta un altro nodo arbitrario Q e prova a inviare l'aggiornamento a Q. Tuttavia è possibile che Q sia stato già aggiornato da un altro nodo. In questo caso P può perdere l'interesse a diffondere ulteriormente l'aggiornamento, diciamo con probabilità 1/k. Il gossiping è del tutto analogo alla vita reale; si rivela un ottimo metodo per la rapida diffusione delle notizie, tuttavia non può garantire che tutti i nodi vengano effettivamente raggiunti. 39

40 SEI: CAPITOLO 5 -> NAMING CAPITOLO 5: NAMING I nomi giocano un ruolo molto importante in tutti i sistemi di computer. Sono usati per condividere le risorse, identificare univocamente le entità, far riferimento alle loro posizioni e altro. Un elemento importante del naming è che un nome può essere risolto nell entità a cui si riferisce, permette quindi di poter associare un indirizzo ad un nome. Il naming in un sistema distribuito non cambia di molto da quello stand-alone e la differenza è sul modo in cui essi sono implementati. In un sistema distribuito talvolta anche il naming è di tipo distribuito su molte macchine. NOMI, IDENTIFICATORI E INDIRIZZI Un nome in un sistema distribuito è una sequenza di caratteri utilizzati per riferirsi a un entità. Un entità in un sistema distribuito può essere in pratica qualunque cosa. Per operare su un entità è necessario accedervi tramite un punto di accesso cioè un tipo speciale di entità in un sistema distribuito. Il nome di un punto di accesso è detto indirizzo. Un entità può avere più di un punto di accesso, può cambiare il suo punto d accesso nel corso del tempo. Spesso, un identificatore fa riferimento alla stessa entità. Oltre agli indirizzi, ci sono altri tipi di nomi che meritano un trattamento speciale, come quelli usati per identificare univocamente un entità. Un identificatore vero è un nome che ha le seguenti proprietà: 1. Un identificatore si riferisce al massimo a un entità; 2. Ogni entità è referenziata al massimo da un identificatore; 3. Un identificatore si riferisce sempre alla stessa entità (cioè non è mai riusato). Usando gli identificatori, diventa più facile riferirsi a un entità in maniera non ambigua. NAMING SEMPLICE La prima modalità è il naming semplice ossia una modalità in cui l assegnamento della risorsa non contiene informazione di alcun tipo su come localizzare il punto d accesso all entità associata. Broadcasting Consideriamo un sitema distribuito costruito su una rete di computer che offre funzionalità di broadcasting efficiente. Tipicamente, tali funzionalità sono offerte da reti locali, in cui tutte le macchine sono connesse a un singolo cavo o al suo equivalente logico. Localizzare un entità in tale ambiente è semplice: un messaggio contenente l identificatore dell entità viene trasmesso a ogni macchina e a ogni macchina viene richiesto di controllare se possiede quell entità. Solo le macchine che possono offrire un punto d accesso per l entità inviano un messaggio di risposta contenente l indirizzo di quel punto d accesso. Questo principio è usato nel protocollo di risoluzione degli indirizzi (ARP) per trovare l indirizzo a livello del collegamento dati di una macchina dato solo un indirizzo IP. In sostanza, una macchina trasmette un pacchetto sulla rete locale richiedendo chi sia il proprietario di un dato indirizzo IP. Quando il messaggio raggiunge una macchina, il destinatario controlla se ha l indirizzo IP richiesto. In caso affermativo, invia un pacchetto di risposta contenente, ad esempio, il suo indirizzo ethernet (MAC). Il broadcasting diventa inefficiente man mano che la rete cresce. Una soluzione possibile è di passare al multicasting, in cui solo un ristretto numero di host riceve la richiesta. Il multicasting può anche essere usato per localizzare entità nelle reti point-to-point. Un indirizzo multicasting può essere usato come servizio di localizzazione generale per molteplici entità. 40

41 SEI: CAPITOLO 5 -> NAMING Puntatori forwarding Un altro approccio diffuso per localizzare le entità mobili è l impiego di puntatori forwarding. Il principio è semplice: quando un entità si sposta da A a B, si lascia dietro un puntatore alla sua nuova posizione su B. Il vantaggio principale di questo approccio è la sua semplicità: non appena viene trovata un entità, ad esempio usando il naming service tradizionale, un client può cercare l indirizzo attuale seguendo la catena dei puntatori forwarding. Esiste però anche un certo numero di inconvenienti. Primo, se non vengono prese misure opportune, la catena di un entità molto mobile può diventare così lunga che localizzarla diventa troppo dispendioso. Secondo, ogni posizione intermediaria nella catena deve mantenere la sua parte di catena di puntatori forwarding finché necessario. Terzo il sistema è molto vulnerabile all interruzione dei collegamenti. Per capire meglio come funzionano i puntatori forwarding, consideriamo il loro impiego con gli oggetti remoti: oggetti cui si può accedere per mezzo di una chiamata a procedura remota. Un server stub contiene un riferimento locale all oggetto reale o un riferimento locale a un client stub remoto per quell oggetto. Quando un oggetto si sposta dallo spazio degli indirizzi di A a quello di B, lascia su A al suo posto un client stub e installa un server stub su B che si riferisce a esso. La migrazione avviene in modo del tutto trasparente al client. L unico elemento che il client vede di un oggetto è il client stub. Quando la chiamata raggiunge l oggetto nella sua posizione attuale, viene inviata una risposta al client stub dove ha avuto origine la chiamata (spesso senza risalire lungo la catena). Con la risposta viene anche inviata la posizione attuale e il client stub aggiorna il suo server stub associato a quello nella posizione corrente dell oggetto. Approcci Home-Based Un modo è quello di tenere traccia di un Home Agent (una sorta di dispositivo software che mantiene l indirizzo della risorsa e tiene traccia dei suoi spostamenti). In questo caso la comunicazione è abbastanza semplice. Un altro esempio in cui è utilizzato un approccio home-based è Mobile IP. Ogni host mobile usa un indirizzo IP fisso. Tutta la comunicazione verso questo indirizzo IP viene inizialmente diretta all home agent dell host mobile. L home agent è posizionato nella rete locale corrispondente all indirizzo di rete contenuto nell indirizzo IP dell host mobile. Nel caso di IPv6, esso è un componente del livello della rete. Quando l host mobile si sposta in un altra rete, richiede un indirizzo temporaneo da usare la comunicazione. Questo care of address è registrato dall home agent. Per comunicare con un entità mobile, un client anzitutto deve contattare l home, che può essere in una posizione completamente diversa da quella dell entità stessa. Il risultato è un aumento dei tempi di latenza della comunicazione. Un inconveniente dell approccio home based è l uso di home location fisse. Quando un entità durevole decide di spostarsi permanentemente in un altro punto della rete completamente diverso da dove si trova la sua home, sarebbe stato meglio se la home si fosse potuta spostare con l entità. Questo approccio è utilizzato quando gli spostamenti non sono frequenti e lunghi. 41

42 SEI: CAPITOLO 5 -> NAMING Hash table distribuite Un terzo approccio è quello delle Hash Table Distribuite. Bisogna tener traccia delle risorse e dei suoi spostamenti ed un approccio che può essere utilizzato è quello di Chord. La questione principale in un sistema basato su DHT è la risoluzione di una chiave k nell indirizzo succ(k). Un modo semplice di effettuare la ricerca è quella di tener traccia del successore e del predecessore e scorrerli tutti. In questo caso però la ricerca è molto onerosa, nell ordine O(n). Le hash table fanno si che la ricerca diventa nell ordine dei O(log(n)) soprattutto con l aggiunta del concetto di finger con la possibilità di puntare a diversi nodi. Tramite i finger, l individuazione dei successori potrebbe essere troppo avanti e quindi conviene prendere il primo più vicino al target. Questo comporta che la look up è dell ordine di O(log(n)). Altri problemi possono riguardare join e leave ma anche problemi legati ad interruzione di comunicazione quali guasti accidentali del nodo. Approccio gerarchico Dal punto di vista logico, non è altro che l organizzazione di tutti gli oggetti distribuiti in modo gerarchico dove abbiamo un nodo root, i vari sottoalberi ed infine le foglie. In uno schema gerarchico, una rete è suddivisa in un insieme di domini. Esiste un solo dominio, top-level, che comprende l intera rete. Ogni dominio può essere suddiviso in molti sottodomini più piccoli. Un dominio di livello più basso chiamato dominio foglia, corrisponde di solito a una rete locale LAN in una rete di computer o a una cella in una rete di telefonia mobile. 42

43 SEI: CAPITOLO 5 -> NAMING L idea è che all interno di quell entità vi è un indirizzo che punta alla root directory. Ogni nodo deve tener traccia di tutte le entità del proprio sotto-albero. Il nodo radice contiene le informazioni di tutto l albero e anche dell indirizzo del sottoalbero che contiene la risorsa ricercata. Un entità può avere molteplici indirizzi, ad esempio se è replicata. Se un entità ha un indirizzo nel dominio foglia D1 e uno nel dominio D2 rispettivamente, allora il nodo directory del dominio più piccolo contenente sia D1 sia D2, avrà due puntatori uno per ogni sottodominio contenente un indirizzo. Quello che si fa è risalire il sottoalbero fino a quando non si trova un nodo che abbia gli indirizzi di entrambe le risorse coinvolte. Come mostrato nella figura sotto (5.7), un client che desidera trovare un entità E, invia una richiesta di ricerca al nodo directory del dominio foglia D in cui risiede il client. Se nel nodo directory non c è un location record per quell entità, allora l entità non è attualmente posizionata in D. Di conseguenza, il nodo inoltra la richiesta al padre. Si noti che il nodo padre rappresenta un dominio più ampio rispetto al figlio. Se anche il padre non ha un location record per E, la richiesta di ricerca è inoltrata al livello superiore. Non appena una richiesta raggiunge un nodo directory M contenente un location record per l entità E, sappiamo che E si trova da qualche parte nel dominio dom(m) rappresentato dal nodo M. Nella figura sotto si vede che M ha un location record contenente un puntatore a uno dei suoi sottodomini. La richiesta di ricerca viene quindi inoltrata al nodo directory di quel sottodominio, che a sua volta la inoltra lungo l albero finché la richiesta alla fine non raggiunge una foglia. Il location record memorizzato nel nodo foglia conterrà l indirizzo di E in quel dominio foglia. Questo indirizzo può quindi essere restituito al client che ha inizialmente dato origine alla richiesta. L altro esempio è quello di ricercare una entità, il funzionamento è abbastanza semplice. La ricerca si effettua salendo man mano di livello e si controlla se si ha la conoscenza della risorsa nel sottoalbero. Un altro metodo è quello di mantenere le informazioni man mano che si cerca la risorsa (approccio Bottomup). Si crea un location record prima di passare la richiesta d inserimento al nodo padre. Il vantaggio di quest ultimo approccio è che un indirizzo diventa disponibile per le ricerche non appena possibile. Di conseguenza, se un nodo padre è temporaneamente non raggiungibile, l indirizzo può ancora essere ricercato all interno del dominio rappresentato dal nodo corrente. Un operazione di cancellazione è analoga a quella di inserimento. Quando un indirizzo dell entità nel dominio foglia D deve essere rimosso, viene richiesto al nodo directory dir(d) di rimuovere quell indirizzo 43

44 SEI: CAPITOLO 5 -> NAMING dal suo location record. Se questo location record si svuota, cioè non contiene altri indirizzi per E in D, il record può essere eliminato. Il processo continua fino a quando non si raggiunge la radice. NAMING STRUTTURATO I nomi semplici si adattano bene alle macchine, ma in genere non sono molto opportuni per gli uomini. Come alternativa, i sistemi di naming supportano in genere i nomi strutturati composti da nomi semplici leggibili dagli uomini. Non solo i nomi dei file seguono questo approccio, ma anche i nomi degli host di Internet. Spazio dei nomi I nomi sono solitamente organizzati nei cosiddetti spazi dei nomi (name space). Uno spazio dei nomi per i nomi strutturati può essere rappresentato come un grafo orientato, etichettato con due tipi di nodi. Un nodo foglia rappresenta una data entità e non ha archi in uscita; in genere contiene informazioni sull'entità che rappresenta. Un nodo directory ha vari archi in uscita, ciascuno etichettato con un nome; contiene una tabella (directory table) in cui un arco in uscita è rappresentato come una coppia (etichetta dell'arco, identificatore del nodo). Il nodo n0 ha solo archi in uscita e non in entrata; un nodo di questo tipo si chiama (nodo) radice del grafo dei nomi. Ogni percorso in un grafo dei nomi può essere chiamato con la sequenza di etichette corrispondenti agli archi nel percorso stesso. Tale sequenza è detta path name (nome del percorso). Se il primo nodo in un path name è la radice del grafo dei nomi, esso è detto path name assoluto, altrimenti è detto path name relativo. Questa descrizione di un grafo dei nomi è molto vicina a ciò che è implementato in molti file system. Il blocco di boot è un blocco speciale di dati e istruzioni che sono automaticamente caricati nella memoria principale quando si avvia il sistema. Il blocco di boot è usato per caricare il sistema operativo in memoria centrale. Il superblocco contiene informazioni sull'intero file system, come la sua dimensione, quali blocchi non sono ancora stati allocati, quali inode non sono ancora usati e così via. Gli inode sono identificati da un indice, a partire da 0 riservato per l'inode rappresentante la root directory. Ogni inode contiene informazioni relative alla reperibilità su disco dei dati del file a esso associato. Inoltre un inode contiene informazioni sul proprietario, sulla data e ora di creazione e di ultima modifica, sui permessi d'accesso e così via. Di conseguenza, dato l'indice di un inode, è possibile accedere al file associato. Le directory sono implementate come i file, compresa la root directory, che contiene una corrispondenza tra i nomi dei file e gli indici degli inode. Si vede così che l'indice di un inode corrisponde all'identificatore del nodo nel grafo dei nomi. 44

45 SEI: CAPITOLO 5 -> NAMING La risoluzione del nome può aver luogo solo se sappiamo come e da dove iniziare. Avere queste informazioni è in genere chiamato meccanismo di chiusura. Per esempio la risoluzione dei nomi del grafo dei nomi per un file system Unix fa uso del fatto che l'inode della root directory è il primo inode nel disco logico che rappresenta il file system. Il suo offset reale in byte è calcolato a partire dai valori in altri campi del superblocco, insieme a informazioni codificate nel sistema operativo stesso sull'organizzazione interna del superblocco. Linking e mounting Strettamente correlato alla risoluzione dei nomi è l'uso di alias. Un alias è un altro nome per la stessa entità. Ci sono fondamentalmente due modi per implementare gli alias. Il primo è quello di consentire semplicemente che molteplici path name assoluti si riferiscano allo stesso nodo in un grafo dei nomi. Questo approccio è illustrato nella figura seguente in cui due diversi path name si riferiscono al nodo n5. Nella terminologia Unix, entrambi i path name /keys e home/steen/keys sono chiamati hard link al nodo n5. Il secondo approccio è di rappresentare un'entità attraverso un nodo foglia N, ma il nodo, invece di memorizzare l'indirizzo o lo stato dell'entità, memorizza un path name assoluto. Questo principio corrisponde all'uso di link simbolici nel file system Unix. Consideriamo un file system montato (mounted). Per quanto attiene al nostro modello di naming, montare un file system significa lasciare che un nodo directory memorizzi l'identificatore di un nodo directory proveniente da un diverso spazio dei nomi, che chiamiamo spazio dei nomi esterno. Il nodo directory che memorizza l'identificatore del nodo è chiamato mount point. Di conseguenza il nodo directory nello spazio dei nomi esterno è chiamato mounting point. Il principio del mounting può essere allargato anche ad altri spazi dei nomi. In particolare è necessario un nodo directory che agisca da mount point e memorizzi tutte le informazioni necessarie per identificare e accedere al mounting point nello spazio dei nomi esterno. Questo approccio è seguito in molti file system distribuiti. Per montare uno spazio dei nomi esterno in un sistema distribuito sono necessarie come minimo le seguenti informazioni: 1. il nome di un protocollo d'accesso; 2. il nome del server; 3. il nome del mounting point nello spazio dei nomi esterno. Ciascuno di questi nomi deve essere risolto. Il nome di un protocollo d'accesso deve essere risolto nell'implementazione di un protocollo attraverso il quale può aver luogo la comunicazione con il server dello spazio dei nomi esterno. Il nome del server deve essere risolto in un indirizzo dove il server può essere raggiunto. Poi il nome del mounting point deve essere risolto in un identificatore di un nodo nello spazio dei nomi esterno. NFS è un file system distribuito che ha un protocollo che descrive esattamente come un client può accedere ad un file memorizzato su un file server NFS (remoto). In particolare per consentire ad NFS di lavorare su Internet, un client deve specificare esattamente a quale file vuole accedere per mezzo di un URL NFS, per esempio nfs://fits.cs.nl/home/steen. Questa URL indica un file server NFS fits.cs.nl cui un client può accedere per mezzo del protocollo NFS. 45

46 SEI: CAPITOLO 5 -> NAMING Il nome nfs è ben conosciuto, nel senso che esiste un accordo a livello mondiale su come interpretarlo. Dato che abbiamo a che fare con una URL, il nome nfs verrà risolto in un'implementazione del protocollo NFS. Il nome del server è risolto nel suo indirizzo usando il DNS. /home/steen è risolto dal server dello spazio dei nomi esterno. Nell esempio, il nodo /remote/vu è un mouting point a nfs:.. Implementazione di uno spazio di nomi Gli spazi dei nomi per sistemi distribuiti di larga scala, eventualmente globali, sono di solito organizzati gerarchicamente. Il livello globale è costituito dai nodi di più alto livello, cioè il nodo radice e altri nodi directory logicamente vicini alla radice, vale a dire i suoi figli. I nodi nel livello globale sono spesso caratterizzati dalla loro stabilità, nel senso che le directory table cambiano raramente. Tali nodi possono rappresentare le aziende, o i gruppi di aziende, i cui nomi sono memorizzati nello spazio dei nomi. Il livello amministrativo è costituito dai nodi directory gestiti da una sola azienda. Una caratteristica dei nodi a questo livello è che rappresentano gruppi di entità che appartengono alla stessa azienda o unità amministrativa. Il livello gestionale è costituito dai nodi che cambiano regolarmente. Per esempio appartengono a questo livello i nodi che rappresentano gli host in una rete locale. Lo spazio dei nomi è suddiviso in parti non sovrapponibili, chiamate zone del DNS. Una zona è una parte dello spazio dei nomi che è implementata da un name server separato. Relativamente alla disponibilità e alle prestazioni, i name server in ogni livello devono soddisfare requisiti diversi. Per quelli nel livello globale è particolarmente critico l'essere altamente disponibili. Se un name server si guasta, un'ampia parte dello spazio dei nomi diventa irraggiungibile perché la risoluzione dei nomi non può andare oltre il server che si è guastato. 46

47 SEI: CAPITOLO 5 -> NAMING Le prestazioni sono un argomento delicato. A causa del fatto che i nodi nel livello globale cambiano poco, il risultato delle operazioni di ricerca rimane in genere valido a lungo. Di conseguenza, questi risultati possono effettivamente essere memorizzati localmente (cached) dai client. La disponibilità di un name server nel livello amministrativo è importante anzitutto per i client nella stessa azienda. Se si guasta, molte risorse all'interno dell'azienda diventano irraggiungibili, perche non possono essere ricercate. D'altronde il fatto che una risorsa in un'azienda diventi temporaneamente irraggiungibile è poco importante per gli utenti al di fuori dell'azienda. In merito alle prestazioni, i name server nel livello amministrativo hanno caratteristiche simili a quelli nel livello globale. I requisiti relativi alla disponibilità per i name server nel livello gestionale sono in genere meno impegnativi. In particolare, è spesso sufficiente usare una singola macchina dedicata per i name server, a rischio di una temporanea indisponibilità. Le prestazioni invece sono un elemento cruciale, infatti gli utenti si aspettano che le operazioni abbiano luogo immediatamente. Implementazione della risoluzione dei nomi Supponiamo di dover risolvere il path name assoluto: root:<nl, vu, cs, ftp, pub, globe, index.html>. Nella risoluzione dei nomi iterativa, un name resolver passa al root name server il nome completo. Si suppone che l'indirizzo presso cui contattare il root server sia ben conosciuto. Il root server risolverà il path name appena possibile e restituirà il risultato al client. Nel nostro esempio, il root server può risolvere solo l'etichetta nl, per la quale restituirà l'indirizzo del name server associato. A questo punto il client passa il resto del path name a quel name server che risolverà solo l'etichetta di livello inferiore, e così via. In alternativa alla risoluzione dei nomi iterativa è possibile usare la ricorsione durante tale processo. Invece di restituire ogni risultato intermedio al name resolver del client, con la risoluzione dei nomi ricorsiva un name server passa il risultato al name server successivo. Così, per esempio, quando il root name server trova l'indirizzo del name server che implementa il nodo chiamato nl, gli chiede di risolvere il nome <nl, vu, cs, ftp, pub, globe, index.html>. Usando anch'esso la risoluzione dei nomi ricorsiva, questo name server risolve il path completo e alla fine restituisce il file index.html al root server che, a sua volta, lo passerà al name resolver del client. Come nella risoluzione dei nomi iterativa, l'ultimo passo del processo in genere è eseguito dal client come un processo separato. L'inconveniente principale della risoluzione dei nomi ricorsiva è che richiede a ciascun name server un livello di prestazioni superiore. Fondamentalmente si richiede a un name server di gestire la completa risoluzione di un path name, sebbene possa farlo in collaborazione con altri name server. Questo carico ulteriore in genere è così pesante che i name server nel livello globale di uno spazio dei nomi supportano solo la risoluzione dei nomi iterativa. La risoluzione dei nomi ricorsiva consente a ogni name server di 47

48 SEI: CAPITOLO 5 -> NAMING imparare gradualmente gli indirizzi di ogni name server responsabile dell'implementazione dei nodi di livello più basso. Ne consegue che i meccanismi di caching possono effettivamente essere usati per migliorare le prestazioni. Il vantaggio di quest'approccio è che alla fine le operazioni di ricerca sono gestibili piuttosto efficientemente. Supponiamo per esempio, che successivamente un altro client richieda la risoluzione del parh name root:<nl, vu, cs, flits>. Questo nome viene passato alla radice che può immediatamente inoltrarlo al name server per il nodo cs e richiedergli di risolvere il path name rimanente cs:<flits>. Con la risoluzione dei nomi iterativa, i meccanismi di caching sono necessariamente limitati al name resolver del client. Di conseguenza, se un client A richiede la risoluzione di un nome e un'altro client B richiede più tardi la risoluzione dello stesso nome, questa deve passare attraverso lo stesso name server da cui era passato il client A. Come compromesso, molte aziende usano un name server locale intermedio condiviso da tutti i client, che memorizza nella sua cache i risultati delle interrogazioni. Il secondo vantaggio della risoluzione ricorsiva è che spesso è meno costosa in termini di comunicazione. Dns name space Uno dei più diffusi servizi di naming distribuiti oggi in uso è il domain name system (DNS) di Internet. Il DNS è principalmente usato per ricercare gli indirizzi IP degli host e dei mail server. Spazio dei nomi del DNS Lo spazio dei nomi del DNS è organizzato gerarchicamente come un albero con radice. Un etichetta è una stringa case insensitive ( non sensibile alle maiuscole ) costituita da caratteri alfanumerici, con una lunghezza massima di 63 caratteri; la lunghezza di un path name completo è limitata a 255 caratteri. La radice è costituita da un punto. Un sottoalbero è chiamato dominio; il path name verso il suo nodo radice è chiamato nome del dominio. Il contenuto di un nodo è costituito da un insieme di resource record. Un nodo nello spazio dei nomi del DNS spesso rappresenta molte entità allo stesso tempo. Un resource record SOA (start of autority) contiene informazioni come un indirizzo dell amministratore di sistema responsabile della zona rappresentata, il nome dell host dove si possono prelevare informazioni sulla zona e così via. Un A address record rappresenta un particolare host in 48

49 SEI: CAPITOLO 5 -> NAMING Internet. L A record contiene un indirizzo IP di quell host per consentire la comunicazione. I record MX (mail exchange) sono, invece, un link simbolico a un nodo che rappresenta un mail server. I nodi che rappresentano una zona contengono uno o più record NS (name server). Come i record MX, un record NS contiene il nome di un name server che implementa la zona rappresentata dal nodo. Il DNS distingue gli alias dai cosiddetti nomi canonici. Si suppone che ogni host abbia un nome canonico primario. Un alias è implementato per mezzo di un nodo che memorizza un record CNAME contenente il nome canonico di un host. Il DNS mantiene una corrispondenza inversa tra IP e i nomi degli host per mezzo dei record PTR (pointer). Gli ultimi due tipi di record sono i record HINFO e i record TXT. Un record HINFO (host info) è usato per memorizzare informazioni aggiuntive su un host come il tipo di macchina e di sistema operativo. Analogamente, i record TXT sono usati per ogni altro tipo di dato in merito all entità rappresentata dal nodo che un utente possa in qualche modo trovare utile. Nell esempio sopra riportato, il nodo cs.vu.nl rappresenta il dominio così come la zona. Il suo resource record SOA contiene informazioni specifiche sulla validità di questo file, che non ci interessano ulteriormente. Ci sono 4 name server per questa zona, indicati nei record NS dai loro host name canonici. Il record TXT è usato per fornire informazioni aggiuntive su questa zona, ma non può essere processato automaticamente da alcun name server. Inoltre c è un solo mail server che gestisce le mail in ingresso indirizzate agli utenti in questo dominio. Il numero che precede il nome di un mail server specifica la priorità di selezione. Un mail server che invia un messaggio deve sempre cercare di contattare per primo il mail server con il numero più basso. L host star.cs.vu.nl opera come name server per questa zona. I name server sono critici per ogni servizio di naming. Bisogna notare che questo name server è stato reso più robusto assengandoli due interfacce di rete, ciascuna rappresentata da un A record separato. In questo modo, possono essere ridotte le conseguenze negative che si avrebbero in caso di rottura di una rete, in quanto il server rimane comunque accessibile. Le quattro righe successive (relative a zephyr.cs.vu.nl) forniscono le informazioni necessarie per uno dei mail server del dipartimento. Si noti che per questo mail server ne esiste uno di backup, il cui path è tornado.cs.vu.nl. Le sei righe successive mostrano una configurazione tipica in cui il Web server e l FTP server del dipartimento sono implementati sulla stessa macchina, chiamata soling.cs.vu.nl. Eseguire entrambi i servizi sulla stessa macchina (ed essenzialmente usare questa macchina solo per i servizi Internet e per nient altro) facilita l amministrazione del sistema. Per esempio, entrambi i server avranno la stessa vista del file system e, per motivi di efficienza, parte del file system può essere implementata su soling.cs.vu.nl. Questo approccio è spesso applicato nel caso dei servizi WWW e FTP. 49

50 SEI: CAPITOLO 5 -> NAMING Le due righe successive mostrano informazioni su uno dei cluster di server più vecchi del dipartimento. In questo caso, si indica che l indirizzo sia associato all host name vucs-das1.cs.vu.nl. Le quattro righe successive mostrano informazioni su due delle principale stampanti connesse alla rete. Si noti che gli intdirizzi nell intervallo e sono privati: si può accedervi solo dall interno della rete locale e non da un host arbitrario di internet. NAMING BASATO SUGLI ATTRIBUTI Le entità sono descritte attraverso coppie (attributo, valore). In questo approccio si suppone che un entità abbia associato un insieme di attributi. Ogni attributo indica qualcosa sull entità. È compito del sistema di naming restituire una o più entità che corrispondano alla descrizione dell utente. Gli attributi indicano caratteristiche dell entità. Directory sevice I sistemi di naming basati sugli attributi si definiscono anche come Directory Service e per utilizzare gli attributi, si ha la necessità di concordarli in maniera consistente con altri utenti. Con i DS le entità hanno associato un insieme di attributi utilizzabili per le ricerche. In alcuni casi, la scelta degli attributi è relativamente semplice. Per far si che si utilizzi un modo unico per identificare le risorse, è stato definito un modello Resource Description Framework (RDF) che si basa essenzialmente sul fatto che le risorse sono descritte da triplette costituite da un soggetto, un predicato e un oggetto. Implementazioni gerarchiche: LDAP Un approccio diffuso di affrontare il problema dei directory service distribuiti consiste nel combinare il naming strutturato con quello basato sugli attributi. Questo approccio è stato ampiamente usato, ad esempio, nel servizio di Active Directory di Microsoft e in altri sistemi. Molti di questi sistemi usano o si basano sul lightweight directory access protocol comunemente chiamato LDAP. Concettualmente, un directory service LDAP consiste di un certo numero di record, di solito chiamati elementi della directory. Un elemento della directory è paragonabile a un resource record del DNS. Ogni record è costituito da un insieme di coppie attributo, valore, in cui ogni attributo ha un tipo associato. Bisogna cercare le informazioni in modo esaustivo su tutto l albero. Come nel DNS, l uso di nomi univoci globali ottenuti elencando gli RDN (relative distinguished name: attributo di naming) in sequenza, genera una gerarchia degli elementi della directory, chiamata directory 50

51 SEI: CAPITOLO 5 -> NAMING information tree DIT. Un DIT essenzialmente costituisce il grafo dei nomi del directory service LDAP in cui ogni nodo rappresenta un elemento della directory. Le ricerche vengono fatte tramite 2 funzioni principali: read e list. L operazione read è usata per leggere un singolo record, dato il suo path name nel DIT. Diversamente, l operazione list è usata per elencare i nomi di tutti gli archi in uscita da un dato nodo nel DIT. Ogni nome corrisponde a un nodo figlio del nodo dato. Si noti che l operazione list non restituisce alcun record; essa semplicemente ne restituisce i nomi. Implementazioni decentralizzate Con l introduzione dei sistemi peer-to-peer, i ricercatori hanno iniziato a cercare soluzioni per sistemi di naming decentralizzati basati sugli attributi. L elemento chiave è che deve essere realizzato un mapping delle coppie (attributo, valore) in modo che la ricerca possa essere efficiente, cioè evitando una ricerca esaustiva in tutto lo spazio degli attributi. Mapping in Hash Table distribuite In questo primo caso vengono considerate le coppie (attributo, valore) che sono supportate da un sistema basato su DHT. Il vantaggio dell uso di questo sistema è principalmente che non devono essere supportati intervalli di valori. Nell esempio sopra riportato, l elemento principale è la trasformazione del AVTree in un insieme di chiavi che possano essere ricercate in un sistema DHT. In questo caso, a ogni percorso che parte dalla radice è assegnato un hash univoco, in cui la descrizione del percorso inizia con un collegamento (che rappresenta un attributo) e termina in un nodo (valore) o in un altro collegamento. Bisogna associare un hash ad ogni ramo dell albero. h1: hash (tipo-libro) h2: hash (tipo-libro-autore) h3: hash (tipo-libro-autore-tolkien) h4: hash (tipo-libro-titolo) h5: hash (tipo-libro-titolo-isda) h6: hash (genere-fantasy) Un nodo responsabile dell hash h i gestisce un riferimento alla risorsa reale. Nel nostro esempio questo porta ad avere sei nodi che memorizzano informazioni su il signore degli anelli di Tolkien. Il vantaggio di questa ridondanza è, tuttavia, che consente interrogazioni parziali. Ad esempio, consideriamo un interrogazione del tipo restituisci i libri scritti da Tolkien. Questa interrogazione è tradotta nell AVTree mostrato nella figura sotto, dando luogo al calcolo di tre hash seguenti: h1: hash (tipo-libro) h2: hash (tipo-libro-autore) h3: hash (tipo-libro-autore-tolkien) 51

52 SEI: CAPITOLO 5 -> NAMING Reti overlay semantiche Per rendere efficienti le ricerche, è importante che i nodi abbiano dei riferimenti ad altri nodi che possano molto probabilmente rispondere alle interrogazioni. Se supponiamo che le interrogazioni che hanno origine nel nodo P siano fortemente correlate alle risorse di P, allora stiamo cercando di mettere a disposizione di P un insieme di collegamenti a nodi semanticamente vicini. Ricordiamo che tale elenco è conosciuto anche come vista parziale. La vicinanza semantica può essere definita in diversi modi, ma tutti si riducono al tener traccia dei nodi con risorse simili. I nodi e questi collegamenti costituiscono quindi ciò che è conosciuta come rete overlay semantica. Nella figura sottostante è mostrato uno schema di gossiping a due livelli. Il livello inferiore consiste di un protocollo epidemico che cerca di mantenere una vista parziale di nodi uniformi selezionati casualmente. Il livello superiore mantiene un elenco di nodi semanticamente vicini attraverso il gossiping. Per iniziare uno scambio, un nodo P può selezionare casualmente un nodo Q dalla sua lista attuale, ma il trucco è di lasciare che P invii solo quegli elementi semanticamente più vicini a Q. A sua volta, quando P riceve degli elementi da Q, alla fine manterrà una vista parziale costituita solo dai nodi semanticamente vicini. Come si evince, le viste parziali gestite dal livello superiore convergeranno rapidamente all optimum. 52

53 SEI: CAPITOLO 6 -> SINCRONIZZAZIONE CAPITOLO 6: SINCRONIZZAZIONE La sincronizzazione nei sistemi distribuiti è spesso più difficile rispetto alla sincronizzazione nei sistemi monoprocessore e multiprocessore. SINCRONIZZAZIONE DEL CLOCK Il modo in cui il programma make lavora di solito è semplice. Quando un programmatore ha finito di modificare tutti i file necessari, esegue il programma make che esamina la data e l ora di ultima modifica dei file sorgente e oggetto. Se il file sorgente input.c ha associato l istante 2151 e il corrispondente file oggetto input.o ha associato l istante 2150, il programma make sa che il file input.c è stato modificato dopo aver creato input.o e di conseguenza input.c deve essere compilato. Se invece input.c ha associato l istante 2144 e input.o ha associato l istante 2145, non sarà necessaria alcuna compilazione. Immaginiamo ora cosa sarebbe potuto accadere in un sistema distribuito in cui non ci siano una data e un ora globali. Supponiamo che il file output.o abbia associato l istante 2144 come sopra indicato e che poco dopo venga modificato il file output.c, ma gli venga assegnato l istante 2143, il quanto il clock sulla sua macchina è leggermente in ritardo. Il programma make non richiamerà il compilatore e quindi si avrà un misto di file compilati vecchi e nuovi. Orologi fisici Praticamente tutti i computer hanno un circuito per tener traccia del tempo. Nonostante l ampio uso che si fa della parola clock (orologio) per indicare questi dispositivi, non si tratta realmente di orologi nell accezione comune del termine. Timer sarebbe forse una parola migliore. Un timer del computer di solito è un cristallo di quarzo. Con un solo computer e un solo clock, non ha molta importanza se questo orologio sia leggermente in anticipo o in ritardo. Nel momento in cui si usano più CPU, ciascuna con il proprio clock, la situazione cambia radicalmente. Anche se la frequenza a cui oscilla un cristallo è abbastanza stabile, è impossibile garantire che i cristalli in computer diversi oscillino esattamente alla stessa frequenza. Questa differenza nei valori della data e dell ora è chiamata disallineamento dei clock. Vediamo brevemente come viene misurato in realtà il tempo. Non è affatto facile come può sembrare, soprattutto quando è richiesto un certo grado di accuratezza. Dall invenzione degli orologi meccanici nel diciassettesimo secolo, il tempo è stato misurato dal punto di vista astronomico. Il fatto che il sole raggiunga la sua massima altezza apparente nel cielo è detta culminazione del sole e accade ogni giorno all incirca a mezzogiorno. L intervallo tra due culminazioni consecutive è chiamato giorno solare. 53

54 SEI: CAPITOLO 6 -> SINCRONIZZAZIONE Negli anni 40 è stato scoperto che la durata della rotazione terrestre non è costante. La terra sta rallentando a causa dell attrito delle maree e della resistenza dell atmosfera. I geologi pensano oggi che 300 milioni di anni fa, ci fossero circa 400 giorni in un anno. Non si pensa che sia cambiata la lunghezza dell anno, semplicemente il giorno è diventato più lungo. Gli astronomi hanno effettuato una serie di valutazioni su un gran numero di giorni, prendendone la media prima di dividere per La quantità risultante è chiamata secondo solare medio. Con l invenzione dell orologio atomico nel 1948 è divenuto possibile misurare il tempo più accuratamente e in maniera indipendente dai movimenti della terra, contando le transizioni di un atomo di cesio 133. I fisici si sono assunti il compito di misurare il tempo a scapito degli astronomi e hanno definito il secondo come il tempo che impiega il cesio 133 per compiere esattamente transizioni. La scelta del numero è dovuta al tentativo di rendere il secondo atomico uguale al secondo solare medio calcolato nell anno della sua introduzione. Attualmente, molti laboratori nel mondo hanno orologi al cesio 133. Periodicamente, ogni laboratorio comunica al Bureau International de l Heure (BIH) di Parigi il proprio numero di tic. Il BIH calcola la media di questi valori e definisce il tempo atomico internazionale (TAI). A causa dei piccoli ritardi che sono di circa 3 msec, il BIH risolve il problema introducendo dei secondi intercalare noti come leap seconds secondi di salto ogni volta che la discrepanza tra il TAI e il tempo solare raggiunge gli 800 msec. Questa correzione dà origine a un sistema di tempo basato sui secondi TAI costanti, ma che rimane allineato con il movimento apparente del sole, chiamato tempo coordinato universale, abbreviato in UTC. L UTC è la base di tutti i moderni sistemi di gestione del tempo della nostra civiltà. Ha in sostanza sostituto il vecchio standard, il Greenwich mean time, che è un tempo astronomico. Per rendere disponibile l UTC a coloro che necessitino di una data e un ora precisa, il National Istitute of Standard Time (NIST) gestisce da Ford Collins in Colorado una stazione radio a onde corte che ha come sigla WWV. Essa diffonde un breve impulso all inizio di ogni secondo UTC. Global position system Ora valutiamo il problema della determinazione della posizione geografica di una persona o di un oggetto sulla terra. Questo problema è risolto attraverso un sistema distribuito dedicato e assolutamente specifico, vale a dire il GPS, un acronimo di global positioning system. Il sistema GPS usa 29 satelliti in orbita a circa Km di altezza. Ogni satellite possiede fino a quattro orologi atomici, regolarmente calibrati da speciali stazioni sulla terra. Un satellite diffonde continuamente 54

55 SEI: CAPITOLO 6 -> SINCRONIZZAZIONE la sua posizione e contrassegna ogni messaggio con il suo timestamp locale. Questa diffusione consente a ogni soggetto sulla terra di calcolare con accuratezza la sua posizione, usando, in linea di principio, solo tre satelliti. Per calcolare una posizione, consideriamo per primo il caso bidimensionale, in cui sono disegnati due satelliti e le circonferenze che rappresentano i punti alla stessa distanza del rispettivo satellite. Ignorando il punto più in alto, vediamo che l intersezione delle due circonferenze è un punto univoco. Il principio delle intersezioni delle circonferenze può essere esteso a tre dimensioni, il che significa che sono necessari tre satelliti per conoscere longitudine, latitudine e altitudine di un soggetto sulla terra. Ci sono due aspetti del mondo reale che dobbiamo considerare: 1. Ci vuole un certo tempo perché i dati sulla posizione del satellite raggiungano il soggetto 2. L orologio del soggetto in genere non è sincronizzato con quello del satellite. Algoritmi di sincronizzazione dei clock Se una macchina ha un ricevitore WWV, l obiettivo è di mantenere tutte le altre macchine sincronizzate con essa. Tutti gli algoritmi si basano sullo stesso modello di sistema. Si suppone che ogni macchina abbia un timer che solleva un interrupt H volte al secondo. Chiamiamo C il valore di questo clock. Nello specifico, se t è il valore dell UTC, il valore del clock sulla macchina p è C p (t). In un mondo perfetto avremmo C p (t)=t per ogni macchina p in ogni istante t. in altre parole C p (t)=dc/dt dovrebbe essere idealmente 1. Il disallineamento è definito come C p 1 e denota di quanto si scosta la frequenza da quella del clock perfetto. L offset relativo a uno specifico istante t è dato da C p (t) t. Più precisamente, se esiste una qualche costante ρ tale per cui: 1 - ρ dc/dt 1 + ρ La costante ρ è definita da costruttore ed è nota come tasso di scostamento massimo. Network time protocol Un approccio comune a molti protocolli, originariamente proposto da Cristian (1989), è di lasciare che i client contattino un time server. Quest ultimo può fornire la data e l ora attuali con precisione, grazie alla sua dotazione di un ricevitore WWV o di un clock accurato. Il problema, ovviamente, è che quanto si 55

56 SEI: CAPITOLO 6 -> SINCRONIZZAZIONE contatta il server, il tempo di trasferimento dei messaggi rende obsolete la data e l ora restituite. Il trucco è di trovare una stima valida per questo tempo di trasferimento. Ovviamente il tempo non può tornare indietro. Se il clock di A è veloce θ < 0, significa che A dovrebbe teoricamente spostare indietro il suo orologio. Ciò non è consentito, in quanto potrebbe causare seri problemi, come il fatto che un file oggetto venga compilato subito dopo l aggiornamento dell orologio, dato che ha associate una data e un ora precedenti rispetto al file sorgente modificato prima dell aggiornamento dell orologio. Il network time protocol (NTP) è realizzato tra coppie di server. Il altre parole, B chiederà ad A la sua data e la sua ora attuali. Viene calcolato l offset θ, insieme alla stima δ del tempo di trasferimento. Otto coppie di valori (θ, δ) sono memorizzati nel buffer, assumendo alla fine il valore minimo trovato per δ come migliore stima del tempo di trasferimento tra i due server e successivamente il valore θ a esso associato a come la stima più affidabile dell offset. Algoritmo di Berkeley In molti algoritmi come NTP il time server è passivo. Altre macchine periodicamente gli richiedono data e ora. Tutto ciò che esso fa è rispondere alle loro chieste. In UNIX Berkeley si segue l approccio esattamente opposto. In questo caso il time server (in realtà un time daemon) è attivo, richiedendo di tanto in tanto a ogni macchina che ore sono. In base alla risposta, esso calcola un tempo medio e indica a tutte le altre macchine di far avanzare i loro orologi fino al nuovo tempo o di rallentarli finché non si ottiene una certa riduzione. Questo metodo è adatto a sistemi in cui nessuna macchina ha un ricevitore WWV. La data e l ora dei time daemon devono essere periodicamente impostate da un operatore. Si noti che in genere è sufficiente che tutte le macchine concordino sullo stesso tempo. Non è essenziale che questo tempo corrisponda anche al tempo reale, come quello del segnale orario della radio. Sincronizzazione nelle reti senza fili Un vantaggio importante dei sistemi distribuiti più tradizionali è che i time server sono utilizzabili in maniera facile ed efficiente. Tali supposizioni non sono applicabili a molte reti senza fili, specialmente alle reti di sensori. Inoltre spesso è importante ottimizzare gli algoritmi per il consumo di energia. Queste e altre 56

57 SEI: CAPITOLO 6 -> SINCRONIZZAZIONE considerazioni hanno portato alla progettazione di algoritmi molto diversi per la sincronizzazione nelle reti senza fili. Si noti che nei protocolli come l NTP, il timestamp viene aggiunto a ogni messaggio prima che esso sia passato all interfaccia di rete. Il reference broadcast synchronization (RBS) è un protocollo di sincronizzazione piuttosto diverso dagli altri. L idea di base è semplice, quando un nodo diffonde un messaggio di riferimento m, ogni nodo p registra semplicemente l istante in cui riceve m. Ignorando il disallineamento degli orologi, due nodi p e q si possono scambiare i tempi di trasferimento con l obiettivo di stimare il loro reciproco offset relativo. OROLOGI LOGICI In un articolo ormai divenuto classico, Lamport (1978) dimostrava che anche se la sincronizzazione è possibile, non deve necessariamente essere assoluta. Se due processi non interagiscono, non è necessario che i loro orologi siano sincronizzati in quanto la mancanza di sincronizzazione non sarebbe osservabile e quindi non potrebbe causare problemi. Inoltre, egli sottolineava che di solito non conta che tutti i processi concordino su che ora è, ma piuttosto concordino sull ordine degli eventi. Orologi logici di Lamport Per sincronizzare gli orologi logici, Lamport ha definito una relazione chiamata di precedenza (happensbefore). L'espressione a > b viene letta come "a precede b" e significa che tutti i processi concordino sul fatto che prima accade l'evento a e poi accade l'evento b. La relazione di precedenza può essere direttamente osservata in due situazioni. 1. Se a e b sono eventi dello stesso processo e a precede b, allora a > b è vera. 2. Se a è l'evento d'invio di un messaggio da parte di un processo e b è l'evento di ricezione del messaggio da parte di un altro processo, allora a > b è di nuovo vera. Un messaggio non può essere ricevuto prima di essere inviato, o nello stesso istante in cui è inviato, in quanto richiede un tempo finito maggiore di zero per raggiungere la destinazione. La relazione di precedenza è transitiva, per cui se a > b e b > c allora a > c. Ogni clock ha una frequenza costante, ma le frequenze sono diverse a causa dell'uso di cristalli diversi. Nell'istante 6, il processo P1 invia il messaggio m1 al processo P2. Quanto tempo impiega il messaggio ad arrivare dipende dal clock di riferimento. In ogni caso, il clock del processo P2 segna 16 all'arrivo del messaggio. Se il messaggio riporta come inizio l'istante 6, il processo P2 concluderà che ha impiegato 10 colpi di clock per compiere il suo percorso. Questo valore è assolutamente plausibile. Seguendo tale ragionamento, il messaggio m2 da parte di P2 verso P3 impiega 16 colpi di clock, di nuovo un valore plausibile. Consideriamo ora il messaggio m3. Esso lascia il processo P3 all'istante 60 e raggiunge P2 all'istante 56. Analogamente il messaggio m4 da P2 a P1 parte all'istante 64 e arriva all'istante 54. Questi valori sono 57

58 SEI: CAPITOLO 6 -> SINCRONIZZAZIONE chiaramente impossibili e bisogna impedire situazioni di questo tipo. Per implementare gli orologi logici di Lamport, ogni processo A mantiene un contatore locale Ci. Questi contatori vengono aggiornati nel modo seguente: 1. prima di eseguire un evento (cioè inviare un messaggio sulla rete, consegnare un messaggio a un'applicazione o qualche altro evento interno), Pi esegue Ci <-- Ci + 1; 2. quando il processo Pi invia il messaggio m a Pj, imposta il timestamp di m, detto ts(m), uguale a Ci dopo aver eseguito il passo precedente; 3. quando riceve il messaggio m, il processo Pj corregge il suo contatore locale eseguendo Cj<--max[Cj, ts(m)), dopodiché esegue il passo al punto 1 e consegna il messaggio all'applicazione. Esempio multicasting totalmente ordinato Come applicazione degli orologi logici di Lamport, consideriamo una base di dati replicata in diversi siti. Ad esempio, per migliorare le prestazioni delle interrogazioni, una banca potrebbe posizionare due copie di una base di dati dei conti in due città diverse, come New York e San Francisco. Il prezzo per un tempo di risposta migliore si paga parzialmente con un costo di aggiornamento superiore, in quanto ogni operazione di aggiornamento deve essere eseguita su tutte le repliche. In realtà, c è un requisito più stringente relativo agli aggiornamenti. Supponiamo che un cliente a San Francisco voglia versare $100 sul proprio conto, che attualmente ammonta a $1000. Contemporaneamente, un impiegato di banca a New York inizia la procedura di accredito degli interessi, secondo la quale il conto del cliente va incrementato dell'1%. Entrambi gli aggiornamenti devono essere eseguiti su entrambe le copie della base di dati. Tuttavia, a causa dei ritardi nella comunicazione della rete sottostante, l'arrivo degli aggiornamenti può corrispondere all'ordine mostrato nella Figura. L'operazione di aggiornamento del cliente è eseguita a San Francisco prima dell'aggiornamento degli interessi. Diversamente, la copia del conto sulla replica di New York prima viene aggiornata con l'1% di interessi e poi con il deposito di $100. Di conseguenza, la base di dati di San Francisco memorizzerà il valore $1111 come totale del conto, mentre la base di dati a New York memorizzerà $1110. Il problema che stiamo affrontando è che le due operazioni di aggiornamento avrebbero dovuto essere eseguite nello stesso ordine su entrambe le copie. Anche se c'è differenza nell'eseguire il deposito prima o dopo l'aggiornamento degli interessi, dal punto di vista della consistenza non ha importanza quale ordine venga seguito. L'aspetto importante è che le due copie devono essere identiche. In generale, situazioni come queste richiedono un multicast totalmente ordinato, vale a dire un'operazione di multicast attraverso 58

59 SEI: CAPITOLO 6 -> SINCRONIZZAZIONE la quale tutti i messaggi sono consegnati nello stesso ordine a ogni destinatario. Gli orologi logici di Lamport possono essere usati per implementare il multicast totalmente ordinato in maniera completamente distribuita. Quando un processo riceve un messaggio, lo mette in una coda locale, ordinata in base al timestamp. Il destinatario invia in multicast un messaggio di conferma (acknowledgement) agli altri processi. Si noti che se seguiamo l'algoritmo di Lamport per correggere gli orologi, il timestamp del messaggio ricevuto è inferiore a quello del messaggio di conferma. L'aspetto interessante di questo approccio è che tutti i processi avranno alla fine la stessa copia della coda locale (a patto che nessun messaggio venga cancellato). Un processo può consegnare un messaggio in coda all'applicazione che sta eseguendo solo quando quel messaggio è in cima alla coda ed è stato riconosciuto da ogni altro processo. A questo punto, il messaggio viene rimosso dalla coda e passato all'applicazione; i messaggi di conferma associati possono semplicemente essere rimossi. Dato che ogni processo ha la stessa copia della coda, tutti i messaggi sono consegnati ovunque nello stesso ordine. In altre parole, abbiamo generato il multicasting totalmente ordinato. Clock vettoriali Con gli orologi di Lamport, non si può dire nulla della relazione tra due eventi a e b confrontando semplicemente i valori C(a) e C(b), rispettivamente. In altre parole, il fatto che C(a) < C(b) non implica necessariamente che a preceda davvero b. Per ottenerlo ci vuole qualcosa in più. Il problema è che gli orologi di Lamport non colgono il rapporto causa/effetto che può essere invece colto dai clock vettoriali. Un clock vettoriale VC(a) assegnato a un evento a ha la proprietà che se VC(a) < VC(b) per un evento b, allora si sa che l'evento a ha un rapporto di causa/effetto con l'evento b. I clock vettoriali sono costruiti lasciando che ogni processo P i mantenga un vettore VC; con le seguenti due proprietà: 1. VC[i] è il numero di eventi occorsi finora in P i. In altre parole, VC i [i] è l'orologio logico locale del processo P i ; 2. se VC i [j] = k allora P i sa che sono occorsi k eventi in P j. In questo modo P i conosce il tempo locale di P j La prima proprietà è mantenuta incrementando VC i [i] all'occorrenza di ogni nuovo evento nel processo P i. La seconda proprietà è mantenuta portandosi dietro i vettori insieme ai messaggi inviati. In particolare, sono eseguiti i seguenti passi: 1. prima di eseguire un evento (cioè inviare un messaggio sulla rete, consegnare un messaggio a un'applicazione o qualche altro evento interno), Pi esegue: VCi[i] <- VCi[i] + 1; 2. quando un processo Pi invia un messaggio m a Pj, imposta il timestamp vettoriale di ts(m) uguale a VCi dopo che ha eseguito il passo precedente; 3. quando riceve un messaggio m, il processo Pj corregge il suo vettore VCj al massimo impostando VCj[k]<-max{VCj[k], ts(m)[k]} per ogni k, dopodiché esegue il primo passo e consegna il messaggio all'applicazione. 59

60 SEI: CAPITOLO 6 -> SINCRONIZZAZIONE Si noti che se un evento a ha un valore del timestamp ts(a), allora ts(a)[i] -1 denota il numero di eventi processati in P i che precedono causalmente a. Di conseguenza, quando Pj riceve un messaggio da Pi con timestamp ts(m), conosce il numero di eventi occorsi in Pi che precedono causalmente l'invio di m. Forzare la comunicazione causale Usando i clock vettoriali è ora possibile assicurare che un messaggio venga consegnato solo se tutti i messaggi che lo precedono causalmente sono stati ricevuti. Per realizzare tale schema, supponiamo che venga fatto un multicast dei messaggi all'interno di un gruppo di processi. Si noti che questo multicasting causalmente ordinato è più debole del multicasting totalmente ordinato che abbiamo visto in precedenza. Supponiamo ora che Pj riceva un messaggio m da Pi con timestamp (vettoriale) ts(m). La consegna del messaggio al livello applicativo sarà ritardata finché non si verificano le seguenti due condizioni: 1. ts(m)[i] = VCj[i] ts(m)[k] VCj[k] per ogni k i La prima condizione indica che m è il messaggio successivo che Pj si aspetta dal processo Pi. La seconda condizione indica che Pj ha visto gli stessi messaggi di Pi quando invia il messaggio m. Si noti che non c'è la necessità che Pj ritardi la consegna dei suoi messaggi. Come esempio, consideriamo i tre processi P0, P1 e P2 come mostrati nella Figura. Nell'istante (1, 0, 0), P0 invia il messaggio m agli altri due processi. Dopo che l'ha ricevuto, P1 decide di inviare il messaggio m* che raggiunge P2 prima di m. A questo punto, la consegna di m* viene ritardata da P2 finché m non sia stato ricevuto e consegnato al livello applicativo di P2. MUTUA ESLUSIONE Un algoritmo centralizzato Il modo più facile di ottenere la mutua esclusione in un sistema distribuito è di simulare ciò che accade in un sistema monoprocessore. Un processo viene eletto come coordinatore. Quando un processo vuole accedere a una risorsa condivisa, invia un messaggio di richiesta al coordinatore, dichiarando a quale risorsa voglia accedere e richiedendone l'autorizzazione. Se nessun altro processo sta attualmente accedendo alla risorsa, il coordinatore restituisce una risposta concedendo l'autorizzazione, come mostrato nella Figura (a). Quando arriva la risposta, il processo richiedente può andare avanti. Supponiamo ora che un altro processo, il numero 2 nella Figura (b), richieda l'autorizzazione d'accesso alla risorsa. Il coordinatore sa che un altro processo sta già usando la risorsa, per cui non può concedere 60

61 SEI: CAPITOLO 6 -> SINCRONIZZAZIONE l'autorizzazione. Il metodo esatto per negare l'autorizzazione dipende dal sistema. Nella Figura (b) il coordinatore evita semplicemente di rispondere, bloccando cosi il processo 2 che rimane in attesa di una risposta. Alternativamente, potrebbe inviare una risposta del tipo "autorizzazione negata". In entrambi i casi, la richiesta del processo 2 viene messa in una coda per un certo tempo in attesa di altri messaggi. Quando il processo 1 finisce di usare la risorsa, invia un messaggio al coordinatore rilasciando il suo accesso esclusivo, come mostrato nella Figura (c). Il coordinatore prende il primo messaggio dalla coda delle richieste in attesa e invia a quel processo un messaggio di autorizzazione. Se il processo era ancora bloccato, si sblocca e accede alla risorsa. Quindi l'algoritmo garantisce la mutua esclusione. L approccio centralizzato presenta anche alcuni svantaggi. Il coordinatore è un punto singolo di malfunzionamento, per cui, se subisce un crash, l'intero sistema può "piantarsi". Un algoritmo decentralizzato Avere un singolo coordinatore spesso non è sufficiente. La soluzione proposta estende il coordinatore centralizzato nel seguente modo. Si suppone che ogni risorsa sia replicata ogni volta, ogni replica ha il suo coordinatore per controllare l accesso da parte di processi concorrenti. Tuttavia quando un processo vuole accedere ad una risorsa, dovrà semplicemente ottenere un voto di maggioranza da m>n/2 coordinatori. Con n=32 e m=0,75n la probabilità di violare la correttezza è meno di 10-40, sicuramente più piccola della disponibilità di qualunque risorsa. Un algoritmo distribuito L'algoritmo lavora come descritto di seguito. Quando un processo vuole accedere a una risorsa condivisa, costruisce un messaggio contenente il nome della risorsa, il suo numero e l'istante (logico) attuale. Quindi invia il messaggio a tutti gli altri processi, concettualmente includendo se stesso. Si suppone che l'invio dei messaggi sia affidabile, cioè che nessun messaggio vada perso. Quando un processo riceve un messaggio di richiesta da un altro processo, l'azione che intraprende dipende dal suo stato rispetto alla risorsa indicata nel messaggio. Devono essere chiaramente distinti tre casi diversi: 1. se il destinatario non sta accedendo alla risorsa e non vuole accedervi, restituisce un messaggio di tipo OK al mittente; 2. se il destinatario ha già accesso alla risorsa, semplicemente non risponde. Invece, mette la richiesta in coda; 3. se il destinatario vuole accedere alla risorsa, ma non l'ha ancora fatto, confronta il timestamp del messaggio in ingresso con quello contenuto nel messaggio che ha inviato a tutti. Quello più basso vince. Se il messaggio in ingresso ha un timestamp più basso, il destinatario restituisce un messaggio di tipo OK. Se il suo messaggio ha un timestamp più basso, il destinatario mette il messaggio in ingresso in coda e non invia alcunché. Dopo aver inviato le richieste di autorizzazione, un processo si ferma e attende finché tutti gli altri non l'abbiano autorizzato. Non appena arrivano tutte le autorizzazioni, esso può continuare. Quando ha terminato, invia messaggi di tipo OK a tutti i processi nella sua coda e li cancella da essa. Proviamo a capire perché l'algoritmo funziona. In assenza di conflitto, è evidente che funzioni. Tuttavia, supponiamo che due processi cerchino di accedere alla risorsa simultaneamente, come mostrato nella Figura (a). 61

62 SEI: CAPITOLO 6 -> SINCRONIZZAZIONE Il processo 0 invia a tutti una richiesta con timestamp 8, mentre contemporaneamente il processo 2 invia a tutti una richiesta con timestamp 12. Il processo 1 non è interessato alla risorsa e quindi invia un messaggio di tipo OK a entrambi i processi. I processi 0 e 2 vedono il conflitto e confrontano i timestamp. Il processo 2 vede che ha perso, per cui invia l'autorizzazione al processo 0 inviando un messaggio di tipo OK. Il processo 0 mette in coda la richiesta del processo 2 di una successiva elaborazione e accede alla risorsa, come mostrato nella Figura (b). Al termine, rimuove la richiesta proveniente dal processo 2 dalla sua coda e invia un messaggio di tipo OK al processo 2, consentendo a, quest'ultimo di continuare, come mostrato nella Figura (c). L'algoritmo funziona perché, nel caso di un conflitto, il timestamp più basso vince e tutti concordano sull'ordinamento dei timestamp. Come con l'algoritmo centralizzato descritto in precedenza, la mutua esclusione è garantita senza deadlock e starvation. Sfortunatamente, il singolo point of failure è stato sostituito da n point of failure. Se un qualunque processo si pianta, non risponderà alla richiesta. Dato che la probabilità che fallisca uno di n processi è almeno n volte quella che un singolo coordinatore subisca un crash, abbiamo fatto di tutto per sostituire un algoritmo insufficiente con uno che è più di n volte peggio e richiede anche un maggiore traffico di rete. Perché annoiarsi a studiarlo in queste condizioni? Per un semplice motivo: esso dimostra che un algoritmo distribuito è quanto meno possibile, cosa non del tutto ovvia all'inizio della nostra dissertazione. Distribuzione AD ANELLI Un approccio completamente differente per ottenere la mutua esclusione in maniera deterministica in un sistema distribuito è mostrato nella figura. La rete a bus, mostrata nella Figura (a) (ad esempio Ethernet), non ha alcun ordinamento intrinseco dei processi. Viene costruito via software un anello logico in cui ogni processo ha assegnata una posizione nell'anello, come mostrato nella Figura (b). Quando l'anello viene inizializzato, viene dato al processo 0 un token. Il token circola all'interno dell'anello. Viene passato dal processo k al processo k + 1 (modulo la dimensione dell'anello) in messaggi punto-apunto. Quando un processo riceve il token dal suo vicino, controlla se ha la necessità di accedere alla risorsa condivisa. Se è così, il processo continua, fa tutto ciò che deve fare e rilascia la risorsa. Dopo che ha terminato, passa il token lungo l'anello. Non è consentito accedere di nuovo immediatamente alla risorsa usando lo stesso token. È facile verificare la correttezza dell'algoritmo. In ogni istante solo un processo ha il token, per cui solo un processo può realmente accedere alla risorsa. Dato che il token circola tra i processi in un ordine ben 62

63 SEI: CAPITOLO 6 -> SINCRONIZZAZIONE definito, non è possibile che si verifichi la starvation. Una volta che un processo decide di aver bisogno di una risorsa, nel caso peggiore deve attendere che tutti gli altri processi la usino. Come sempre, questo algoritmo ha anche dei problemi. Se il token viene perso, deve essere rigenerato. Se richiediamo a un processo che riceve il token di confermare la ricezione, un processo che si è piantato verrà individuato quando un vicino cercherà di passargli il token e non ci riuscirà. Confronto tra i 4 algoritmi L'algoritmo centralizzato è il più semplice e quindi il più efficiente. Richiede solo tre messaggi per entrare e uscire dalla regione critica: una richiesta, un'autorizzazione d'ingresso e un rilascio per l'uscita. Nel caso decentralizzato, si vede che i messaggi devono essere inviati a ciascuno degli m coordinatori, ma è possibile che siano necessari numerosi tentativi (per i quali introduciamo la variabile k). L'algoritmo distribuito necessita di n - 1 messaggi di richiesta, uno per ogni altro processo e anche di n-1 messaggi di autorizzazione, per un totale di 2 (n - 1) messaggi. (Supponiamo che siano usati solo canali di comunicazione punto-a-punto). Con l'algoritmo token ring, il numero è variabile. Se ogni processo vuole costantemente entrare in una regione critica, allora ogni passaggio di token si traduce in un ingresso e in un'uscita, con una media di un messaggio per ogni regione critica in cui si entra. Il token può però anche circolare per ore senza che nessuno ne sia interessato. In questo caso, il numero di messaggi per ingresso in una regione critica è illimitato. Ci vuole il tempo di due messaggi per entrare in una regione critica nel caso centralizzato, ma il tempo diventa 3mk per il caso decentralizzato, dove k è il numero di tentativi necessari. Supponendo che i messaggi siano inviati l'uno dopo l'altro, nel caso distribuito sono necessari 2 (n-1) tempi messaggio. Per il token ring il tempo varia da 0 (il token è appena arrivato) a n- 1 (il token se n'è appena andato). Infine, tutti gli algoritmi, escluso quello decentralizzato, sono molto sensibili ai crash dei processi. Devono essere introdotte misure speciali e un ulteriore livello di complessità per evitare che un crash faccia cadere l'intero sistema. Fa sorridere il fatto che gli algoritmi distribuiti siano anche più sensibili di quello centralizzato. In un sistema progettato per essere fault tolerant, nessuno di questi algoritmi sarebbe adatto, ma se i crash sono molti rari, allora vanno bene. POSIZIONE GLOBALE DEI NODI Consideriamo il routing basato sulla posizione. In tali schemi, un messaggio è inoltrato alla sua destinazione usando solo informazioni relative alla posizione. 63

I Thread. I Thread. I due processi dovrebbero lavorare sullo stesso testo

I Thread. I Thread. I due processi dovrebbero lavorare sullo stesso testo I Thread 1 Consideriamo due processi che devono lavorare sugli stessi dati. Come possono fare, se ogni processo ha la propria area dati (ossia, gli spazi di indirizzamento dei due processi sono separati)?

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

Il Sistema Operativo. C. Marrocco. Università degli Studi di Cassino

Il Sistema Operativo. C. Marrocco. Università degli Studi di Cassino Il Sistema Operativo Il Sistema Operativo è uno strato software che: opera direttamente sull hardware; isola dai dettagli dell architettura hardware; fornisce un insieme di funzionalità di alto livello.

Dettagli

Con il termine Sistema operativo si fa riferimento all insieme dei moduli software di un sistema di elaborazione dati dedicati alla sua gestione.

Con il termine Sistema operativo si fa riferimento all insieme dei moduli software di un sistema di elaborazione dati dedicati alla sua gestione. Con il termine Sistema operativo si fa riferimento all insieme dei moduli software di un sistema di elaborazione dati dedicati alla sua gestione. Compito fondamentale di un S.O. è infatti la gestione dell

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

La gestione di un calcolatore. Sistemi Operativi primo modulo Introduzione. Sistema operativo (2) Sistema operativo (1)

La gestione di un calcolatore. Sistemi Operativi primo modulo Introduzione. Sistema operativo (2) Sistema operativo (1) La gestione di un calcolatore Sistemi Operativi primo modulo Introduzione Augusto Celentano Università Ca Foscari Venezia Corso di Laurea in Informatica Un calcolatore (sistema di elaborazione) è un sistema

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

3. Introduzione all'internetworking

3. Introduzione all'internetworking 3. Introduzione all'internetworking Abbiamo visto i dettagli di due reti di comunicazione: ma ce ne sono decine di tipo diverso! Occorre poter far comunicare calcolatori che si trovano su reti di tecnologia

Dettagli

A intervalli regolari ogni router manda la sua tabella a tutti i vicini, e riceve quelle dei vicini.

A intervalli regolari ogni router manda la sua tabella a tutti i vicini, e riceve quelle dei vicini. Algoritmi di routing dinamici (pag.89) UdA2_L5 Nelle moderne reti si usano algoritmi dinamici, che si adattano automaticamente ai cambiamenti della rete. Questi algoritmi non sono eseguiti solo all'avvio

Dettagli

MODELLO CLIENT/SERVER. Gianluca Daino Dipartimento di Ingegneria dell Informazione Università degli Studi di Siena daino@unisi.it

MODELLO CLIENT/SERVER. Gianluca Daino Dipartimento di Ingegneria dell Informazione Università degli Studi di Siena daino@unisi.it MODELLO CLIENT/SERVER Gianluca Daino Dipartimento di Ingegneria dell Informazione Università degli Studi di Siena daino@unisi.it POSSIBILI STRUTTURE DEL SISTEMA INFORMATIVO La struttura di un sistema informativo

Dettagli

Approccio stratificato

Approccio stratificato Approccio stratificato Il sistema operativo è suddiviso in strati (livelli), ciascuno costruito sopra quelli inferiori. Il livello più basso (strato 0) è l hardware, il più alto (strato N) è l interfaccia

Dettagli

Una architettura peer-topeer per la visualizzazione 3D distribuita

Una architettura peer-topeer per la visualizzazione 3D distribuita Una architettura peer-topeer per la visualizzazione 3D distribuita Claudio Zunino claudio.zunino@polito.it Andrea Sanna andrea.sanna@polito.it Dipartimento di Automatica e Informatica Politecnico di Torino

Dettagli

SISTEMI OPERATIVI. Prof. Enrico Terrone A. S: 2008/09

SISTEMI OPERATIVI. Prof. Enrico Terrone A. S: 2008/09 SISTEMI OPERATIVI Prof. Enrico Terrone A. S: 2008/09 Che cos è il sistema operativo Il sistema operativo (SO) è il software che gestisce e rende accessibili (sia ai programmatori e ai programmi, sia agli

Dettagli

Reti di Telecomunicazione Lezione 8

Reti di Telecomunicazione Lezione 8 Reti di Telecomunicazione Lezione 8 Marco Benini Corso di Laurea in Informatica marco.benini@uninsubria.it Livello di trasporto Programma della lezione relazione tra lo strato di trasporto e lo strato

Dettagli

Scheduling della CPU. Sistemi multiprocessori e real time Metodi di valutazione Esempi: Solaris 2 Windows 2000 Linux

Scheduling della CPU. Sistemi multiprocessori e real time Metodi di valutazione Esempi: Solaris 2 Windows 2000 Linux Scheduling della CPU Sistemi multiprocessori e real time Metodi di valutazione Esempi: Solaris 2 Windows 2000 Linux Sistemi multiprocessori Fin qui si sono trattati i problemi di scheduling su singola

Dettagli

Concetti di base di ingegneria del software

Concetti di base di ingegneria del software Concetti di base di ingegneria del software [Dalle dispense del corso «Ingegneria del software» del prof. A. Furfaro (UNICAL)] Principali qualità del software Correttezza Affidabilità Robustezza Efficienza

Dettagli

Introduzione alla Virtualizzazione

Introduzione alla Virtualizzazione Introduzione alla Virtualizzazione Dott. Luca Tasquier E-mail: luca.tasquier@unina2.it Virtualizzazione - 1 La virtualizzazione è una tecnologia software che sta cambiando il metodo d utilizzo delle risorse

Dettagli

Progettare un Firewall

Progettare un Firewall Progettare un Firewall Danilo Demarchi danilo@cuneo.linux.it GLUG Cuneo Corso Sicurezza 2006 Concetti introduttivi Come pensare un Firewall Argomenti trattati I Gli strumenti del Firewall Gli strumenti

Dettagli

Gestione della memoria centrale

Gestione della memoria centrale Gestione della memoria centrale Un programma per essere eseguito deve risiedere in memoria principale e lo stesso vale per i dati su cui esso opera In un sistema multitasking molti processi vengono eseguiti

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

GLI APPARATI PER L INTERCONNESSIONE DI RETI LOCALI 1. Il Repeater 2. L Hub 2. Il Bridge 4. Lo Switch 4. Router 6

GLI APPARATI PER L INTERCONNESSIONE DI RETI LOCALI 1. Il Repeater 2. L Hub 2. Il Bridge 4. Lo Switch 4. Router 6 GLI APPARATI PER L INTERCONNESSIONE DI RETI LOCALI 1 Il Repeater 2 L Hub 2 Il Bridge 4 Lo Switch 4 Router 6 Gli apparati per l interconnessione di reti locali Distinguiamo i seguenti tipi di apparati:

Dettagli

Dal protocollo IP ai livelli superiori

Dal protocollo IP ai livelli superiori Dal protocollo IP ai livelli superiori Prof. Enrico Terrone A. S: 2008/09 Protocollo IP Abbiamo visto che il protocollo IP opera al livello di rete definendo indirizzi a 32 bit detti indirizzi IP che permettono

Dettagli

Le Infrastrutture Software ed il Sistema Operativo

Le Infrastrutture Software ed il Sistema Operativo Le Infrastrutture Software ed il Sistema Operativo Corso di Informatica CdL: Chimica Claudia d'amato claudia.damato@di.uniba.it Il Sistema Operativo (S0) (Inf.) E' l'insieme dei programmi che consentono

Dettagli

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

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

Dettagli

Reti di Telecomunicazioni Mobile IP Mobile IP Internet Internet Protocol header IPv4 router host indirizzi IP, DNS URL indirizzo di rete

Reti di Telecomunicazioni Mobile IP Mobile IP Internet Internet Protocol header IPv4 router host indirizzi IP, DNS URL indirizzo di rete IP Analizziamo con sufficiente dettaglio il sistema denominato IP, usato per consentire a due computer mobili di spostarsi liberamente in altre reti pur mantenendo lo stesso indirizzo IP. In particolare,

Dettagli

Introduzione Ai Data Bases. Prof. Francesco Accarino IIS Altiero Spinelli Via Leopardi 132 Sesto San giovanni

Introduzione Ai Data Bases. Prof. Francesco Accarino IIS Altiero Spinelli Via Leopardi 132 Sesto San giovanni Introduzione Ai Data Bases Prof. Francesco Accarino IIS Altiero Spinelli Via Leopardi 132 Sesto San giovanni I Limiti Degli Archivi E Il Loro Superamento Le tecniche di gestione delle basi di dati nascono

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

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

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2014-15. Pietro Frasca. Parte II Lezione 5 Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2014-15 Parte II Lezione 5 Giovedì 19-03-2015 1 Intensità del traffico e perdita dei pacchetti La componente

Dettagli

Indice generale. OOA Analisi Orientata agli Oggetti. Introduzione. Analisi

Indice generale. OOA Analisi Orientata agli Oggetti. Introduzione. Analisi Indice generale OOA Analisi Orientata agli Oggetti Introduzione Analisi Metodi d' analisi Analisi funzionale Analisi del flusso dei dati Analisi delle informazioni Analisi Orientata agli Oggetti (OOA)

Dettagli

Introduzione. Classificazione di Flynn... 2 Macchine a pipeline... 3 Macchine vettoriali e Array Processor... 4 Macchine MIMD... 6

Introduzione. Classificazione di Flynn... 2 Macchine a pipeline... 3 Macchine vettoriali e Array Processor... 4 Macchine MIMD... 6 Appunti di Calcolatori Elettronici Esecuzione di istruzioni in parallelo Introduzione... 1 Classificazione di Flynn... 2 Macchine a pipeline... 3 Macchine vettoriali e Array Processor... 4 Macchine MIMD...

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

Online Help StruxureWare Data Center Expert

Online Help StruxureWare Data Center Expert Online Help StruxureWare Data Center Expert Version 7.2.7 StruxureWare Data Center ExpertDispositivo virtuale Il server StruxureWare Data Center Expert 7.2 è disponibile come dispositivo virtuale, supportato

Dettagli

Siamo così arrivati all aritmetica modulare, ma anche a individuare alcuni aspetti di come funziona l aritmetica del calcolatore come vedremo.

Siamo così arrivati all aritmetica modulare, ma anche a individuare alcuni aspetti di come funziona l aritmetica del calcolatore come vedremo. DALLE PESATE ALL ARITMETICA FINITA IN BASE 2 Si è trovato, partendo da un problema concreto, che con la base 2, utilizzando alcune potenze della base, operando con solo addizioni, posso ottenere tutti

Dettagli

Determinare la grandezza della sottorete

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

Dettagli

Sistemi Operativi IMPLEMENTAZIONE DEL FILE SYSTEM. Implementazione del File System. Struttura del File System. Implementazione

Sistemi Operativi IMPLEMENTAZIONE DEL FILE SYSTEM. Implementazione del File System. Struttura del File System. Implementazione IMPLEMENTAZIONE DEL FILE SYSTEM 9.1 Implementazione del File System Struttura del File System Implementazione Implementazione delle Directory Metodi di Allocazione Gestione dello spazio libero Efficienza

Dettagli

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

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

Dettagli

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

BASE DI DATI: introduzione. Informatica 5BSA Febbraio 2015

BASE DI DATI: introduzione. Informatica 5BSA Febbraio 2015 BASE DI DATI: introduzione Informatica 5BSA Febbraio 2015 Di cosa parleremo? Base di dati relazionali, modelli e linguaggi: verranno presentate le caratteristiche fondamentali della basi di dati. In particolare

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

CAPITOLO 1. Introduzione alle reti LAN

CAPITOLO 1. Introduzione alle reti LAN CAPITOLO 1 Introduzione alle reti LAN Anche se il termine rete ha molte accezioni, possiamo definirla come un gruppo di due o più computer collegati. Se i computer sono collegati in rete è possibile scambiarsi

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

HBase Data Model. in più : le colonne sono raccolte in gruppi di colonne detti Column Family; Cosa cambia dunque?

HBase Data Model. in più : le colonne sono raccolte in gruppi di colonne detti Column Family; Cosa cambia dunque? NOSQL Data Model HBase si ispira a BigTable di Google e perciò rientra nella categoria dei column store; tuttavia da un punto di vista logico i dati sono ancora organizzati in forma di tabelle, in cui

Dettagli

Nelle reti di calcolatori, le porte (traduzione impropria del termine. port inglese, che in realtà significa porto) sono lo strumento

Nelle reti di calcolatori, le porte (traduzione impropria del termine. port inglese, che in realtà significa porto) sono lo strumento I protocolli del livello di applicazione Porte Nelle reti di calcolatori, le porte (traduzione impropria del termine port inglese, che in realtà significa porto) sono lo strumento utilizzato per permettere

Dettagli

Pronto Esecuzione Attesa Terminazione

Pronto Esecuzione Attesa Terminazione Definizione Con il termine processo si indica una sequenza di azioni che il processore esegue Il programma invece, è una sequenza di azioni che il processore dovrà eseguire Il processo è quindi un programma

Dettagli

Software per Helpdesk

Software per Helpdesk Software per Helpdesk Padova - maggio 2010 Antonio Dalvit - www.antoniodalvit.com Cosa è un helpdesk? Un help desk è un servizio che fornisce informazioni e assistenza ad utenti che hanno problemi nella

Dettagli

Architettura hardware

Architettura hardware Architettura dell elaboratore Architettura hardware la parte che si può prendere a calci Sistema composto da un numero elevato di componenti, in cui ogni componente svolge una sua funzione elaborazione

Dettagli

Architetture Applicative

Architetture Applicative Alessandro Martinelli alessandro.martinelli@unipv.it 6 Marzo 2012 Architetture Architetture Applicative Introduzione Alcuni esempi di Architetture Applicative Architetture con più Applicazioni Architetture

Dettagli

Introduzione alle basi di dati. Gestione delle informazioni. Gestione delle informazioni. Sistema informatico

Introduzione alle basi di dati. Gestione delle informazioni. Gestione delle informazioni. Sistema informatico Introduzione alle basi di dati Introduzione alle basi di dati Gestione delle informazioni Base di dati Modello dei dati Indipendenza dei dati Accesso ai dati Vantaggi e svantaggi dei DBMS Gestione delle

Dettagli

Client - Server. Client Web: il BROWSER

Client - Server. Client Web: il BROWSER Client - Server Client Web: il BROWSER Il client Web è un applicazione software che svolge il ruolo di interfaccia fra l utente ed il WWW, mascherando la complessità di Internet. Funzioni principali Inviare

Dettagli

Sistemi Operativi MECCANISMI E POLITICHE DI PROTEZIONE. D. Talia - UNICAL. Sistemi Operativi 13.1

Sistemi Operativi MECCANISMI E POLITICHE DI PROTEZIONE. D. Talia - UNICAL. Sistemi Operativi 13.1 MECCANISMI E POLITICHE DI PROTEZIONE 13.1 Protezione Obiettivi della Protezione Dominio di Protezione Matrice di Accesso Implementazione della Matrice di Accesso Revoca dei Diritti di Accesso Sistemi basati

Dettagli

MECCANISMI E POLITICHE DI PROTEZIONE 13.1

MECCANISMI E POLITICHE DI PROTEZIONE 13.1 MECCANISMI E POLITICHE DI PROTEZIONE 13.1 Protezione Obiettivi della Protezione Dominio di Protezione Matrice di Accesso Implementazione della Matrice di Accesso Revoca dei Diritti di Accesso Sistemi basati

Dettagli

Sistemi centralizzati e distribuiti

Sistemi centralizzati e distribuiti Sistemi centralizzati e distribuiti In relazione al luogo dove è posta fisicamente la base di dati I sistemi informativi, sulla base del luogo dove il DB è realmente dislocato, si possono suddividere in:

Dettagli

Contesto: Peer to Peer

Contesto: Peer to Peer Contesto: Peer to Peer Un architettura di rete P2P è caratterizzata da: Connessioni dirette tra i suoi componenti. Tutti i nodi sono entità paritarie (peer). Risorse di calcolo, contenuti, applicazioni

Dettagli

Lo scenario: la definizione di Internet

Lo scenario: la definizione di Internet 1 Lo scenario: la definizione di Internet INTERNET E UN INSIEME DI RETI DI COMPUTER INTERCONNESSE TRA LORO SIA FISICAMENTE (LINEE DI COMUNICAZIONE) SIA LOGICAMENTE (PROTOCOLLI DI COMUNICAZIONE SPECIALIZZATI)

Dettagli

Capitolo 3. L applicazione Java Diagrammi ER. 3.1 La finestra iniziale, il menu e la barra pulsanti

Capitolo 3. L applicazione Java Diagrammi ER. 3.1 La finestra iniziale, il menu e la barra pulsanti Capitolo 3 L applicazione Java Diagrammi ER Dopo le fasi di analisi, progettazione ed implementazione il software è stato compilato ed ora è pronto all uso; in questo capitolo mostreremo passo passo tutta

Dettagli

Sistemi Operativi Kernel

Sistemi Operativi Kernel Approfondimento Sistemi Operativi Kernel Kernel del Sistema Operativo Kernel (nocciolo, nucleo) Contiene i programmi per la gestione delle funzioni base del calcolatore Kernel suddiviso in moduli. Ogni

Dettagli

COME SVILUPPARE UN EFFICACE PIANO DI INTERNET MARKETING

COME SVILUPPARE UN EFFICACE PIANO DI INTERNET MARKETING Febbraio Inserto di Missione Impresa dedicato allo sviluppo pratico di progetti finalizzati ad aumentare la competitività delle imprese. COME SVILUPPARE UN EFFICACE PIANO DI INTERNET MARKETING COS E UN

Dettagli

Sistemi Operativi IMPLEMENTAZIONE DEL FILE SYSTEM. D. Talia - UNICAL. Sistemi Operativi 9.1

Sistemi Operativi IMPLEMENTAZIONE DEL FILE SYSTEM. D. Talia - UNICAL. Sistemi Operativi 9.1 IMPLEMENTAZIONE DEL FILE SYSTEM 9.1 Implementazione del File System Struttura del File System Implementazione Implementazione delle Directory Metodi di Allocazione Gestione dello spazio libero Efficienza

Dettagli

Comunicazione tra Computer. Protocolli. Astrazione di Sottosistema di Comunicazione. Modello di un Sottosistema di Comunicazione

Comunicazione tra Computer. Protocolli. Astrazione di Sottosistema di Comunicazione. Modello di un Sottosistema di Comunicazione I semestre 04/05 Comunicazione tra Computer Protocolli Prof. Vincenzo Auletta auletta@dia.unisa.it http://www.dia.unisa.it/professori/auletta/ Università degli studi di Salerno Laurea in Informatica 1

Dettagli

MANUALE DI UTILIZZO: INTRANET PROVINCIA DI POTENZA

MANUALE DI UTILIZZO: INTRANET PROVINCIA DI POTENZA MANUALE DI UTILIZZO: INTRANET PROVINCIA DI POTENZA Fornitore: Publisys Prodotto: Intranet Provincia di Potenza http://www.provincia.potenza.it/intranet Indice 1. Introduzione... 3 2. I servizi dell Intranet...

Dettagli

Introduzione alle tecnologie informatiche. Strumenti mentali per il futuro

Introduzione alle tecnologie informatiche. Strumenti mentali per il futuro Introduzione alle tecnologie informatiche Strumenti mentali per il futuro Panoramica Affronteremo i seguenti argomenti. I vari tipi di computer e il loro uso Il funzionamento dei computer Il futuro delle

Dettagli

Esercizi su. Funzioni

Esercizi su. Funzioni Esercizi su Funzioni ๒ Varie Tracce extra Sul sito del corso ๓ Esercizi funz_max.cc funz_fattoriale.cc ๔ Documentazione Il codice va documentato (commentato) Leggibilità Riduzione degli errori Manutenibilità

Dettagli

Progettazione concettuale

Progettazione concettuale Progettazione concettuale Strategie top-down A partire da uno schema che descrive le specifiche mediante pochi concetti molto astratti, si produce uno schema concettuale mediante raffinamenti successivi

Dettagli

Corso di Amministrazione di Reti A.A. 2002/2003

Corso di Amministrazione di Reti A.A. 2002/2003 Struttura di Active Directory Corso di Amministrazione di Reti A.A. 2002/2003 Materiale preparato utilizzando dove possibile materiale AIPA http://www.aipa.it/attivita[2/formazione[6/corsi[2/materiali/reti%20di%20calcolatori/welcome.htm

Dettagli

Il software impiegato su un computer si distingue in: Sistema Operativo Compilatori per produrre programmi

Il software impiegato su un computer si distingue in: Sistema Operativo Compilatori per produrre programmi Il Software Il software impiegato su un computer si distingue in: Software di sistema Sistema Operativo Compilatori per produrre programmi Software applicativo Elaborazione testi Fogli elettronici Basi

Dettagli

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

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

Dettagli

Cos'è una vlan. Da Wikipedia: Una LAN virtuale, comunemente

Cos'è una vlan. Da Wikipedia: Una LAN virtuale, comunemente Cos'è una vlan Da Wikipedia: Una LAN virtuale, comunemente detta VLAN, è un gruppo di host che comunicano tra di loro come se fossero collegati allo stesso cablaggio, a prescindere dalla loro posizione

Dettagli

Il Sistema Operativo

Il Sistema Operativo Il Sistema Operativo Il Sistema Operativo Il Sistema Operativo (S.O.) è un insieme di programmi interagenti che consente agli utenti e ai programmi applicativi di utilizzare al meglio le risorse del Sistema

Dettagli

La Metodologia adottata nel Corso

La Metodologia adottata nel Corso La Metodologia adottata nel Corso 1 Mission Statement + Glossario + Lista Funzionalià 3 Descrizione 6 Funzionalità 2 Schema 4 Schema 5 concettuale Logico EA Relazionale Codice Transazioni In PL/SQL Schema

Dettagli

Più processori uguale più velocità?

Più processori uguale più velocità? Più processori uguale più velocità? e un processore impiega per eseguire un programma un tempo T, un sistema formato da P processori dello stesso tipo esegue lo stesso programma in un tempo TP T / P? In

Dettagli

e-dva - eni-depth Velocity Analysis

e-dva - eni-depth Velocity Analysis Lo scopo dell Analisi di Velocità di Migrazione (MVA) è quello di ottenere un modello della velocità nel sottosuolo che abbia dei tempi di riflessione compatibili con quelli osservati nei dati. Ciò significa

Dettagli

Condizioni di servizio per l'utente finale (applicazioni gratuite)

Condizioni di servizio per l'utente finale (applicazioni gratuite) Condizioni di servizio per l'utente finale (applicazioni gratuite) 1. Definizioni Ai fini delle disposizioni sotto indicate, le espressioni sono da intendere nei seguenti modi: "Applicazione" significa

Dettagli

Sistemi informativi secondo prospettive combinate

Sistemi informativi secondo prospettive combinate Sistemi informativi secondo prospettive combinate direz acquisti direz produz. direz vendite processo acquisti produzione vendite INTEGRAZIONE TRA PROSPETTIVE Informazioni e attività sono condivise da

Dettagli

ARCHITETTURA DI RETE FOLEGNANI ANDREA

ARCHITETTURA DI RETE FOLEGNANI ANDREA ARCHITETTURA DI RETE FOLEGNANI ANDREA INTRODUZIONE È denominata Architettura di rete un insieme di livelli e protocolli. Le reti sono organizzate gerarchicamente in livelli, ciascuno dei quali interagisce

Dettagli

Agenti Mobili Intelligenti e Sicurezza Informatica Utilizzare un nuovo paradigma applicativo per la realizzazione di sistemi informatici sicuri.

Agenti Mobili Intelligenti e Sicurezza Informatica Utilizzare un nuovo paradigma applicativo per la realizzazione di sistemi informatici sicuri. Agenti Mobili Intelligenti e Sicurezza Informatica Utilizzare un nuovo paradigma applicativo per la realizzazione di sistemi informatici sicuri. Roma, 25 ottobre 2010 Ing. Antonio Salomè Ing. Luca Lezzerini

Dettagli

Gestione della memoria. Paginazione Segmentazione Segmentazione con paginazione

Gestione della memoria. Paginazione Segmentazione Segmentazione con paginazione Gestione della memoria Paginazione Segmentazione Segmentazione con paginazione Modello di paginazione Il numero di pagina serve come indice per la tabella delle pagine. Questa contiene l indirizzo di base

Dettagli

Scenario di Progettazione

Scenario di Progettazione Appunti del 3 Ottobre 2008 Prof. Mario Bochicchio SCENARIO DI PROGETTAZIONE Scenario di Progettazione Il Committente mette a disposizione delle risorse e propone dei documenti che solitamente rappresentano

Dettagli

STRUTTURE DEI SISTEMI DI CALCOLO

STRUTTURE DEI SISTEMI DI CALCOLO STRUTTURE DEI SISTEMI DI CALCOLO 2.1 Strutture dei sistemi di calcolo Funzionamento Struttura dell I/O Struttura della memoria Gerarchia delle memorie Protezione Hardware Architettura di un generico sistema

Dettagli

Corso di Sistemi di Elaborazione delle informazioni

Corso di Sistemi di Elaborazione delle informazioni Corso di Sistemi di Elaborazione delle informazioni Sistemi Operativi Francesco Fontanella Complessità del Software Software applicativo Software di sistema Sistema Operativo Hardware 2 La struttura del

Dettagli

Strutturazione logica dei dati: i file

Strutturazione logica dei dati: i file Strutturazione logica dei dati: i file Informazioni più complesse possono essere composte a partire da informazioni elementari Esempio di una banca: supponiamo di voler mantenere all'interno di un computer

Dettagli

Dispositivi di rete. Ripetitori. Hub

Dispositivi di rete. Ripetitori. Hub Ripetitori Dispositivi di rete I ripetitori aumentano la distanza che può essere ragginta dai dispositivi Ethernet per trasmettere dati l'uno rispetto all'altro. Le distanze coperte dai cavi sono limitate

Dettagli

Definizione Parte del software che gestisce I programmi applicativi L interfaccia tra il calcolatore e i programmi applicativi Le funzionalità di base

Definizione Parte del software che gestisce I programmi applicativi L interfaccia tra il calcolatore e i programmi applicativi Le funzionalità di base Sistema operativo Definizione Parte del software che gestisce I programmi applicativi L interfaccia tra il calcolatore e i programmi applicativi Le funzionalità di base Architettura a strati di un calcolatore

Dettagli

www.andreatorinesi.it

www.andreatorinesi.it La lunghezza focale Lunghezza focale Si definisce lunghezza focale la distanza tra il centro ottico dell'obiettivo (a infinito ) e il piano su cui si forma l'immagine (nel caso del digitale, il sensore).

Dettagli

esales Forza Ordini per Abbigliamento

esales Forza Ordini per Abbigliamento esales Rel. 2012 Forza Ordini per Abbigliamento Scopo di questo documento è fornire la descrizione di una piattaforma di Raccolta Ordini via Web e la successiva loro elaborazione in ambiente ERP Aziendale.

Dettagli

Achab Learning & Presentation System Il progetto di Achab, per lo sviluppo e la pubblicazione di presentazioni e corsi di formazione online

Achab Learning & Presentation System Il progetto di Achab, per lo sviluppo e la pubblicazione di presentazioni e corsi di formazione online Achab Learning & Presentation System Il progetto di Achab, per lo sviluppo e la pubblicazione di presentazioni e corsi di formazione online Organizzare presentazioni e corsi online...2 Comunicare in modo

Dettagli

Hardware delle reti LAN

Hardware delle reti LAN Hardware delle reti LAN Le reti LAN utilizzano una struttura basata su cavi e concentratori che permette il trasferimento di informazioni. In un ottica di questo tipo, i computer che prendono parte allo

Dettagli

HR - Sicurezza. Parma 17/12/2015

HR - Sicurezza. Parma 17/12/2015 HR - Sicurezza Parma 17/12/2015 FG Software Produce software gestionale da più di 10 anni Opera nel mondo del software qualità da 15 anni Sviluppa i propri software con un motore completamente proprietario

Dettagli

Le fattispecie di riuso

Le fattispecie di riuso Le fattispecie di riuso Indice 1. PREMESSA...3 2. RIUSO IN CESSIONE SEMPLICE...4 3. RIUSO CON GESTIONE A CARICO DEL CEDENTE...5 4. RIUSO IN FACILITY MANAGEMENT...6 5. RIUSO IN ASP...7 1. Premessa Poiché

Dettagli

NUOVI APPROCCI PER UN MANAGER ALLENATORE : IL PROCESSO DI COACHING

NUOVI APPROCCI PER UN MANAGER ALLENATORE : IL PROCESSO DI COACHING gno Inserto di Missione Impresa dedicato allo sviluppo pratico di progetti finalizzati ad aumentare la competitività delle imprese. NUOVI APPROCCI PER UN MANAGER ALLENATORE : IL PROCESSO DI COACHING COSA

Dettagli

Progettaz. e sviluppo Data Base

Progettaz. e sviluppo Data Base Progettaz. e sviluppo Data Base! Progettazione Basi Dati: Metodologie e modelli!modello Entita -Relazione Progettazione Base Dati Introduzione alla Progettazione: Il ciclo di vita di un Sist. Informativo

Dettagli

CORSO ACCESS PARTE II. Esistono diversi tipi di aiuto forniti con Access, generalmente accessibili tramite la barra dei menu (?)

CORSO ACCESS PARTE II. Esistono diversi tipi di aiuto forniti con Access, generalmente accessibili tramite la barra dei menu (?) Ambiente Access La Guida di Access Esistono diversi tipi di aiuto forniti con Access, generalmente accessibili tramite la barra dei menu (?) Guida in linea Guida rapida Assistente di Office indicazioni

Dettagli

Progettaz. e sviluppo Data Base

Progettaz. e sviluppo Data Base Progettaz. e sviluppo Data Base! Introduzione ai Database! Tipologie di DB (gerarchici, reticolari, relazionali, oodb) Introduzione ai database Cos è un Database Cos e un Data Base Management System (DBMS)

Dettagli

Il Sistema Operativo (1)

Il Sistema Operativo (1) E il software fondamentale del computer, gestisce tutto il suo funzionamento e crea un interfaccia con l utente. Le sue funzioni principali sono: Il Sistema Operativo (1) La gestione dell unità centrale

Dettagli

SIMULAZIONE PROVA SCRITTA ESAME DI STATO. PER LA DISCIPLINA di SISTEMI

SIMULAZIONE PROVA SCRITTA ESAME DI STATO. PER LA DISCIPLINA di SISTEMI SIMULAZIONE PROVA SCRITTA ESAME DI STATO PER LA DISCIPLINA di SISTEMI L assessorato al turismo di una provincia di medie dimensioni vuole informatizzare la gestione delle prenotazioni degli alberghi associati.

Dettagli

INDIRIZZI IP ARCHITETTURA GENERALE DEGLI INDIRIZZI IP FORME DI INDIRIZZI IP CINQUE FORME DI INDIRIZZI IP

INDIRIZZI IP ARCHITETTURA GENERALE DEGLI INDIRIZZI IP FORME DI INDIRIZZI IP CINQUE FORME DI INDIRIZZI IP INDIRIZZI IP ARCHITETTURA GENERALE DEGLI INDIRIZZI IP Un indirizzo IP è composto da 32 bit. Generalmente, per convenienza, è presentato in decimale: 4 ottetti (bytes) separati da un punto. Ogni rete fisica

Dettagli

RETI DI COMPUTER Reti Geografiche. (Sez. 9.8)

RETI DI COMPUTER Reti Geografiche. (Sez. 9.8) RETI DI COMPUTER Reti Geografiche (Sez. 9.8) Riepilogo Reti lez precedente reti locali o LAN (Local Area Network): connette fisicamente apparecchiature su brevi distanze Una LAN è solitamente interna a

Dettagli

Creare una Rete Locale Lezione n. 1

Creare una Rete Locale Lezione n. 1 Le Reti Locali Introduzione Le Reti Locali indicate anche come LAN (Local Area Network), sono il punto d appoggio su cui si fonda la collaborazione nel lavoro in qualunque realtà, sia essa un azienda,

Dettagli

EXPLOit Content Management Data Base per documenti SGML/XML

EXPLOit Content Management Data Base per documenti SGML/XML EXPLOit Content Management Data Base per documenti SGML/XML Introduzione L applicazione EXPLOit gestisce i contenuti dei documenti strutturati in SGML o XML, utilizzando il prodotto Adobe FrameMaker per

Dettagli

Automazione Industriale (scheduling+mms) scheduling+mms. adacher@dia.uniroma3.it

Automazione Industriale (scheduling+mms) scheduling+mms. adacher@dia.uniroma3.it Automazione Industriale (scheduling+mms) scheduling+mms adacher@dia.uniroma3.it Introduzione Sistemi e Modelli Lo studio e l analisi di sistemi tramite una rappresentazione astratta o una sua formalizzazione

Dettagli

Appunti sulla Macchina di Turing. Macchina di Turing

Appunti sulla Macchina di Turing. Macchina di Turing Macchina di Turing Una macchina di Turing è costituita dai seguenti elementi (vedi fig. 1): a) una unità di memoria, detta memoria esterna, consistente in un nastro illimitato in entrambi i sensi e suddiviso

Dettagli