Java Distribuited Computing Enviroment

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Java Distribuited Computing Enviroment"

Transcript

1 Reti di Calcolatori LS prof. Antonio Corradi a.a. 2003/2004 Relazione di Poggiali Antonio

2 Sommario Sommario... 2 Introduzione a JDCE... 3 Calcolo distribuito...3 Le componenti del sistema...4 Client...4 Customer... 4 Manager...5 Affidabilità rispetto alla caduta dei nodi...5 Deployment di una Computazione... 6 DataPool...6 Operation...7 ResultCollector...7 Ricircolo dei pacchetti... 8 ComputationInitializer... 8 Interazione fra le componenti... 8 Identificazione di client, customer e recupero degli oggetti remoti... 9 Il controllo dei permessi...9 Componenti attivi e passivi...10 Rilevazione dei guasti La replicazione del manager...10 Il manager...11 manager.iclient manager.icustomer Guasti a client e customer Il customer customer.imanager...13 customer.iclient Terminazione del customer Il client...15 client.imanager Conclusioni Computazione locale vs. distribuita Il prototipo del sistema e gli sviluppi futuri Politica di distribuzione della potenza di calcolo...17 Politica di distribuzione dei dati Comportamento del client

3 Introduzione a JDCE JDCE è un ambiente per lo sviluppo e l esecuzione di applicazioni di calcolo distribuito di tipo cooperativo. In JDCE le macchine che partecipano al calcolo offrendo le proprie risorse non sono note a priori ma vengono liberamente messe a disposizione (e liberamente tolte) dagli utenti delle macchine stesse. JDCE gestisce autonomamente la distribuzione della potenza di calcolo disponibile fra i vari richiedenti e gestisce le problematiche che nascono dall ambiente distribuito. JDCE offre al programmatore un sistema semplice, basato su interfacce ed ereditarietà, per strutturare e sviluppare le proprie applicazioni di calcolo e per mandarle in esecuzione. JDCE è sviluppato in Java ed utilizza RMI come middleware di comunicazione fra i vari componenti. Calcolo distribuito In JDCE un applicazione di calcolo viene chiamata computazione (computation) Una computazione consiste in una serie di pacchetti di dati: a ciascun viene applicata una operazione che lavora solo sui dati che questo contiene e restituisce un nuovo che contiene il risultato. JDCE distribuisce il calcolo affidando i vari pacchetti a calcolatori diversi e raccogliendo poi i risultati che questi producono: man mano che i risultati sono raccolti vengono presentati alla computazione.. sorgente di dati di dati di dati di dati di dati di dati di dati di dati di dati operazione operazione di risultati di risultati collettore dei risultati 3

4 Ogni computazione è quindi fisicamente articolata su una terna di elementi distinti che il programmatore deve sviluppare: la sorgente dei dati (data pool), l operazione da eseguire (operation) ed il collettore dei risultati (result collector). Le componenti del sistema Gli attori che partecipano al sistema JDCE sono di tre tipi: i client, i customer ed i(l) manager: i client sono gli attori che mettono a disposizione la loro capacità di elaborazione, i customer (committenti) sono gli attori che richiedono capacità di calcolo per eseguire una computazione, il manager è l attore che si occupa di gestire la capacità di calcolo disponibile (i client disponibili) fra le varie computazioni pervenute (i customer che hanno fatto richiesta); mentre client e customer sono molteplici per ogni ambiente JDCE in funzione c è un solo attore manager. Ogni attore consiste fisicamente in una macchina connessa alla rete su cui gira una applicazione che svolge determinate operazioni. su richiesta lega ad un customer Manager assegna/revoca client su richiesta invia operazione e pacchetti Client Customer invia risultati o notifica errori di calcolo Client L applicazione client di JDCE, brevemente, si iscrive (subscribe) ad un manager e chiede di essere legato (bind) ad un customer. Una volta legato il client richiede al customer che gli mandi il codice dell operazione, ed una volta ottenuto chiede un di dati su cui eseguirlo. Ogni volta che un viene elaborato il client comunica al customer il risultato e gli chiede un altro. Quando il customer ha concluso la propria elaborazione ne informa il client che ricomincia da capo chiedendo al manager di essere legato. L utente sulla macchina su cui l applicazione client esegue può decidere di terminarla in qualsiasi momento, in quel caso il client si cancella (unscribe) dal manager Customer L applicazione customer di JDCE richiede che le venga fornita una computazione (un applicazione di calcolo) da portare a termine. Il customer fa da ponte tra i client e la terna di componenti della computazione. Per prima cosa il customer si iscrive al manager (in 4

5 maniera simile al client) ed il manager, quando ne ha disponibili, gli assegna (grant) uno o più client con cui poter lavorare. Le assegnazioni sono temporanee, il manager potrebbe revocarle (revoke) in qualsiasi momento. Il customer serve solo le richieste che gli arrivano dai client che il manager gli ha assegnato. Quando la computazione è terminata il customer si cancella (unscribe) dal manager. I suoi compiti fondamentali nel portare avanti la computazione sono: gestire la perdita di pacchetti dovuti alla caduta dei client replicando le richieste, sterminare eventuali risultati duplicati e consegnare alla computazione i risultati in ordine, compensando le differenti velocità dei client. Manager L applicazione manager di JDCE si occupa di tenere traccia dei client e dei customer che si iscrivono, di rispondere alle richieste di legarsi dei client fornendogli un customer, di comunicare ai customer l assegnazione di client, di rispondere alle richieste di cancellazione di client, revocandoli al customer a cui sono assegnati, e rispondendo alle richieste di cancellazione dei customer. Il ruolo del manager nella architettura JDCE è fondamentale: è il manager che fa da broker fra i client ed i customer, è il manager che decide come distribuire la potenza di calcolo ed è sempre il manager che, nel caso di fallimenti di client o customer, si fa carico della gestione degli errori che ne risultano. Affidabilità rispetto alla caduta dei nodi Uno degli obiettivi di JDCE è fornire una infrastruttura solida a cui fare affidamento; il programmatore scrive il codice di una computazione e lo affida ad un customer per portarla a termine senza doversi preoccupare di cosa fanno i client o il manager. Per questo motivo il sistema, nel caso che il nodo manager cada, permette ai customer di continuare a lavorare con i client che gli erano stati assegnati dal manager prima che cadesse. In questo scenario la caduta del manager impedirà a nuovi attori (customer e client) di entrare nel sistema ed ai client che chiedono di essere legati di ottenere una risposta, uno scenario comunque da evitare. Per ovviare a questi problemi il sistema prevede la possibilità di replicare il manager su più nodi, pronti a subentrare in caso di fallimento del nodo principale. La caduta di un nodo customer porta alla perdita della computazione che stava portando a termine. La possibilità di replicare nodi customer è stata presa in considerazione ma scartata perché replicare le strutture del customer su macchine diverse sarebbe troppo onerosa in termini di trasferimento dei dati, ad esempio: se un customer sta gestendo una computazione che fa compressione video occorre copiare il video non compresso (la sorgente dei dati) ed il 5

6 video compresso (il risultato, man mano che viene calcolato) su tutti i nodi che replicano il customer, parliamo di gigabyte da trasferire! Deployment di una Computazione Una computazione è costituita da tre elementi: una sorgente di dati una operazione ed un collettore di risultati. Sviluppare una computazione per JDCE vuol dire scrivere uno o più moduli che implementano le interfacce di questi tre componenti. DataPool In JDCE è definita l interfaccia computation.datapool che descrive il comportamento che una sorgente di dati deve avere. Il customer sfrutta questi metodi per recuperare i pacchetti dai inviare ai clienti. Ogni deve essere identificato da un numero che lo caratterizza univocamente rispetto a tutti gli altri pacchetti del DataPool. package computation; public interface DataPool { } public Packet getnextpacket() throws NoMorePacketException; public Packet getpacket(int number) throws InexistingPacketException; public boolean haspacket(); public void inexistingpackethandler(); public void inexistingpackethandler(int number); La sorgente di dati è vista come un flusso sequenziale di pacchetti numerati in ordine crescente che possono essere recuperati con il metodo getnextpacket(); una volta terminata la sequenza dei pacchetti il metodo lancerà l eccezione NoMorePacketException. Il metodo haspacket() restituisce vero se la getnextpacket() ritorna un, falso altrimenti. La sorgente permette anche l accesso random ai pacchetti con il metodo getpacket(int number) in cui occorre specificare il numero del desiderato, se questo non esiste viene lanciata una eccezione InexistingPacketException. I due metodi inexistingpackethandler servono al customer per segnalare, prima di abortire la computazione, che la richiesta di un (sequenziale o random) che doveva essere completata correttamente ha lanciato un eccezione inaspettata; e quindi c è un errore nella logica del DataPool. 6

7 Operation In JDCE è definita la classe astratta computation.operation. package computation; import java.io.serializable; public abstract class Operation implements Serializable{ } public abstract Serializable compute(packet data); Java Distribuited Computing Enviroment Questa classe (e le sue figlie) descrivono le operazioni che i client eseguono sui pacchetti; è serializzabile perché deve venire trasferita ai client quando ne fanno richiesta. Invocando il metodo compute() si ottiene il risultato dell elaborazione sul passato come parametro, risultato che deve essere serializzabile per poter essere restituito al customer. Il client costruisce i pacchetti di risultati invocando il costruttore della classe ResultPacket e passandogli come argomenti un di dati e la classe Operation da utilizzare; il costruttore di ResultPacket garantisce che il risultato abbia lo stesso numero del di dati da cui è calcolato. ResultCollector In JDCE è definita l interfaccia computation.resultcollector che descrive il comportamento che un collettore dei risultati deve avere. Il customer sfrutta questi metodi per consegnare alla computazione i pacchetti di risultati inviati dai clienti. package computation; public interface ResultCollector { } public void commit(resultpacket result); public boolean hasfinished(); public void signalerror(int packetindex) throws AbortComputationException; Il metodo commit(resultpacket result) consegna il di risultati. Il metodo signalerror(int packetindex) indica che l elaborazione del con il numero packetindex ha causato un errore sul cliente (ad esempio una divisione per zero) e quindi non è disponibile alcun risultato. Se il metodo lancia l eccezione AbortComputationException richiede al customer di abortire la computazione. Il customer di JDCE consegna i risultati o notifica gli errori rigorosamente in ordine e senza duplicati. Il metodo hasfinished() deve restituire vero quando tutti i pacchetti della computazione sono stati consegnati (o hanno restituito errore) 7

8 Ricircolo dei pacchetti È possibile utilizzare i pacchetti di risultati che vengono restituiti dal customer per costruire nuovi pacchetti dati per il DataPool costruendo una elaborazione ciclica. Per il customer, salvo errori, la computazione ha termine quando il metodo hasfinished() restituisce vero. ComputationInitializer Per istruire il customer su quale DataPool, ResultCollector ed Operation impiegare e su come costruirsi gli oggetti JDCE definisce la classe computation.computationinitializer. package computation; public abstract class ComputationInitializer { public abstract DataPool getdatapool(); public abstract ResultCollector getresultcollector(); public abstract Operation getoperation(); public ComputationInitializer(String[] args) {} } Quando il customer viene avviato gli deve venire indicato il nome il nome di una sua classe figlia, il customer costruirà un oggetto invocando il costruttore e passandogli i restanti parametri della line di comando. Il costruttore dovrà costruire i tre oggetti DataPool ResultCollector ed Operation specifici della computazione che il customer andrà poi a recuperare con i restanti metodi. Interazione fra le componenti Le tre componenti fondamentali di JDCE, client, customer e manager, comunicano tra loro utilizzando RMI, ciascun componente definisce una interfaccia di comunicazione specifica per ciascuna delle altre due parti che devono comunicare con lui, ad esempio il manager definisce le due interfacce manager.icustomer e manager.iclient per poter essere invocato rispettivamente dai customer e dai client, il customer definisce le due interfacce customer.imanager e customer.iclient per poter essere invocato dal manager e dai client mentre il client espone la sola interfaccia client.imanager, 8

9 Manager IManager IManager IClient ICustomer Client Customer IClient I riferimento agli oggetti remoti che implementano le interfacce devono essere reperiti da un registro RMI; in JDCE viene fatta l ipotesi (forte) che il nodo che mantiene il registro non fallisce e quindi non ci sono politiche di recovery su registri secondari. La caduta del nodo registro impedirà a nuovi client e customer di reperire il manager, e quindi di iscriversi al servizio, e impedirà ai client di reperire i customer (customer.iclient) in seguito ad una bind, ma non impedirà ai customer di continuare a lavorare con i client che avevano assegnati. Identificazione di client, customer e recupero degli oggetti remoti La semantica di RMI non permette all oggetto remoto di risalire all identità di chi ne sta facendo uso invocando le sue funzioni. Per identificare i vari client ed i vari customer occorre un sistema per assegnare a ciascuno una identità: al momento di richiedere una operazione l identità del richiedente sarà fornita come parametro della funzione invocata. Il manager permette a client e customer di reperire nomi unici attraverso il metodo getvalidname(), definito nelle sue interfacce estendendo l interfaccia NameResolver, che restituisce un token. I token sono oggetti serializzabili da cui è possibile estrarre un nome con il metodo getname(). Il token serve anche ad identificare la stringa di bind e di lookup da inviare al registro RMI per iscriversi in modo che chiunque altro, una volta ricevuto il token sia in grado di recuperare un riferimento all oggetto remoto. Gli spazi dei nomi di manager, client e customer sono ulteriormente separati sul registro RMI: ogni componente quando si iscrive antepone al nome un prefisso standard (costanti di JDCE) che dipende della sua tipologia (client, customer, manager), prefisso che andrà utilizzato anche al momento del lookup. Il controllo dei permessi Qualsiasi operazione di client e customer sul manager, o di client sui customer, richiede che venga fornito un token che contiene l identità del chiamante. Se il chiamante non è autorizzato, per qualunque motivo, ad eseguire quella operazione verrà sollevata un eccezione InvalidPermissionException. Ad esempio, se un client chiede un di dati ad un customer occorre che il manager abbia concesso (grant) il permesso al customer, se il 9

10 customer non ha il permesso solleverà una InvalidPermissionException (che abbrevieremo con IPE) al client. Componenti attivi e passivi In JDCE le uniche componenti attive sono i client. Manager e customer, tranne quando si avviano e terminano, hanno un comportamento reattivo e lavorano per rispondere alle richieste dei client. Anche le comunicazioni fra di loro avvengono come conseguenza di richieste dei client. Manager e customer implementano le loro interfacce con metodi sincronizzati per evitare che richieste concorrenti di più client generino interferenze nell aggiornamento delle proprie strutture interne (di fatto serializzano le richieste dei client). Questo scenario introduce la possibilità di blocchi critici! Ad esempio: il client A accede al manager, e lo blocca, mentre il client B accede al customer FFT, e lo blocca; a questo punto se per completare l operazione richiesta da A il manager deve invocare un metodo del customer FFT e il customer per completare la richiesta di B deve invocare un metodo del manager siamo in deadlock! Per evitare blocchi critici il protocollo di comunicazione è strutturato in modo che i customer, tranne all inizio ed alla fine della loro vita, non comunichino con il manager; in questo modo eliminiamo la possibilità di deadlock. Rilevazione dei guasti Se un componente fallisce chi comunica con lui se ne accorge dall eccezione RemoteException che RMI lancia quando si invoca un metodo di un oggetto remoto scomparso. Gestendo la RemoteException è possibile implementare meccanismi di rilevazione e reazione ai guasti. In JDCE è definita l interfaccia remota Alive che definisce il metodo boolean alive() allo scopo di chiedere all oggetto remoto che implementa questa interfaccia se è vivo. La replicazione del manager JDCE per migliorare la propria disponibilità prevede che il nodo manager possa essere replicato da una o più copie passive; le copie possono essere aggiunte o rimosse dinamicamente durante l esecuzione. Fra le copie a disposizione del manager una viene eletta copia master ed è l unica che viene mantenuta aggiornata: se la copia master fallisce il manager ne sceglie una fra quelle del gruppo e la elegge a master trasmettendogli tutto lo stato, se il manager fallisce la copia master diventa il nuovo manager ed elegge una nuova copia master. Il manager espone alle copie una interfaccia che permette loro di entrare nel gruppo, di uscirne, e di chiedere al manager se è vivo (Alive). Le copie espongono una interfaccia che 10

11 permette al manager di mantenerle aggiornate sullo stato di client e customer. Durante il normale funzionamento del manager ad ogni operazione richiesta da parte di client e customer, prima di restituire i risultati al chiamante, il manager sincronizza la copia master trasmettendo le modifiche che l operazione ha generato nelle sue strutture dati. La copia master rimane in attesa aggiornando il proprio stato ed invocando periodicamente alive() sul manager per controllarne la sopravvivenza. Quando il manager fallisce i componenti client e customer se ne accorgono a causa della RemoteException che i metodi del defunto manager sollevano. Una volta rilevato il guasto i componenti client e customer eseguono un protocollo che consiste in un periodo di attesa seguito dall interrogazione del registro RMI per ottenere un nuovo riferimento al manager e nella ritrasmissione della richiesta fallita. Durante il tempo di attesa di client e customer la copia master accede al registro RMI e si registra al nome del vecchio manager in modo che gli altri componenti, appena attivi, possono reperirla ed utilizzarla come nuovo manager. Questo protocollo grazie all unica copia sincronizzata ed alla semplicità della gestione del gruppo risulta molto leggero ma è a rischio di fallimento se manager e copia master falliscono contemporaneamente; la possibilità che questo accada è comunque oggettivamente remota. Il manager Il manager ha due interfacce, una per i client ed una per i customer. Entrambe estendono l interfaccia NameResolver che definisce il metodo getvalidname() per il recupero di un token che contiene un nome unico nel sistema JDCE. Per brevità ometteremo da tutti i metodi di tutte le interfacce presentate le dichiarazioni di lancio della RemoteException. manager.iclient package manager; public interface IClient extends Remote, NameResolver { } public void subscribeclient (Token token) throws InvalidPermissionException; public void unscribeclient (Token client) throws InvalidPermissionException; public String bindclient (Token client) throws InvalidPermissionException; Il metodo subscribeclient permette ai client di iscriversi a JDCE fornendo un token di identità; il manager crea le strutture necessarie a tracciare il client, fra cui un riferimento remoto all oggetto. Se un altro client (o lo stesso client) si sono iscritti con lo stesso nome 11

12 (contenuto nel token) o se il manager non trova nel registry RMI un riferimento al client verrà lanciata l eccezione IPE. Il metodo unsubscribeclient elimina il client da JDCE. Se il client risultava legato ad un customer occorrerà informarlo con una revoca dell assegnamento. La IPE viene sollevata se il token contiene un nome inesistente. Il metodo bindclient fornisce al client il nome del customer a cui si deve legare. Il manager nelle sue strutture dati tiene traccia dello stato dei client etichettandoli come liberi o legati (e a chi sono legati). Il metodo bindclient provvede anche ad informare il customer a cui il client verrà legato (vedere l interfaccia customerimanager). Se un client che chiede di essere legato risulta già etichettato come legato ci sono tre diverse possibilità: il customer è fallito ed il client è tornato a chiedere una bind, il customer sta terminando ed ha liberato il client (vedi dopo), oppure il customer ha liberato il client perché al momento non ha pacchetti da affidargli. Il manager verifica cosa sia successo e prende le dovute contromisure. Se non ci sono customer il client viene sospeso, verrà risvegliato appena un customer si renderà disponibile. L eccezione IPE viene sollevata se il token contiene un nome inesistente. manager.icustomer package manager; public interface ICustomer extends Remote, NameResolver { } public void subscribecustomer (Token token) throws InvalidPermissionException; public void unscribecustomer (Token token) throws InvalidPermissionException; I metodi subscribecustomer ed unscribecustomer sono del tutto simili a quelli subscribe/unscribe dell interfaccia IClient, a differenza che lavorano con i customer. Quando un customer si iscrive il manager controlla se ci sono client sospesi sulla bind e li risveglia; quando si cancella il manager etichetta come liberi tutti i client che gli erano legati (NB al client non viene notificato niente). Più complessa è invece la terminazione dei customer: dal momento in cui la computazione termina al momento in cui viene invocata la unscribecustomer può passare diverso tempo. In questo lasso di tempo è facile che almeno un client che gli era legato torni a chiedere una bind al manager: in questo caso il customer viene cancellato d ufficio dal manager. Guasti a client e customer Il manager ha la responsabilità di rilevare i guasti di client e customer, in modo da eliminare dalle sue strutture registrazioni di componenti terminati che non hanno invocati i 12

13 metodi di cancellazione. Nel caso il manager si accorga di un guasto tenta anche di pulire il registro RMI eliminando la registrazione dell oggetto remoto del componente fallito; normalmente sono i componenti stessi a eliminare le proprie registrazioni sul registro RMI. A questo scopo le interfacce per il manager di client e customer estendono l interfaccia Alive ed il manager durante la normale esecuzione dei metodi esegue dei controlli per evitare zombi nelle sue strutture. Il customer Anche il customer ha due interfacce: una per il manager ed una per i client. customer.imanager package customer; public interface IManager extends Remote, Alive { } public void grantbind(token token) throws InvalidPermissionException; public void revokebind(token token) throws InvalidPermissionException; L interfaccia estende anche Alive ereditando il metodo alive(). Nel customer il metodo alive ha un ulteriore applicazione; restituendo falso informa il manager che la computazione è finita, quindi non ha più bisogno dei client, ma non ha ancora invocato il metodo unscribecustomer. Il metodo grantbind() informa il customer che il manager gli ha assegnato il client identificato dal token passato come parametro. L interruzione IPE viene sollevata se il client risultava già assegnato al customer. Il metodo revokebind() informa il customer che non ha più il permesso di utilizzare il client identificato dal token passato come parametro. L interruzione IPE viene sollevata se il client non risultava assegnato al customer. customer.iclient package customer; public interface IClient extends Remote { public Operation getcomputation(token token) throws InvalidPermissionException, NoMorePacketException; public Packet getpacket(token token) throws nvalidpermissionexception, NoMorePacketException; public void setcomputationresult(token token, ResultPacket result) throws InvalidPermissionException, NoMorePacketException; 13

14 } public void notifycomputationerror(token token, int packetindex) throws InvalidPermissionException, NoMorePacketException; L eccezione NoMorePacketException (che abbrevieremo con NMPE) viene lanciata da tutti i metodi dell interfaccia ed ha per tutti lo stesso significato: il customer al momento non ha più pacchetti da fare elaborare al client. Il client come risposta tornerà dal manager a chiedere di essere legato (bind). L eccezione InvalidPermisioneException (IPE) viene lanciata da tutti i metodi dell interfaccia quando il client non risulta assegnato al customer. Alcuni metodi possono lanciare la IPE anche in altre situazioni. Il metodo getcomputation una istanza della classe Operation specifica della computazione che il customer sta gestendo. L IPE può venire sollevata anche nel caso in cui al customer risulti che il client ha già ricevuto una volta l istanza di operation. Il metodo getpacket restituisce al client un di dati da elaborare, il customer nelle sue strutture dati tiene traccia di quali pacchetti ha affidato ai client. L IPE può venire sollevata anche quando il client ha già ricevuto un e non ha ancora consegnato i risultati e quando il client non ha scaricato la classe Operation. I metodi setcomputationresult e notifycomputationerror vengono invocati dai client per restituire i dati elaborati o per segnalare che c è stato un errore durante l elaborazione. L IPE può venire sollevata anche quando il client consegna risultati di un diverso da quello che gli era stato affidato (al limite il client non aveva alcun ) e quando il client non ha scaricato la classe Operation. Terminazione del customer Spieghiamo nei dettagli perché tra il momento in cui la computazione termina ed in momento in cui il customer invoca la unscribecustomer c è un certo tempo. Ogni volta che un o un errore di calcolo vengono consegnati al ResultCollector della computazione il customer verifica tramite il metodo hasfinished se la computazione è finita. A questo punto la cosa più logica sarebbe informare immediatamente il manager ed invocare la unscribecustomer ma per le considerazioni sui deadlock che abbiamo fatto è evidente che rischieremmo il blocco critico del customer e del manager! La soluzione che il customer adotta è quella di lanciare una nuova attività (thread) che si metterà in coda al manager (che serializza tutte le richieste) per invocare la unscribecustomer. 14

15 Il client Il client è l unico componente veramente attivo di JDCE, infatti sono i client con le loro richieste a far progredire le computazioni agendo sul manager e sui customer. Il client espone un unica interfaccia per il manager. client.imanager package client; public interface IManager extends Alive{ } L unica funzione dell interfaccia è permettere al manager di invocare alive() per controllare che il client non sia fallito. Conclusioni Computazione locale vs. distribuita Quando il modello di computazioni distribuita di JDCE può essere utilizzato per avere uno speed-up? Per capirlo occorre prima analizzare le prestazioni del modello di elaborazione locale in pipeline. Nel modello locale in pipeline un processo legge i pacchetti di dati e li passa ad un altro processo che li elabora e poi li passa ad un altro processo che li presenta all utente; tipicamente lettura e presentazione avvengono su disco. Quando i tempi di lettura/scrittura sono tali da rendere trascurabili i tempi di elaborazione la computazione si dice I/O bound. Sicuramente le computazioni I/O bound non sono efficienti per il calcolo distribuito: il punto critico è la lettura e la finalizzazione dei dati, la distribuzione dell elaborazione non elimina questi tempi, anzi introduce l overhead dei tempi di trasmissione. Per le computazioni CPU bound invece lo scenario cambia. Nel modello locale in pipeline se ci sono N pacchetti e ciascuno richiede un tempo T e di elaborazione il tempo complessivo di elaborazione sarà T e locale NT (i tempi di lettura e scrittura dei dati sono trascurabili perché minori di T e ). Distribuendo la computazione dobbiamo considerare i tempi T send e T receive per la trasmissione e la ricezione di un di dati. A differenza del modello locale che lavora in pipeline in JDCE non è possibile che un cliente ottenga un mentre ne sta elaborando un altro (sarebbe uno e 15

16 sviluppo futuro molto interessante però). Nella migliore delle ipotesi, senza ritrasmissioni, la sorgente deve trasferire via rete tutti i pacchetti e ricevere tutti i risultati con un tempo complessivo di T rete N ( Tsend Treceive a cui bisogna aggiungere il tempo che i client impiegano ad elaborare i pacchetti, approssimabile con T e jdce NTe # client sotto l ipotesi che il numero di client assegnati rimanga costante per tutta la computazione. Ponendo N T rete T T otteniamo e jdce NT e locale e ( Tsend Treceive ) NTe da cui si ricava T e ( T # client send ) Treceive)# client # client 1 che rappresenta la condizione minima (lower bound) sul tempo di elaborazione T e dei pacchetti che rende JDCE conveniente rispetto al modello locale in pipeline. Questa disuguaglianza per un numero di client elevato diventa T e ( Tsend Treceive In pratica per avere un miglioramento delle performance di una elaborazione utilizzando JDCE la condizione necessaria è che il tempo di elaborazione di un sia maggiore del tempo di trasmissione dei dati e dei risultati. Non è però detto che la relazione sia sufficiente: nel ricavarla non abbiamo considerato gli overhead che JDCE introduce per il coordinamento delle componenti. ) Il prototipo del sistema e gli sviluppi futuri A conclusione della fase di studio è stato realizzato un prototipo del sistema completo di tutte le componenti e provvisto di tutte le funzionalità tranne, per il momento, la replicazione del manager e la consegna in ordine dei pacchetti di risultati al ResultCollector. Il prototipo è composto da tre diversi programmi eseguibili, uno per ogni componente, dotati di interfaccia da linea di comando sviluppata con CLI (Command Line Interfaces, e capacità di log file degli output con due diversi livello di verbose. 16

17 Politica di distribuzione della potenza di calcolo A seconda della politica di distribuzione della potenza di calcolo disponibile che si decide di adottare si ottengono risultati diversi in termini di throughput (numero di customer completati), latenza (tempo di attesa per il completamento), parallelismo ed overhead di comunicazione. Il manager assume che tutti i client abbiano la stessa potenza di calcolo e la stessa banda: sotto queste ipotesi la potenza di calcolo assegnata ad un customer coincide con il numero di client assegnati. Una politica paritaria di ripartizione della potenza di calcolo cercherebbe di ripartire equamente i client fra i customer; quando un nuovo customer si iscrive il manager revoca alcuni client ai customer già iscritti e li assegna a quello nuovo. All altro estremo delle possibilità, passando per tutte le politiche basate su priorità (fissa, mobile, rotante, ecc.) c è la politica FIFO. La FIFO assegna tutta la potenza disponibile al primo customer che ne fa richiesta; quando questo termina tutti i client vengono assegnati al secondo e così via. Il vantaggio della politica FIFO rispetto a tutte le altre è che minimizza l overhead di comunicazione: una volta assegnati i client non vengono più revocati questo si traduce in un minor numero di chiamate ad oggetti remoti. Al momento il prototipo di JDCE che è stato realizzato utilizza una politica FIFO; sia per limitare l overhead di comunicazione, sia perché è facilmente implementabile. Per le prossime versioni del sistema sarà necessario uno studio formale dell efficienza delle varie politiche per scegliere la migliore o, ancora meglio, permettere all utente la scelta della politica di distribuzione della potenza di calcolo. Politica di distribuzione dei dati Il customer ha il compito di portare a termine la computazione di tutti i pacchetti di dati che il DataPool fornisce e di consegnare in ordine i risultati al ResultCollector. Nel prototipo che è stato implementato il customer si avvale di tre strutture: una lista dei pacchetti letti, una lista dei pacchetti ritornati ed una lista dei pacchetti in attesa di consegna; in verità le prime due strutture contengono solo i numeri dei pacchetti. Quando un viene letto in accesso sequenziale dal DataPool il suo numero viene inserito nella lista di quelli letti. Quando un client consegna un il suo numero viene tolto dalla lista di quelli letti ed inserito in quella dei consegnati, a meno che non fosse già nella lista dei consegnati, in questo caso viene scartato perché è un duplicato. I pacchetti consegnati dai client vengono restituiti al ResultCollector in sequenza, se un di risultati è fuori sequenza viene temporaneamente inserito nella lista dei pacchetti in attesa di consegna. Il metodo getpacket() tenta sempre un accesso sequenziale al DataPool; se questo 17

18 non è possibile estrae dalla lista dei pacchetti letti il numero più basso, accede in modo random al DataPool estraendo il con quel numero e lo restituisce al client. Questa politica di gestione è estremamente semplice (per non dire rozza) ma evita di utilizzare time-out per la scadenza della consegna ed evita di introdurre nella comunicazione client-customer chiamate al client per sapere se è ancora vivo (che implicherebbero chiamate al manager per informarlo della morte dei client); per contro introduce un certo grado di replicazione delle elaborazioni e delle trasmissioni e quindi uno spreco di risorse. E ovviamente necessario studiare una politica migliore per le prossime versioni del sistema. Comportamento del client Il client è un componente estremamente stupido. Il suo compito è unicamente quello di elaborare i dati, tutte le decisioni vengono prese dal manager e dai customer. Per prima cosa il client si inizializza recuperando un riferimento al manager, chiedendo un token di identità, iscrivendosi al registro RMI e poi iscrivendosi al manager. A questo punto il client chiede al manager di essere legato ad un customer; una volta ottenuto il nome recupera dal registro RMI un riferimento all oggetto remoto e scarica il codice della classe Operation della computazione. Una volta ottenuta la computazione il client chiede un di dati, lo computa e ritorna il risultato al customer (o segnala errore) e continua ad eseguire queste tre operazioni fino a che il customer non lo interrompe con una eccezione. Una volta interrotto il client ricomincia il ciclo chiedendo al manager di essere legato ad un customer e così via. Le politiche di distribuzione della potenza di calcolo e di distribuzione dei pacchetti implementate nel prototipo hanno caratterizzato in modo determinante il codice del client (ed in particolare il suo comportamento alle eccezioni); uno degli sviluppi futuri più importanti sarà quello di potenziare il client rendendo disponibili operazioni di controllo remoto da parte di manager e customer. 18

Java Remote Method Invocation

Java Remote Method Invocation Java Remote Method Invocation Programmazione in Rete e Laboratorio Comunicazione distribuita Port1 Java VM1 Java VM2 Port 2 Matteo Baldoni Dipartimento di Informatica Universita` degli Studi di Torino

Dettagli

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY

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

Dettagli

Sistemi Operativi (modulo di Informatica II)

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

Dettagli

Programmazione concorrente in Java. Dr. Paolo Casoto, Ph.D. - 2012 1

Programmazione concorrente in Java. Dr. Paolo Casoto, Ph.D. - 2012 1 + Programmazione concorrente in Java 1 + Introduzione al multithreading 2 La scomposizione in oggetti consente di separare un programma in sottosezioni indipendenti. Oggetto = metodi + attributi finalizzati

Dettagli

Laboratorio di Sistemi Distribuiti Leonardo Mariani

Laboratorio di Sistemi Distribuiti Leonardo Mariani Laboratorio di Sistemi Distribuiti Leonardo Mariani ELECTION ALGORITHMS In molti sistemi distribuiti un processo deve agire da (o svolgere un ruolo particolare) per gli altri processi. Spesso non è importante

Dettagli

Programmazione di sistemi distribuiti

Programmazione di sistemi distribuiti Programmazione di sistemi distribuiti I Sistemi Distribuiti, per loro natura, prevedono che computazioni differenti possano essere eseguite su VM differenti, possibilmente su host differenti, comunicanti

Dettagli

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

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

Dettagli

GESTIONE DEI PROCESSI

GESTIONE DEI PROCESSI Sistemi Operativi GESTIONE DEI PROCESSI Processi Concetto di Processo Scheduling di Processi Operazioni su Processi Processi Cooperanti Concetto di Thread Modelli Multithread I thread in Java Concetto

Dettagli

RMI Remote Method Invocation

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

Dettagli

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

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

Dettagli

Organizzazione della lezione. Lezione 18 Remote Method Invocation - 6. (con callback) L accesso al registry per il rebind()

Organizzazione della lezione. Lezione 18 Remote Method Invocation - 6. (con callback) L accesso al registry per il rebind() Organizzazione della lezione Lezione 18 Remote Method Invocation - 6 Vittorio Scarano Corso di Programmazione Distribuita (2003-2004) Laurea di I livello in Informatica Università degli Studi di Salerno

Dettagli

Registri RMI. Massimo Merro Univ. Verona Programmazione di Rete 90 / 247

Registri RMI. Massimo Merro Univ. Verona Programmazione di Rete 90 / 247 Registri RMI Per poter interagire con un server remoto, un client deve essere in possesso di una sua referenza remota (ovvero un oggetto stub). Un servizio di Naming è una risorsa centralizzata che può

Dettagli

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

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

Dettagli

UnicastRemoteObject. Massimo Merro Programmazione di Rete 103 / 124

UnicastRemoteObject. Massimo Merro Programmazione di Rete 103 / 124 UnicastRemoteObject Java RMI fornisce diverse classi base per definire server remoti: UnicastRemoteObject < RemoteServer < RemoteObject dove A < B significa che A è una sottoclasse di B. UnicastRemotObject

Dettagli

RMI. Java RMI RMI. G. Prencipe prencipe@di.unipi.it

RMI. Java RMI RMI. G. Prencipe prencipe@di.unipi.it Java Remote Method Invocation -- RMI G. Prencipe prencipe@di.unipi.it RMI RMI è una tecnologia JAVA che permette a una JVM di comunicare con un altra JVM per farle eseguire metodi È possibile che oggetti

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

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

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

Dettagli

12 - Introduzione alla Programmazione Orientata agli Oggetti (Object Oriented Programming OOP)

12 - Introduzione alla Programmazione Orientata agli Oggetti (Object Oriented Programming OOP) 12 - Introduzione alla Programmazione Orientata agli Oggetti (Object Oriented Programming OOP) Programmazione e analisi di dati Modulo A: Programmazione in Java Paolo Milazzo Dipartimento di Informatica,

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

CAPITOLO 27 SCAMBIO DI MESSAGGI

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

Dettagli

Esercitazione n 4. Obiettivi

Esercitazione n 4. Obiettivi Esercitazione n 4 Obiettivi Progettare e implementare per intero un componente software in Java Linguaggio Java: Classi astratte Utilizzo di costruttori e metodi di superclasse Polimorfismo Esempio guida:

Dettagli

Programmazione distribuita

Programmazione distribuita Programmazione distribuita 1 Architettura client-server È il modo classico di progettare applicazioni distribuite su rete Server offre un servizio "centralizzato" attende che altri (client) lo contattino

Dettagli

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

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

Dettagli

Un sistema operativo è un insieme di programmi che consentono ad un utente di

Un sistema operativo è un insieme di programmi che consentono ad un utente di INTRODUZIONE AI SISTEMI OPERATIVI 1 Alcune definizioni 1 Sistema dedicato: 1 Sistema batch o a lotti: 2 Sistemi time sharing: 2 Sistema multiprogrammato: 3 Processo e programma 3 Risorse: 3 Spazio degli

Dettagli

Sistemi Operativi (modulo di Informatica II) Sottosistema di I/O

Sistemi Operativi (modulo di Informatica II) Sottosistema di I/O Sistemi Operativi (modulo di Informatica II) Sottosistema di I/O Patrizia Scandurra Università degli Studi di Bergamo a.a. 2009-10 Sommario L hardware di I/O Struttura Interazione tra computer e controllori

Dettagli

Sistemi Operativi II Corso di Laurea in Ingegneria Informatica

Sistemi Operativi II Corso di Laurea in Ingegneria Informatica www.dis.uniroma1.it/~midlab Sistemi Operativi II Corso di Laurea in Ingegneria Informatica Prof. Roberto Baldoni Complementi: Buffer I/O Gestione dei buffer e I/O scheduling: 1. Richiami sulle tecniche

Dettagli

Informatica. Prof. A. Longheu. Introduzione ai Linguaggi Object-Oriented

Informatica. Prof. A. Longheu. Introduzione ai Linguaggi Object-Oriented Informatica Prof. A. Longheu Introduzione ai Linguaggi Object-Oriented 1 Generalità programmazione OO La programmazione ad oggetti è un particolare modo di scrivere il programma. Si prevede che: 1) si

Dettagli

Capitolo 5: I thread

Capitolo 5: I thread Capitolo 5: I thread Generalità. Modelli multithread. Problematiche relative ai thread. Pthread. 5.1 I thread Il thread è un flusso di controllo relativo ad un dato processo. Molti sistemi operativi moderni

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

Organizzazione della lezione. 15. Java Remote Method Invocation (3) Lo schema del Factory Design Pattern - 1. Factory design pattern

Organizzazione della lezione. 15. Java Remote Method Invocation (3) Lo schema del Factory Design Pattern - 1. Factory design pattern Organizzazione della lezione 15. Java Remote Method Invocation (3) Vittorio Scarano Corso di Programmazione Distribuita Laurea di I livello in Informatica Università degli Studi di Salerno Il design pattern

Dettagli

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2015-16. Pietro Frasca.

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2015-16. Pietro Frasca. Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2015-16 Pietro Frasca Lezione 15 Martedì 24-11-2015 Struttura logica del sottosistema di I/O Processi

Dettagli

SCP: SCHEDULER LAYER. a cura di. Alberto Boccato

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

Dettagli

Il bus PCI. Piccinetti Stefano

Il bus PCI. Piccinetti Stefano Il bus PCI Piccinetti Stefano Prima del bus PCI: il bus ISA Il bus più diffuso prima del 1992 era il bus ISA (quello sostanzialmente trattato a Reti Logiche). Il primo bus ISA era ad 8 bit e garantiva

Dettagli

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

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

Dettagli

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

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

Dettagli

Architetture Web. parte 1. Programmazione in Ambienti Distribuiti A.A. 2003-04

Architetture Web. parte 1. Programmazione in Ambienti Distribuiti A.A. 2003-04 Architetture Web parte 1 Programmazione in Ambienti Distribuiti A.A. 2003-04 Architetture Web (1) Modello a tre livelli in cui le interazioni tra livello presentazione e livello applicazione sono mediate

Dettagli

Applicazioni distribuite

Applicazioni distribuite Applicazioni distribuite Maurizio Cozzetto 1 agosto 2009 Un pò di teoria Ricordiamo che un'applicazione distribuita è un'applicazione composta da più programmi (almeno 2) posti in esecuzione su macchine

Dettagli

Programmazione a Oggetti Lezione 10. Ereditarieta

Programmazione a Oggetti Lezione 10. Ereditarieta Programmazione a Oggetti Lezione 10 Ereditarieta Sommario Come definire sottoclassi Costruttori Abstract Classes Final Ereditarietà: promemoria Strumento tipico dell OOP per riusare il codice e creare

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

Servers Activatable. Massimo Merro Programmazione di Rete 166 / 193

Servers Activatable. Massimo Merro Programmazione di Rete 166 / 193 Servers Activatable Nelle lezioni precedenti abbiamo detto che una referenza remota ad un server di tipo UnicastRemoteObject rimane valida finchè il server è in esecuzione. Quando il server termina, o

Dettagli

Caso di Studio: Avant Dernier

Caso di Studio: Avant Dernier Caso di Studio: Avant Dernier Specifiche: Nel gioco si affrontano 4 giocatori, ciascuno individuato con un numero progressivo (da 1 a 4). Inizialmente, i giocatori ricevono 5 carte ciascuno, e una carta

Dettagli

2. I THREAD. 2.1 Introduzione

2. I THREAD. 2.1 Introduzione 2. I THREAD 2.1 Introduzione Il tipo di parallelismo che è opportuno avere a disposizione nelle applicazioni varia in base al grado di cooperazione necessaria tra le diverse attività svolte in parallelo:

Dettagli

Socket & RMI Ingegneria del Software - San Pietro

Socket & RMI Ingegneria del Software - San Pietro Socket & RMI Ingegneria del Software - San Pietro Socket È possibile trattare la comunicazione di rete allo stesso modo con cui è possibile trattare la lettura da file. La classe Socket rappresenta la

Dettagli

Reti sequenziali e strutturazione firmware

Reti sequenziali e strutturazione firmware Architettura degli Elaboratori, a.a. 25-6 Reti sequenziali e strutturazione firmware Alla parte di corso sulle reti sequenziali è apportata una sensibile semplificazione rispetto a quanto contenuto nel

Dettagli

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

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

Dettagli

Esercitazione di Sistemi Distribuiti: Java RMI

Esercitazione di Sistemi Distribuiti: Java RMI Esercitazione di Sistemi Distribuiti: Java RMI Anno Accademico 2007-08 Marco Comerio comerio@disco.unimib.it Richiami Teorici Oggetti distribuiti 2-16 Usuale organizzazione di un oggetto remoto con un

Dettagli

Infrastrutture Software

Infrastrutture Software Infrastrutture Software I componenti fisici di un sistema informatico sono resi accessibili agli utenti attraverso un complesso di strumenti software finalizzati all utilizzo dell architettura. Si tratta

Dettagli

Synchronized (ancora)

Synchronized (ancora) Synchronized (ancora) Riscriviamo l esempio di prima. Usiamo una struttura modulare, con una classe Notificatore che ha opportuni metodi. La classe ha due campi privati, la lista buftext e un suo thread.

Dettagli

19. Introduzione al multi-threading

19. Introduzione al multi-threading 19. Introduzione al multi-threading Marco Faella Dip. Ing. Elettrica e Tecnologie dell'informazione Università di Napoli Federico II Corso di Linguaggi di Programmazione II I thread I thread, o processi

Dettagli

Corso di Informatica

Corso di Informatica Corso di Informatica Modulo T1 B2 Significato e proprietà della OOP 1 Prerequisiti Concetto ed elementi della comunicazione Allocazione e deallocazione della memoria Compilazione di un programma Spazio

Dettagli

IL LIVELLO DI LINEA O LIVELLO DI DATA LINK 1. Servizi offerti 2. Struttura dei pacchetti 3 CAMPO DATI 3. Character stuffing 4.

IL LIVELLO DI LINEA O LIVELLO DI DATA LINK 1. Servizi offerti 2. Struttura dei pacchetti 3 CAMPO DATI 3. Character stuffing 4. IL LIVELLO DI LINEA O LIVELLO DI DATA LINK 1 Servizi offerti 2 Struttura dei pacchetti 3 CAMPO DATI 3 Character stuffing 4 Bit stuffing 6 Protocolli di comunicazione 7 Protocolli di tipo simplex 8 Simplex

Dettagli

Supporto per servizi di File Hosting

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

Dettagli

Informatica 3. Informatica 3. LEZIONE 6: Il controllo dell esecuzione. Lezione 6 - Modulo 1. Errori durante l esecuzione. Il controllo dell esecuzione

Informatica 3. Informatica 3. LEZIONE 6: Il controllo dell esecuzione. Lezione 6 - Modulo 1. Errori durante l esecuzione. Il controllo dell esecuzione Informatica 3 Informatica 3 LEZIONE 6: Il controllo dell esecuzione Modulo 1: La gestione delle eccezioni Modulo 2: Programmazione concorrente Lezione 6 - Modulo 1 La gestione delle eccezioni Politecnico

Dettagli

QUEUE : considerazioni. QUEUE : considerazioni. QUEUE : esempio. QUEUE : esempio

QUEUE : considerazioni. QUEUE : considerazioni. QUEUE : esempio. QUEUE : esempio QUEUE : considerazioni QUEUE : considerazioni Si è realizzata una struttura dati complessa utilizzandone una primitiva, l array. Il pregio di tale implementazione è il basso costo computazionale, mentre

Dettagli

Protocolli di accesso multiplo

Protocolli di accesso multiplo Protocolli di accesso multiplo Quando l accesso ad una risorsa può avvenire da parte di più utenti indipendenti, si parla di risorsa condivisa ed è necessaria l implementazione di particolari protocolli

Dettagli

Il Sistema Operativo. Funzionalità. Sistema operativo. Sistema Operativo (Software di base)

Il Sistema Operativo. Funzionalità. Sistema operativo. Sistema Operativo (Software di base) Sistema Operativo (Software di base) Il Sistema Operativo Il sistema operativo è un insieme di programmi che opera sul livello macchina e offre funzionalità di alto livello Es.organizzazione dei dati attraverso

Dettagli

Telematica II 17. Esercitazione/Laboratorio 6

Telematica II 17. Esercitazione/Laboratorio 6 Multitasking e Multithreading Telematica II 17. Esercitazione/Laboratorio 6 Multitasking si riferisce all abilità di un computer di eseguire processi (jobs) multipli in maniera concorrente si ricorda che

Dettagli

7 Esercitazione (svolta): Callback. Polling. Java RMI: callback. Server. Server. Client. Client. due possibilità:

7 Esercitazione (svolta): Callback. Polling. Java RMI: callback. Server. Server. Client. Client. due possibilità: 7 Esercitazione (svolta): due possibilità: Java RMI: callback Molte applicazioni richiedono un meccanismo publish/subscribe I partecipanti (client) necessitano di notifiche da parte del coordinatore (server)

Dettagli

Specifica i tipi di oggetti a creare, utilizzando un istanza prototipo, e crea nuove istanze tramite la copia di questo prototipo.

Specifica i tipi di oggetti a creare, utilizzando un istanza prototipo, e crea nuove istanze tramite la copia di questo prototipo. Prototype 28 4. Prototype (GoF pag. 117) 4.1. Descrizione 4.2. Esempio Specifica i tipi di oggetti a creare, utilizzando un istanza prototipo, e crea nuove istanze tramite la copia di questo prototipo.

Dettagli

Negro Giulio Del Mutolo Nicola CORSO DI SISTEMI PER L ELABORAZIONE DELL INFORMAZIONE: GESTIONE DI RETE

Negro Giulio Del Mutolo Nicola CORSO DI SISTEMI PER L ELABORAZIONE DELL INFORMAZIONE: GESTIONE DI RETE Definizione di un'architettura client/server basata su SNMP per il monitoraggio del traffico che passa attraverso n router utilizzati per connettere un'azienda ad Internet. Negro Giulio Del Mutolo Nicola

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

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

Sincronizzazione distribuita: Mutua esclusione ed elezione

Sincronizzazione distribuita: Mutua esclusione ed elezione Sistemi Distribuiti Sincronizzazione distribuita: Mutua esclusione ed elezione 1 Mutua Esclusione (algoritmo centralizzato) a) Il Processo 1 chiede al coordinatore il permesso di entrare in una regione

Dettagli

Introduzione a Java Remote Method Invocation (RMI)

Introduzione a Java Remote Method Invocation (RMI) Introduzione a Java Remote Method Invocation (RMI) SAPIENZA Università di Roma Corso di Architetture Software Orientate ai Servizi E risuona il mio barbarico yawp sopra i tetti del mondo ( I sound my barbaric

Dettagli

Sistemi Operativi mod. B. Sistemi Operativi mod. B A B C A B C P 1 2 0 0 P 1 1 2 2 3 3 2 P 2 3 0 2 P 2 6 0 0 P 3 2 1 1 P 3 0 1 1 < P 1, >

Sistemi Operativi mod. B. Sistemi Operativi mod. B A B C A B C P 1 2 0 0 P 1 1 2 2 3 3 2 P 2 3 0 2 P 2 6 0 0 P 3 2 1 1 P 3 0 1 1 < P 1, > Algoritmo del banchiere Permette di gestire istanze multiple di una risorsa (a differenza dell algoritmo con grafo di allocazione risorse). Ciascun processo deve dichiarare a priori il massimo impiego

Dettagli

RMI. Prova pratica di Sistemi Distribuiti:

RMI. Prova pratica di Sistemi Distribuiti: Prova pratica di Sistemi Distribuiti: RMI Di Nicola Milella Al fine di toccare con mano queste tecnologie e capirne i rispettivi pro e contro si è deciso di sviluppare un applicazione distribuita sfruttando

Dettagli

Il sistema operativo

Il sistema operativo Il sistema operativo Percorso di Preparazione agli Studi di Ingegneria Università degli Studi di Brescia Docente: Massimiliano Giacomin Cos è un Sistema Operativo? Per capirlo, immaginiamo inizialmente

Dettagli

Introduzione. Java. Composizione. Esempio -- composizione. G. Prencipe prencipe@di.unipi.it. È qualcosa che abbiamo già visto varie volte

Introduzione. Java. Composizione. Esempio -- composizione. G. Prencipe prencipe@di.unipi.it. È qualcosa che abbiamo già visto varie volte Java riutilizzo delle classi G. Prencipe prencipe@di.unipi.it Introduzione Una delle caratteristiche fondamentali in Java è il riutilizzo del codice Ci sono due modi per ottenerlo Creare oggetti di classi

Dettagli

Relazione Progetto. Restaurant Manager. Corso: Programmazione ad oggetti Anno scolastico 2014/2015. Sara Sintoni Matteo Venditto

Relazione Progetto. Restaurant Manager. Corso: Programmazione ad oggetti Anno scolastico 2014/2015. Sara Sintoni Matteo Venditto Relazione Progetto Restaurant Manager Corso: Programmazione ad oggetti Anno scolastico 2014/2015 Autori: Daniele Rosetti Sara Sintoni Matteo Venditto Indice 1. Analisi 3 1.1 Requisiti... 3 1.2 Problema...

Dettagli

Input/Output in Java

Input/Output in Java Corso Java Input/Output in Java Docente: Dott. Marco Bianchi Slide realizzate da Ing. A.Bei, Dott. M.Bianchi, Dott. F.Lombardi Input/Output in Java Per effettuare operazioni di I/O in Java è possibile

Dettagli

Prodotto Matrice - Vettore in OpenMP

Prodotto Matrice - Vettore in OpenMP Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Elaborato di Calcolo Parallelo Prodotto Matrice - Vettore in OpenMP Anno Accademico 2011/2012 Professoressa Alessandra D Alessio Studenti

Dettagli

ARCHIVI E LORO ORGANIZZAZIONI

ARCHIVI E LORO ORGANIZZAZIONI ARCHIVI E LORO ORGANIZZAZIONI Archivio: - insieme di registrazioni (record), ciascuna costituita da un insieme prefissato di informazioni elementari dette attributi (campi) - insieme di informazioni relative

Dettagli

Realizzazione di Politiche di Gestione delle Risorse: i Semafori Privati

Realizzazione di Politiche di Gestione delle Risorse: i Semafori Privati Realizzazione di Politiche di Gestione delle Risorse: i Semafori Privati Condizione di sincronizzazione Qualora si voglia realizzare una determinata politica di gestione delle risorse,la decisione se ad

Dettagli

Parte II: Reti di calcolatori Lezione 10

Parte II: Reti di calcolatori Lezione 10 Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14 Pietro Frasca Parte II: Reti di calcolatori Lezione 10 Giovedì 3-04-2014 1 Reti per la distribuzione

Dettagli

Funzioni del Sistema Operativo

Funzioni del Sistema Operativo Il Software I componenti fisici del calcolatore (unità centrale e periferiche) costituiscono il cosiddetto Hardware (ferramenta). La struttura del calcolatore può essere schematizzata come una serie di

Dettagli

Sistemi Operativi. Lez. 13: primitive per la concorrenza monitor e messaggi

Sistemi Operativi. Lez. 13: primitive per la concorrenza monitor e messaggi Sistemi Operativi Lez. 13: primitive per la concorrenza monitor e messaggi Osservazioni I semafori sono strumenti particolarmente potenti poiché consentono di risolvere ogni problema di sincronizzazione

Dettagli

PC/CSA. Manuale di utilizzo del PC/CSA Specifiche tecniche per lo scarico automatico dei dati dei pagamenti delle violazioni al Codice della Strada

PC/CSA. Manuale di utilizzo del PC/CSA Specifiche tecniche per lo scarico automatico dei dati dei pagamenti delle violazioni al Codice della Strada PC/CSA Manuale di utilizzo del PC/CSA Specifiche tecniche per lo scarico automatico dei dati dei pagamenti delle violazioni al Codice della Strada PC/CSA-SPF-1.0 Versione del 18.04.2001 SOMMARIO 1 INTRODUZIONE

Dettagli

Introduzione a Classi e Oggetti

Introduzione a Classi e Oggetti Introduzione a Classi e Oggetti Oggetto: concetto astratto Entità di un programma dotata di tre proprietà caratteristiche stato informazioni conservate nell oggetto condizionano il comportamento dell oggetto

Dettagli

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

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

Dettagli

Soluzione dell esercizio del 2 Febbraio 2004

Soluzione dell esercizio del 2 Febbraio 2004 Soluzione dell esercizio del 2 Febbraio 2004 1. Casi d uso I casi d uso sono riportati in Figura 1. Figura 1: Diagramma dei casi d uso. E evidenziato un sotto caso di uso. 2. Modello concettuale Osserviamo

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

Java Server farm. M. Danelutto. Progetto conclusivo LPRb A.A. 2006-2007. Versione 1.0

Java Server farm. M. Danelutto. Progetto conclusivo LPRb A.A. 2006-2007. Versione 1.0 Java Server farm M. Danelutto Progetto conclusivo LPRb A.A. 2006-2007 Versione 1.0 1 Server farm Lo scopo del progetto é la realizzazione di un server farm (vedi la definizione di server farm di Wikipedia

Dettagli

F.O.A.M. Free Object Access Method. Un introduzione. Documento: Introduzione FOAM.doc Versione: 0.03.2k30131 Autore: Mario Meo Colombo

F.O.A.M. Free Object Access Method. Un introduzione. Documento: Introduzione FOAM.doc Versione: 0.03.2k30131 Autore: Mario Meo Colombo F.O.A.M. Free Object Access Method Un introduzione Documento: Introduzione FOAM.doc Versione: 0.03.2k30131 Autore: Mario Meo Colombo Il protocollo FOAM. FOAM (Free Object Access Method) è un protocollo

Dettagli

Nascita di Java. Che cos e Java? Caratteristiche di Java. Java: linguaggio a oggetti

Nascita di Java. Che cos e Java? Caratteristiche di Java. Java: linguaggio a oggetti Nascita di Java L uscita di Java, verso la metà degli anni novanta, fu accolta con molto entusiasmo dalla comunità dei programmatori e dei provider di servizi internet perché permetteva agli utenti del

Dettagli

Gli EJB offrono vari vantaggi allo sviluppatore di una applicazione

Gli EJB offrono vari vantaggi allo sviluppatore di una applicazione Gli EJB offrono vari vantaggi allo sviluppatore di una applicazione Un ambiente di esecuzione che gestisce o naming di oggetti, sicurezza, concorrenza, transazioni, persistenza, distribuzione oggetti (location

Dettagli

Input/Output. Moduli di Input/ Output. gestiscono quantità di dati differenti a velocità diverse in formati diversi. n Grande varietà di periferiche

Input/Output. Moduli di Input/ Output. gestiscono quantità di dati differenti a velocità diverse in formati diversi. n Grande varietà di periferiche Input/Output n Grande varietà di periferiche gestiscono quantità di dati differenti a velocità diverse in formati diversi n Tutti più lenti della CPU e della RAM n Necessità di avere moduli di I/O Moduli

Dettagli

Manuale di Integrazione IdM-RAS

Manuale di Integrazione IdM-RAS IdM-RAS Data: 30/11/09 File: Manuale di integrazione IdM-RAS.doc Versione: Redazione: Sardegna IT IdM-RAS Sommario 1 Introduzione... 3 2 Architettura del sistema... 4 2.1 Service Provider... 4 2.2 Local

Dettagli

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

Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2014-15. Pietro Frasca. Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2014-15 Pietro Frasca Lezione 5 Martedì 21-10-2014 Thread Come abbiamo detto, un processo è composto

Dettagli

Concetti Base Eccezioni Eccezioni e Metodi Gerarchia di Eccezioni. Java: Eccezioni. Damiano Macedonio

Concetti Base Eccezioni Eccezioni e Metodi Gerarchia di Eccezioni. Java: Eccezioni. Damiano Macedonio Dipartimento di Informatica, Università degli Studi di Verona Corso di Programmazione per Bioformatica lezione del 30 maggio 2014 Introduzione Un programma diviso in sezioni distinte Un approccio alla

Dettagli

Architettura di un computer

Architettura di un computer Architettura di un computer Modulo di Informatica Dott.sa Sara Zuppiroli A.A. 2012-2013 Modulo di Informatica () Architettura A.A. 2012-2013 1 / 36 La tecnologia Cerchiamo di capire alcuni concetti su

Dettagli

RMI: metodi equals e hashcode

RMI: metodi equals e hashcode RMI: metodi equals e hashcode Per verificare se due oggetti remoti contengono gli stessi dati, la chiamata indirizzata al metodo equals() avrebbe bisogno di contattare i server dove si trovano gli oggetti

Dettagli

Corso di Informatica

Corso di Informatica Corso di Informatica Modulo T3 1-Sottoprogrammi 1 Prerequisiti Tecnica top-down Programmazione elementare 2 1 Introduzione Lo scopo di questa Unità è utilizzare la metodologia di progettazione top-down

Dettagli

Corso di Informatica

Corso di Informatica CdLS in Odontoiatria e Protesi Dentarie Corso di Informatica Prof. Crescenzio Gallo crescenzio.gallo@unifg.it Funzioni dei Sistemi Operativi!2 Le funzioni principali del SO Gestire le risorse dell elaboratore

Dettagli

Metodologie di progetto Estensione di classi Implementazione di interfacce Composizione

Metodologie di progetto Estensione di classi Implementazione di interfacce Composizione Gerarchie di Tipi Metodologie di progetto Estensione di classi Implementazione di interfacce Composizione Notazione UML Relazione Simbolo Significato Ereditarietà Implementazione Aggregazione Dipendenza

Dettagli

Corsi di Reti di Calcolatori (Docente Luca Becchetti)

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

Dettagli

Tecnologia di un Database Server (centralizzato) Gestione del buffer

Tecnologia di un Database Server (centralizzato) Gestione del buffer Buffer Basi di Dati / Complementi di Basi di Dati 1 Tecnologia di un Database Server (centralizzato) Gestione del buffer Angelo Montanari Dipartimento di Matematica e Informatica Università di Udine Buffer

Dettagli

SISTEMI OPERATIVI. Deadlock (blocco critico) Domande di verifica. Luca Orrù Centro Multimediale Montiferru 04/06/2007

SISTEMI OPERATIVI. Deadlock (blocco critico) Domande di verifica. Luca Orrù Centro Multimediale Montiferru 04/06/2007 2007 SISTEMI OPERATIVI Deadlock (blocco critico) Domande di verifica Luca Orrù Centro Multimediale Montiferru 04/06/2007 Deadlock (blocco critico) 1. Si descriva il deadlock e le condizioni sotto cui si

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

Indice. settembre 2008 Il File System 2

Indice. settembre 2008 Il File System 2 Il File System Indice 4. Il File System 5. Vantaggi del FS 6. Protezione 7. Condivisione 8. I file - 1 9. I file - 2 10. Attributi dei file 11. Directory 12. Livelli di astrazione - 1 13. Livelli di astrazione

Dettagli

progam ponteasensounicoalaternato ; type dir = ( nord, sud );

progam ponteasensounicoalaternato ; type dir = ( nord, sud ); Esercizio di Sincronizzazione Tra Processi: Ponte a Senso Unico Alternato Un ponte contiene una sola csia di traffico consentendo così l'accesso a macchine provenienti da una sola direzione per volta,

Dettagli