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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Dettagli

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

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

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

Contesto e motivazioni Architettura e concetti di base Componenti di RMI RMIRegistry Interfacce, eccezioni e classi Lo sviluppo di una applicazione L

Contesto e motivazioni Architettura e concetti di base Componenti di RMI RMIRegistry Interfacce, eccezioni e classi Lo sviluppo di una applicazione L CEFRIEL Consorzio per la Formazione e la Ricerca in Ingegneria dell Informazione Politecnico di Milano Programmazione Object Oriented in Java Java Remote Method Invocation Docente: Diego Peroni CEFRIEL

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

Remote Method Invocation (RMI)

Remote Method Invocation (RMI) (RMI) Remote Method Invocation (RMI) in Java. Walter Cazzola Dipartimento di Informatica e Comunicazione Università à degli Studi di Milano. e-mail: cazzola@disi disi.unige.it Walter Cazzola Java: Remote

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

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

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

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

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

LAVORI ESTIVI DI INFORMATICA PER LA CLASSE IV Sez. Ainf (Prof. Tessore Luca)

LAVORI ESTIVI DI INFORMATICA PER LA CLASSE IV Sez. Ainf (Prof. Tessore Luca) Ministero dell Istruzione, dell Università e della Ricerca Istituto Tecnico Industriale Statale Enrico Mattei Via Martiri di Cefalonia 46-20097 San Donato Milanese Tel. 0255691411 - Fax 025276676 itisando@tin.it

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

Sistemi Operativi. Rappresentazione e gestione delle attività e della computazione: processi e thread

Sistemi Operativi. Rappresentazione e gestione delle attività e della computazione: processi e thread Modulo di Sistemi Operativi per il corso di Master RISS: Ricerca e Innovazione nelle Scienze della Salute Unisa, 17-26 Luglio 2012 Sistemi Operativi Rappresentazione e gestione delle attività e della computazione:

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

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

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

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

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

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

Java RMI: Esempio Completo di un Applicazione Distribuita

Java RMI: Esempio Completo di un Applicazione Distribuita Java RMI: Esempio Completo di un Applicazione Distribuita Il Problema Produttore/Consumatore in Ambiente Distribuito* *a cura del Prof. L. Nigro, Università della Calabria Java RMI (Remote Method Invocation)

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

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

Un infrastruttura di supporto per servizi di file hosting

Un infrastruttura di supporto per servizi di file hosting Un infrastruttura di supporto per servizi di file hosting Università degli Studi di Bologna Laurea Specialistica in Ingegneria Informatica Reti di Calcolatori LS Prof. A. Corradi A.A. 2006/2007 Matteo

Dettagli

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

Corso di Reti di Calcolatori LS

Corso di Reti di Calcolatori LS Università degli Studi di Bologna Facoltà di Ingegneria Corso di Reti di Calcolatori LS CORBA - Implementazione Naming Service e Interface Repository Luca Foschini Anno accademico 2008/2009 Agenda CORBA

Dettagli

Programmazione di rete in Java

Programmazione di rete in Java Programmazione di rete in Java Reti di calcolatori Una rete di calcolatori è un sistema che permette la condivisione di dati informativi e risorse (sia hardware sia software) tra diversi calcolatori. Lo

Dettagli

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

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

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

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

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

Gestione delle Eccezioni

Gestione delle Eccezioni Gestione delle Eccezioni Condizioni di Errore Una condizione di errore in un programma può avere molte cause Errori di programmazione Divisione per zero, cast non permesso, accesso oltre i limiti di un

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

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

Sommario. Gestione dell I/O e Scheduling dei Dischi. Categorie di Dispositivi di I/O. Human readable

Sommario. Gestione dell I/O e Scheduling dei Dischi. Categorie di Dispositivi di I/O. Human readable Sommario Gestione dell I/O e Scheduling dei Dischi Dispositivi di I/O Organizzazione delle funzioni di I/O Problematiche di Progettazione I/O Buffering Disk Scheduling Categorie di Dispositivi di I/O Area

Dettagli

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

1. ABSTRACT 2. INTRODUZIONE PROGETTO DI UN INFRASTRUTTURA GERARCHICA PER SERVIZI DI FILE HOSTING PROGETTO DI UN INFRASTRUTTURA GERARCHICA PER SERVIZI DI FILE HOSTING 1. ABSTRACT Al giorno d oggi, l enorme diffusione di contenuti multimediali quali, ad esempio, video ad alta definizione piuttosto che

Dettagli

Java e Serializzazione dalla A all'xml di Leonardo Puleggi

Java e Serializzazione dalla A all'xml di Leonardo Puleggi dalla A all'xml di Leonardo Puleggi Indice generale Introduzione2 Grafo di Riferimenti 4 Attributi Transient.. 6 Metodi writeobject e readobject... 7 Ereditarietà e Serializzazione...10 Serializzazione

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

Java Virtual Machine

Java Virtual Machine Java Virtual Machine programmi sorgente: files.java compilatore files.class bytecode linker/loader bytecode bytecode Java API files.class interprete macchina ospite Indipendenza di java dalla macchina

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

Sistema Operativo Compilatore

Sistema Operativo Compilatore MASTER Information Technology Excellence Road (I.T.E.R.) Sistema Operativo Compilatore Maurizio Palesi Salvatore Serrano Master ITER Informatica di Base Maurizio Palesi, Salvatore Serrano 1 Il Sistema

Dettagli

Programmazione AA 2012 2013

Programmazione AA 2012 2013 Programmazione ad Oggetti AA 2012 2013 Contenuti del corso Modulo A Tecniche di programmazione Docente: Prof. Michele Bugliesi Modulo B Tecniche di progetto Docente: Prof. Alessandro Roncato Contenuti

Dettagli

Lezione n.2 20/2/2006

Lezione n.2 20/2/2006 Lezione n.2 LPR-Informatica Applicata Gestione indirizzi IP 20/2/2006 Gestione Indirizzi IP 1 Schema della Presentazione Gestione Indirizzi IP La classe JAVA. InetAddress Thread pooling Gestione Indirizzi

Dettagli

Evoluzione dei sistemi operativi (5) Evoluzione dei sistemi operativi (4) Classificazione dei sistemi operativi

Evoluzione dei sistemi operativi (5) Evoluzione dei sistemi operativi (4) Classificazione dei sistemi operativi Evoluzione dei sistemi operativi (4) Sistemi multiprogrammati! più programmi sono caricati in contemporaneamente, e l elaborazione passa periodicamente dall uno all altro Evoluzione dei sistemi operativi

Dettagli

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

Il costrutto monitor [Hoare 74]

Il costrutto monitor [Hoare 74] Il monitor 1 Il costrutto monitor [Hoare 74] Definizione: Costrutto sintattico che associa un insieme di operazioni (entry, o public) ad una struttura dati comune a più processi, tale che: Le operazioni

Dettagli

Sistemi Operativi. Processi GESTIONE DEI PROCESSI. Concetto di Processo. Scheduling di Processi. Operazioni su Processi. Processi Cooperanti

Sistemi Operativi. Processi GESTIONE DEI PROCESSI. Concetto di Processo. Scheduling di Processi. Operazioni su Processi. Processi Cooperanti GESTIONE DEI PROCESSI 4.1 Processi Concetto di Processo Scheduling di Processi Operazioni su Processi Processi Cooperanti Concetto di Thread Modelli Multithread I thread in diversi S.O. 4.2 Concetto di

Dettagli

Il Concetto di Processo

Il Concetto di Processo Processi e Thread Il Concetto di Processo Il processo è un programma in esecuzione. È l unità di esecuzione all interno del S.O. Solitamente, l esecuzione di un processo è sequenziale (le istruzioni vengono

Dettagli

Memorizzazione dei dati: Dischi e File

Memorizzazione dei dati: Dischi e File Memorizzazione dei dati: Dischi e File Query\update Query plan Execution Engine richieste di indici, record e file Index/file/record Manager comandi su pagine Query Compiler Buffer Manager Lettura/scrittura

Dettagli

Ereditarietà e classi astratte

Ereditarietà e classi astratte Ereditarietà e classi astratte 6 Temi del capitolo 1. Il concetto di ereditarietà 2. Programmazione grafica con ereditarietà 3. Classi astratte 4. Il pattern TEMPLATE METHOD 5. Interfacce protected 6.

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

Sistemi transazionali. sistemi transazionali 1

Sistemi transazionali. sistemi transazionali 1 Sistemi transazionali sistemi transazionali 1 Ricordiamo le principali caratteristiche dei DBMS condivisione dei dati - concorrenza qualità dei dati - integrità efficienza - caricamento, query, sort controllo

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

Realizzazione del file system

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

Dettagli

Eccezioni 1 CASO: SENTIRE E GESTIRE UN ALLARME. Prof. Enrico Denti Università di Bologna A.A. 2012/2013 1 SITUAZIONI CRITICHE IL CONCETTO DI ECCEZIONE

Eccezioni 1 CASO: SENTIRE E GESTIRE UN ALLARME. Prof. Enrico Denti Università di Bologna A.A. 2012/2013 1 SITUAZIONI CRITICHE IL CONCETTO DI ECCEZIONE Università degli Studi di Bologna Scuola di Ingegneria e Architettura Eccezioni Corso di Laurea in Ingegneria Informatica Anno accademico 2012/2013 Prof. ENRICO DENTI Dipartimento di Informatica Scienza

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

La velocità di una carovana

La velocità di una carovana Programmazione A.A. 2002-03 I linguaggio Java ( Lezione X, Parte I ) Il primo programma Prof. Giovanni Gallo Dr. Gianluca Cincotti Dipartimento di Matematica e Informatica Università di Catania e-mail

Dettagli

31/05/2013. Sistemi Web Distribuiti (parte 2) - Indice dei Contenuti - Naming. Corso Sistemi Distribuiti 6 cfu Docente: Prof. Marcello Castellano

31/05/2013. Sistemi Web Distribuiti (parte 2) - Indice dei Contenuti - Naming. Corso Sistemi Distribuiti 6 cfu Docente: Prof. Marcello Castellano Corso Sistemi Distribuiti 6 cfu Docente: Prof. Marcello Castellano /28 Sistemi Web Distribuiti (parte 2) - Indice dei Contenuti - Naming 3 Sincronizzazione 4 Consistenza e Replica 5 Replica di sistemi

Dettagli

Sistemi Operativi. ugoerr+so@dia.unisa.it 3 LEZIONE PROCESSI CORSO DI LAUREA TRIENNALE IN INFORMATICA. Sistemi Operativi 2007/08

Sistemi Operativi. ugoerr+so@dia.unisa.it 3 LEZIONE PROCESSI CORSO DI LAUREA TRIENNALE IN INFORMATICA. Sistemi Operativi 2007/08 Sistemi Operativi Docente: Ugo Erra ugoerr+so@dia.unisa.it 3 LEZIONE PROCESSI CORSO DI LAUREA TRIENNALE IN INFORMATICA UNIVERSITA DEGLI STUDI DELLA BASILICATA Sommario della lezione Concetto di processo

Dettagli

PROGETTO - Ingegneria del Software. Università degli Studi di Milano Polo di Crema. Corso di laurea in Scienze Matematiche, Fisiche e Naturali

PROGETTO - Ingegneria del Software. Università degli Studi di Milano Polo di Crema. Corso di laurea in Scienze Matematiche, Fisiche e Naturali Università degli Studi di Milano Polo di Crema Corso di laurea in Scienze Matematiche, Fisiche e Naturali INFORMATICA Corso di Ingegneria del Software progetto IL SISTEMA CALENDAR Presentato al dott. Paolo

Dettagli