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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Software che sovrintende al funzionamento del computer eseguendo compiti diversi:

Software che sovrintende al funzionamento del computer eseguendo compiti diversi: Sistema Operativo dispensa a cura di Alessandro Bellini Software che sovrintende al funzionamento del computer eseguendo compiti diversi: 1. Gestire interazione utente macchina 2. Fornire un interfaccia

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

Activation In sintesi: è inutile avere attivi degli oggetti se non vengono utilizzati

Activation In sintesi: è inutile avere attivi degli oggetti se non vengono utilizzati Activation In generale i Sistemi ad oggetti distribuiti sono progettati per lavorare con oggetti persistenti. Dato che questi sistemi saranno composti da migliaia (forse milioni) di tali oggetti, sarebbe

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

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

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

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

Dettagli

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

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

Dettagli

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

Music Everywhere with BT

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

Dettagli

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

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

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

Scope e visibilità per classi

Scope e visibilità per classi Scope e visibilità per classi Packages Classi interne nelle loro diverse forme Interne / statiche / locali Utilizzo congiunto con interfacce Implementazione di iteratori Gestione di eventi Packages Package:

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

T 1. Per un processo con più thread di controllo, lo stato di avanzamento della computazione di ogni thread è dato da:

T 1. Per un processo con più thread di controllo, lo stato di avanzamento della computazione di ogni thread è dato da: Un thread (o processo leggero) è una attività, descritta da una sequenza di istruzioni, che esegue all'interno del contesto di esecuzione di un programma. Un thread procede nella sua esecuzione per portare

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

20 - Input/Output su File

20 - Input/Output su File 20 - Input/Output su File Programmazione e analisi di dati Modulo A: Programmazione in Java Paolo Milazzo Dipartimento di Informatica, Università di Pisa http://www.di.unipi.it/ milazzo milazzo di.unipi.it

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

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

Sommario. G. Piscitelli

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

Dettagli

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

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

Dettagli

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

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

Design Pattern in Java

Design Pattern in Java Design Pattern in Java Claudio Di Ciccio, Massimiliano de Leoni (con la supervisione del docente Massimo Mecella) Università di Roma La Sapienza - Sede di Latina Corso di Progettazione del Software A.A.

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

Gestione dei thread in Java LSO 2008

Gestione dei thread in Java LSO 2008 Gestione dei thread in Java LSO 2008 Cos è un Thread? Si può avere la necessità di suddividere un programma in sottoattività separate da eseguire indipendentemente l una dall altra Queste sottoattività

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

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

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

Classificazione delle tecniche di accesso multiplo

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

Dettagli

Ottava Esercitazione. introduzione ai thread java mutua esclusione

Ottava Esercitazione. introduzione ai thread java mutua esclusione Ottava Esercitazione introduzione ai thread java mutua esclusione Agenda Esempio 1 Concorrenza in Java: creazione ed attivazione di thread concorrenti. Esercizio 2 da svolgere Concorrenza in Java: sincronizzazione

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

Architettura SW Definizione e Notazioni

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

Dettagli

Corsi di Reti di Calcolatori (Docente Luca Becchetti) Esercizi su strati di trasporto e di rete

Corsi di Reti di Calcolatori (Docente Luca Becchetti) Esercizi su strati di trasporto e di rete Corsi di Reti di Calcolatori (Docente Luca Becchetti) Esercizi su strati di trasporto e di rete 1. Si consideri un protocollo per il trasporto non affidabile di dati realtime. Il sender spedisce un pacchetto

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

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

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

Fondamenti di Informatica C Esercitazioni di Laboratorio / 3 http://polaris.ing.unimo.it/fic/laboratorio.html. Outline

Fondamenti di Informatica C Esercitazioni di Laboratorio / 3 http://polaris.ing.unimo.it/fic/laboratorio.html. Outline Fondamenti di Informatica C Esercitazioni di Laboratorio / 3 http://polaris.ing.unimo.it/fic/laboratorio.html Ing. Francesco De Mola demola.francesco@unimore.it DII, Modena Via Vignolese (lab. Dottorandi

Dettagli

Programmazione ad Oggetti Modulo A (Esame del 11/9/2015)

Programmazione ad Oggetti Modulo A (Esame del 11/9/2015) Programmazione ad Oggetti Modulo A (Esame del 11/9/2015) Esercizio 1 Considerate la seguente gerarchia di classi: class A { public void print(string s) { System.out.println(s); public void m1() { print("a.m1");

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

Sviluppo Applicazioni Mobile Lezione 11. Dr. Paolo Casoto, Ph.D - 2012

Sviluppo Applicazioni Mobile Lezione 11. Dr. Paolo Casoto, Ph.D - 2012 + Sviluppo Applicazioni Mobile Lezione 11 + Credits I lucidi di questa lezione sono stati preparati da: Professor Stefano Mizzaro Professor Paolo Coppola e sono stati modificati e completati dal Dr. Paolo

Dettagli

Parte II: Reti di calcolatori Lezione 12

Parte II: Reti di calcolatori Lezione 12 Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2014-15 Parte II: Reti di calcolatori Lezione 12 Giovedì 16-04-2015 1 Confronto architetture C/S e

Dettagli

Gioco dell Oca. 1 Descrizione. 2 Gioco dell Oca. Discussione di Febbraio e Aprile 2009

Gioco dell Oca. 1 Descrizione. 2 Gioco dell Oca. Discussione di Febbraio e Aprile 2009 Discussione di Febbraio e Aprile 2009 Gioco dell Oca Laurea Triennale in Comunicazione Digitale Laboratorio di Programmazione 1 Descrizione Il progetto consiste nell implementare in Java un applicazione

Dettagli

Gestione delle eccezioni in Java

Gestione delle eccezioni in Java Gestione delle eccezioni in Java - Introduzione al concetto di eccezioni E possibile definire un eccezione come un situazione imprevista che il flusso di un applicazione può incontrare. È possibile gestire

Dettagli

Comunicazione fra oggetti distribuiti

Comunicazione fra oggetti distribuiti Comunicazione fra oggetti distribuiti RMI RPC invocazione di metodo remoto - gli oggetti remoti ricevono le RMI interfaccia remota meccanismo per la comunicazione cliente servente come primitiva di un

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

Sincronizzazione e coordinamento nel distribuito

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

Dettagli

Compute engine generici in RMI

Compute engine generici in RMI Compute engine generici in RMI Esempio: Calcolo del prodotto scalare Un unico server offre il servizio di calcolo del prodotto scalare tra vettori di interi Un client richiede al server il calcolo del

Dettagli

ASPETTI PRINCIPALI DELLA GESTIONE AUTOMATIZZATA DI UN ARCHIVIO

ASPETTI PRINCIPALI DELLA GESTIONE AUTOMATIZZATA DI UN ARCHIVIO ARCHIVIO è un insieme di informazioni che hanno tra di loro un nesso logico (sono inerenti ad uno stesso argomento) e sono organizzate in modo tale da renderne facile la consultazione Le informazioni di

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

Ricorsione. Laboratorio di Programmazione II Corso di Laurea in Bioinformatica Dipartimento di Informatica - Università di Verona.

Ricorsione. Laboratorio di Programmazione II Corso di Laurea in Bioinformatica Dipartimento di Informatica - Università di Verona. Laboratorio di Programmazione II Corso di Laurea in Bioinformatica Dipartimento di Informatica - Università di Verona Sommario Implementazione di Utilizzo ricorsione per processare dati in java vs. multipla

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

Fondamenti di Informatica 1. Prof. B.Buttarazzi A.A. 2010/2011

Fondamenti di Informatica 1. Prof. B.Buttarazzi A.A. 2010/2011 Fondamenti di Informatica 1 Prof. B.Buttarazzi A.A. 2010/2011 Sommario Paradigma OO Incapsulamento Polimorfismo e Overloading Ereditarietà e Overriding Esercizi svolti Esercizi proposti Paradigma OO Le

Dettagli

Algoritmi di Ricerca. Esempi di programmi Java

Algoritmi di Ricerca. Esempi di programmi Java Fondamenti di Informatica Algoritmi di Ricerca Esempi di programmi Java Fondamenti di Informatica - D. Talia - UNICAL 1 Ricerca in una sequenza di elementi Data una sequenza di elementi, occorre verificare

Dettagli

Multithreading in Java. Fondamenti di Sistemi Informativi 2014-2015

Multithreading in Java. Fondamenti di Sistemi Informativi 2014-2015 Multithreading in Java Fondamenti di Sistemi Informativi 2014-2015 Multithreading La programmazione concorrente consente di eseguire più processi o thread nello stesso momento. Nel secondo caso si parla

Dettagli

UML Diagrammi delle classi. UML Diagramma classi 1

UML Diagrammi delle classi. UML Diagramma classi 1 UML Diagrammi delle classi UML Diagramma classi 1 Diagramma delle classi Non è nei nostri obiettivi affrontare UML nel suo complesso Ci concentreremo sui diagrammi delle classi che ci forniscono un linguaggio

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

ESAME DI FONDAMENTI DI INFORMATICA T-2 del 15/07/2015 Proff. E. Denti G. Zannoni Tempo a disposizione: 4 ore MAX

ESAME DI FONDAMENTI DI INFORMATICA T-2 del 15/07/2015 Proff. E. Denti G. Zannoni Tempo a disposizione: 4 ore MAX ESAME DI FONDAMENTI DI INFORMATICA T-2 del 15/07/2015 Proff. E. Denti G. Zannoni Tempo a disposizione: 4 ore MAX NB: il candidato troverà nell archivio ZIP scaricato da Esamix anche il software Start Kit

Dettagli

Processi e thread. Dipartimento di Informatica Università di Verona, Italy. Sommario

Processi e thread. Dipartimento di Informatica Università di Verona, Italy. Sommario Processi e thread Dipartimento di Informatica Università di Verona, Italy Sommario Concetto di processo Stati di un processo Operazioni e relazioni tra processi Concetto di thread Gestione dei processi

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

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

Traccia di soluzione dell esercizio del 25/1/2005

Traccia di soluzione dell esercizio del 25/1/2005 Traccia di soluzione dell esercizio del 25/1/2005 1 Casi d uso I casi d uso sono in Figura 1. Ci sono solo due attori: il Capo officina e il generico Meccanico. Figura 1: Diagramma dei casi d uso. 2 Modello

Dettagli

Esercitazione 2 di verifica

Esercitazione 2 di verifica Architettura degli Elaboratori, 27-8 Esercitazione 2 di verifica Soluzione: mercoledì 24 ottobre Una unità di elaborazione U è così definita: Domanda 1 i) possiede al suo interno due componenti logici

Dettagli

BrightSync: progetto di un middleware di sincronizzazione per ambienti eterogenei

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

Dettagli

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

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

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

Jav@Lab Il linguaggio Java I file sequenziali

Jav@Lab Il linguaggio Java I file sequenziali Jav@Lab Il linguaggio Java I file sequenziali Input e Output Secondo i canoni dei linguaggi di programmazione "procedurali" il concetto di input e output è strettamente legato al tipo di dispositivo esterno

Dettagli

13. Chain of Responsibility

13. Chain of Responsibility Chain of Responsibility 92 13. Chain of Responsibility (GoF pag. 223) 13.1. Descrizione Consente di separare il mittente di una richiesta dal destinario, in modo di consentire a più di un oggetto di gestire

Dettagli

Java threads (2) Programmazione Concorrente

Java threads (2) Programmazione Concorrente Java threads (2) emanuele lattanzi isti information science and technology institute 1/28 Programmazione Concorrente Utilizzo corretto dei thread in Java emanuele lattanzi isti information science and

Dettagli

appunti delle lezioni Architetture client/server: applicazioni server

appunti delle lezioni Architetture client/server: applicazioni server Sistemi informativi applicati (reti di calcolatori): appunti delle lezioni Architetture /: applicazioni 1 La logica dei Abbiamo visto che un applicazione si connette e comunica con un applicazione mediante

Dettagli

I tipi di dato astratti

I tipi di dato astratti I tipi di dato astratti.0 I tipi di dato astratti c Diego Calvanese Fondamenti di Informatica Corso di Laurea in Ingegneria Elettronica A.A. 001/00.0 0 I tipi di dato astratti La nozione di tipo di dato

Dettagli