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

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

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

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

Introduzione alle applicazioni di rete

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

Dettagli

Programmazione Java: Variabili membro, Metodi La parola chiave final

Programmazione Java: Variabili membro, Metodi La parola chiave final Programmazione Java: Variabili membro, Metodi La parola chiave final romina.eramo@univaq.it http://www.di.univaq.it/romina.eramo/tlp Roadmap Definire una classe» Variabili membro» Metodi La parola chiave

Dettagli

Middleware Laboratory. Dai sistemi concorrenti ai sistemi distribuiti

Middleware Laboratory. Dai sistemi concorrenti ai sistemi distribuiti Dai sistemi concorrenti ai sistemi distribuiti Problemi nei sistemi concorrenti e distribuiti I sistemi concorrenti e distribuiti hanno in comune l ovvio problema di coordinare le varie attività dei differenti

Dettagli

BPEL: Business Process Execution Language

BPEL: Business Process Execution Language Ingegneria dei processi aziendali BPEL: Business Process Execution Language Ghilardi Dario 753708 Manenti Andrea 755454 Docente: Prof. Ernesto Damiani BPEL - definizione Business Process Execution Language

Dettagli

Università di Torino Facoltà di Scienze MFN Corso di Studi in Informatica. Programmazione I - corso B a.a. 2009-10. prof.

Università di Torino Facoltà di Scienze MFN Corso di Studi in Informatica. Programmazione I - corso B a.a. 2009-10. prof. Università di Torino Facoltà di Scienze MFN Corso di Studi in Informatica Programmazione I - corso B a.a. 009-10 prof. Viviana Bono Blocco 9 Metodi statici: passaggio parametri, variabili locali, record

Dettagli

Introduzione alla Programmazione ad Oggetti in C++

Introduzione alla Programmazione ad Oggetti in C++ Introduzione alla Programmazione ad Oggetti in C++ Lezione 1 Cosa è la Programmazione Orientata agli Oggetti Metodologia per costruire prodotti software di grosse dimensioni che siano affidabili e facilmente

Dettagli

Oggetti Lezione 3. aspetti generali e definizione di classi I

Oggetti Lezione 3. aspetti generali e definizione di classi I Programmazione a Oggetti Lezione 3 Il linguaggio Java: aspetti generali e definizione di classi I Sommario Storia e Motivazioni Definizione di Classi Campi e Metodi Istanziazione di oggetti Introduzione

Dettagli

Inizializzazione degli Host. BOOTP e DHCP

Inizializzazione degli Host. BOOTP e DHCP BOOTP e DHCP a.a. 2002/03 Prof. Vincenzo Auletta auletta@dia.unisa.it http://www.dia.unisa.it/~auletta/ Università degli studi di Salerno Laurea e Diploma in Informatica 1 Inizializzazione degli Host Un

Dettagli

Abstract Data Type (ADT)

Abstract Data Type (ADT) Abstract Data Type Pag. 1/10 Abstract Data Type (ADT) Iniziamo la nostra trattazione presentando una nozione che ci accompagnerà lungo l intero corso di Laboratorio Algoritmi e Strutture Dati: il Tipo

Dettagli

Realizzazione di Politiche di Gestione delle Risorse: i Semafori Privati

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

Dettagli

La fase di realizzazione. La fase di realizzazione (cont.) Traduzione in Java del diagramma degli use case

La fase di realizzazione. La fase di realizzazione (cont.) Traduzione in Java del diagramma degli use case Università degli Studi di Roma La Sapienza Corso di Laurea in Ingegneria dell Informazione Sede di Latina Corso di Laurea in Ingegneria dell Informazione Consorzio Nettuno La fase di realizzazione si occupa

Dettagli

Processi di business sovra-regionali relativi ai sistemi regionali di FSE. Versione 1.0 24 Giugno 2014

Processi di business sovra-regionali relativi ai sistemi regionali di FSE. Versione 1.0 24 Giugno 2014 Processi di business sovra-regionali relativi ai sistemi regionali di FSE Versione 1.0 24 Giugno 2014 1 Indice Indice... 2 Indice delle figure... 3 Indice delle tabelle... 4 Obiettivi del documento...

Dettagli

I file di dati. Unità didattica D1 1

I file di dati. Unità didattica D1 1 I file di dati Unità didattica D1 1 1) I file sequenziali Utili per la memorizzazione di informazioni testuali Si tratta di strutture organizzate per righe e non per record Non sono adatte per grandi quantità

Dettagli

Le funzionalità di un DBMS

Le funzionalità di un DBMS Le funzionalità di un DBMS Sistemi Informativi L-A Home Page del corso: http://www-db.deis.unibo.it/courses/sil-a/ Versione elettronica: DBMS.pdf Sistemi Informativi L-A DBMS: principali funzionalità Le

Dettagli

VIRTUALIZE IT. www.digibyte.it - digibyte@digibyte.it

VIRTUALIZE IT. www.digibyte.it - digibyte@digibyte.it il server? virtualizzalo!! Se ti stai domandando: ma cosa stanno dicendo? ancora non sai che la virtualizzazione è una tecnologia software, oggi ormai consolidata, che sta progressivamente modificando

Dettagli

Linguaggi Corso M-Z - Laurea in Ingegneria Informatica A.A. 2007-2008. - lezione 14 - Thread in Java

Linguaggi Corso M-Z - Laurea in Ingegneria Informatica A.A. 2007-2008. - lezione 14 - Thread in Java Linguaggi Corso M-Z - Laurea in Ingegneria Informatica A.A. 2007-2008 Alessandro Longheu http://www.diit.unict.it/users/alongheu alessandro.longheu@diit.unict.it - lezione 14 - Thread in Java 1 Cos è un

Dettagli

Università degli Studi di Parma. Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica

Università degli Studi di Parma. Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica A.A. 2007-08 CORSO DI INGEGNERIA DEL SOFTWARE Prof. Giulio Destri http://www.areasp.com (C) 2007 AreaSP for

Dettagli

Corso di Amministrazione di Sistema Parte I ITIL 3

Corso di Amministrazione di Sistema Parte I ITIL 3 Corso di Amministrazione di Sistema Parte I ITIL 3 Francesco Clabot Responsabile erogazione servizi tecnici 1 francesco.clabot@netcom-srl.it Fondamenti di ITIL per la Gestione dei Servizi Informatici Il

Dettagli

Il modello client/server consente a due processi di condividere risorse e di cooperare per il raggiungimento di un obiettivo.

Il modello client/server consente a due processi di condividere risorse e di cooperare per il raggiungimento di un obiettivo. In una rete di ampie dimensioni, ciascuna sottorete (es. LAN, WAN) è connessa ad altre sottoreti tramite router. Internet è un insieme di reti connesse tra loro. Essenzialmente, in una rete alcune macchine

Dettagli

1 EJB e Portal Component Object http://desvino.altervista.org

1 EJB e Portal Component Object http://desvino.altervista.org 1 EJB e Portal Component Object http://desvino.altervista.org In questo tutorial studiamo come sfruttare la tecnologia EJB, Enterprise JavaBean, all interno del SAP Netweaver Portal. In breve, EJB è un

Dettagli

Progetto VirtualCED Clustered

Progetto VirtualCED Clustered Progetto VirtualCED Clustered Un passo indietro Il progetto VirtualCED, descritto in un precedente articolo 1, è ormai stato implementato con successo. Riassumendo brevemente, si tratta di un progetto

Dettagli

MODBUS-RTU per. Specifiche protocollo di comunicazione MODBUS-RTU per controllo in rete dispositivi serie. Expert NANO 2ZN

MODBUS-RTU per. Specifiche protocollo di comunicazione MODBUS-RTU per controllo in rete dispositivi serie. Expert NANO 2ZN per Expert NANO 2ZN Specifiche protocollo di comunicazione MODBUS-RTU per controllo in rete dispositivi serie Expert NANO 2ZN Nome documento: MODBUS-RTU_NANO_2ZN_01-12_ITA Software installato: NANO_2ZN.hex

Dettagli

Inter Process Communication. Laboratorio Software 2008-2009 C. Brandolese

Inter Process Communication. Laboratorio Software 2008-2009 C. Brandolese Inter Process Communication Laboratorio Software 2008-2009 C. Brandolese Introduzione Più processi o thread Concorrono alla relaizzazione di una funzione applicativa Devono poter realizzare Sincronizzazione

Dettagli

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

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

Dettagli

Modello OSI e architettura TCP/IP

Modello OSI e architettura TCP/IP Modello OSI e architettura TCP/IP Differenza tra modello e architettura - Modello: è puramente teorico, definisce relazioni e caratteristiche dei livelli ma non i protocolli effettivi - Architettura: è

Dettagli

MIB PER IL CONTROLLO DELLO STATO DI UN SERVER FTP

MIB PER IL CONTROLLO DELLO STATO DI UN SERVER FTP Università degli Studi di Pisa Facoltà di Scienze Matematiche,Fisiche e Naturali Corso di Laurea in Informatica Michela Chiucini MIB PER IL CONTROLLO DELLO STATO DI UN SERVER

Dettagli

ISTRUZIONI PER IL SERVIZIO SPCOOP - RICEZIONE

ISTRUZIONI PER IL SERVIZIO SPCOOP - RICEZIONE ISTRUZIONI PER IL SERVIZIO SPCOOP - RICEZIONE Pag. 1 di 14 INDICE 1. Glossario... 3 2. il servizio SPCoop - Ricezione... 5 3. Il web-service RicezioneFatture... 8 3.1 Operazione RiceviFatture... 9 3.1.1

Dettagli

Algebra di Boole: Concetti di base. Fondamenti di Informatica - D. Talia - UNICAL 1. Fondamenti di Informatica

Algebra di Boole: Concetti di base. Fondamenti di Informatica - D. Talia - UNICAL 1. Fondamenti di Informatica Fondamenti di Informatica Algebra di Boole: Concetti di base Fondamenti di Informatica - D. Talia - UNICAL 1 Algebra di Boole E un algebra basata su tre operazioni logiche OR AND NOT Ed operandi che possono

Dettagli

J+... J+3 J+2 J+1 K+1 K+2 K+3 K+...

J+... J+3 J+2 J+1 K+1 K+2 K+3 K+... Setup delle ConnessioniTCP Una connessione TCP viene instaurata con le seguenti fasi, che formano il Three-Way Handshake (perchè formato da almeno 3 pacchetti trasmessi): 1) il server si predispone ad

Dettagli

! Programmazione strutturata ! TDA. ! Classi, incapsulamento, ! OO. ! Scambio messaggi, eredità, polimorfismo. ! OO in Java

! Programmazione strutturata ! TDA. ! Classi, incapsulamento, ! OO. ! Scambio messaggi, eredità, polimorfismo. ! OO in Java Riassunto Rassegna API - 1 Stefano Mizzaro Dipartimento di matematica e informatica Università di Udine http://www.dimi.uniud.it/mizzaro/ mizzaro@uniud.it Programmazione, lezione 17 3 maggio 2015! Programmazione

Dettagli

Le variabili. Olga Scotti

Le variabili. Olga Scotti Le variabili Olga Scotti Cos è una variabile Le variabili, in un linguaggio di programmazione, sono dei contenitori. Possono essere riempiti con un valore che poi può essere riletto oppure sostituito.

Dettagli

PROBLEMA DELLA RICERCA DI UN ELEMENTO IN UN ARRAY E ALGORITMI RISOLUTIVI

PROBLEMA DELLA RICERCA DI UN ELEMENTO IN UN ARRAY E ALGORITMI RISOLUTIVI PROBLEMA DELLA RICERCA DI UN ELEMENTO IN UN ARRAY E ALGORITMI RISOLUTIVI PROBLEMA DELLA RICERCA in termini generali: Dati in input un insieme S di elementi (numeri, caratteri, stringhe, ) e un elemento

Dettagli

Inter-Process Communication

Inter-Process Communication Inter-Process Communication C. Baroglio a.a. 2002-2003 1 Introduzione In Unix i processi possono essere sincronizzati utilizzando strutture dati speciali, appartenti al pacchetto IPC (inter-process communication).

Dettagli

Classi ed Oggetti in JAVA

Classi ed Oggetti in JAVA Classi ed Oggetti in JAVA Dott. Ing. Leonardo Rigutini Dipartimento Ingegneria dell Informazione Università di Siena Via Roma 56 53100 SIENA Uff. 0577233606 rigutini@dii.unisi.it www.dii.unisi.it/~rigutini/

Dettagli

Risolvere un problema significa individuare un procedimento che permetta di arrivare al risultato partendo dai dati

Risolvere un problema significa individuare un procedimento che permetta di arrivare al risultato partendo dai dati Algoritmi Algoritmi Risolvere un problema significa individuare un procedimento che permetta di arrivare al risultato partendo dai dati Il procedimento (chiamato algoritmo) è composto da passi elementari

Dettagli

Universita' di Ferrara Dipartimento di Matematica e Informatica. Algoritmi e Strutture Dati. Rappresentazione concreta di insiemi e Hash table

Universita' di Ferrara Dipartimento di Matematica e Informatica. Algoritmi e Strutture Dati. Rappresentazione concreta di insiemi e Hash table Universita' di Ferrara Dipartimento di Matematica e Informatica Algoritmi e Strutture Dati Rappresentazione concreta di insiemi e Hash table Copyright 2006-2015 by Claudio Salati. Lez. 9a 1 Rappresentazione

Dettagli

Ambienti di sviluppo integrato

Ambienti di sviluppo integrato Ambienti di sviluppo integrato Un ambiente di sviluppo integrato (IDE - Integrated Development Environment) è un ambiente software che assiste i programmatori nello sviluppo di programmi Esso è normalmente

Dettagli

12.5 UDP (User Datagram Protocol)

12.5 UDP (User Datagram Protocol) CAPITOLO 12. SUITE DI PROTOCOLLI TCP/IP 88 12.5 UDP (User Datagram Protocol) L UDP (User Datagram Protocol) é uno dei due protocolli del livello di trasporto. Come l IP, é un protocollo inaffidabile, che

Dettagli

EQUAZIONI E DISEQUAZIONI POLINOMIALI E COLLEGAMENTI CON LA GEOMETRIA ELEMENTARE

EQUAZIONI E DISEQUAZIONI POLINOMIALI E COLLEGAMENTI CON LA GEOMETRIA ELEMENTARE EQUAZIONI E DISEQUAZIONI POLINOMIALI E COLLEGAMENTI CON LA GEOMETRIA ELEMENTARE 1. EQUAZIONI Definizione: un equazione è un uguaglianza tra due espressioni letterali (cioè in cui compaiono numeri, lettere

Dettagli

DI D AGRA R MM M I M A BLOCC C H C I TEORI R A E D D E SERC R I C ZI 1 1

DI D AGRA R MM M I M A BLOCC C H C I TEORI R A E D D E SERC R I C ZI 1 1 DIAGRAMMI A BLOCCHI TEORIA ED ESERCIZI 1 1 Il linguaggio dei diagrammi a blocchi è un possibile formalismo per la descrizione di algoritmi Il diagramma a blocchi, o flowchart, è una rappresentazione grafica

Dettagli

DNS (Domain Name System) Gruppo Linux

DNS (Domain Name System) Gruppo Linux DNS (Domain Name System) Gruppo Linux Luca Sozio Matteo Giordano Vincenzo Sgaramella Enrico Palmerini DNS (Domain Name System) Ci sono due modi per identificare un host nella rete: - Attraverso un hostname

Dettagli

Business Process Modeling and Notation e WebML

Business Process Modeling and Notation e WebML Business Process Modeling and Notation e WebML 24 Introduzione I Web Service e BPMN sono standard de facto per l interoperabilità in rete a servizio delle imprese moderne I Web Service sono utilizzati

Dettagli

esercizi Esercizi / problemi

esercizi Esercizi / problemi Sistemi informativi applicati (reti di calcolatori): esercizi 1 Esercizi / problemi 1. Creare un applicazione che calcoli la media aritmetica dei seguenti valori interi: 35, 117, 23 e ne visualizzi il

Dettagli

Introduzione. E un sistema EAI molto flessibile, semplice ed efficace:

Introduzione. E un sistema EAI molto flessibile, semplice ed efficace: Overview tecnica Introduzione E un sistema EAI molto flessibile, semplice ed efficace: Introduce un architettura ESB nella realtà del cliente Si basa su standard aperti Utilizza un qualsiasi Application

Dettagli

UML: Class Diagram. Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it

UML: Class Diagram. Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it UML: Class Diagram Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Università di Catania Class Diagram Forniscono una vista strutturale

Dettagli

Architettura dei Calcolatori

Architettura dei Calcolatori Architettura dei Calcolatori Sistema di memoria parte prima Ing. dell Automazione A.A. 2011/12 Gabriele Cecchetti Sistema di memoria parte prima Sommario: Banco di registri Generalità sulla memoria Tecnologie

Dettagli

Strutture. Strutture e Unioni. Definizione di strutture (2) Definizione di strutture (1)

Strutture. Strutture e Unioni. Definizione di strutture (2) Definizione di strutture (1) Strutture Strutture e Unioni DD cap.10 pp.379-391, 405-406 KP cap. 9 pp.361-379 Strutture Collezioni di variabili correlate (aggregati) sotto un unico nome Possono contenere variabili con diversi nomi

Dettagli

Intrusion Detection System

Intrusion Detection System Capitolo 12 Intrusion Detection System I meccanismi per la gestione degli attacchi si dividono fra: meccanismi di prevenzione; meccanismi di rilevazione; meccanismi di tolleranza (recovery). In questo

Dettagli

Rappresentazione dei numeri in un calcolatore

Rappresentazione dei numeri in un calcolatore Corso di Calcolatori Elettronici I A.A. 2010-2011 Rappresentazione dei numeri in un calcolatore Lezione 2 Università degli Studi di Napoli Federico II Facoltà di Ingegneria Rappresentazione dei numeri

Dettagli

Gli array. Gli array. Gli array. Classi di memorizzazione per array. Inizializzazione esplicita degli array. Array e puntatori

Gli array. Gli array. Gli array. Classi di memorizzazione per array. Inizializzazione esplicita degli array. Array e puntatori Gli array Array e puntatori Laboratorio di Informatica I un array è un insieme di elementi (valori) avente le seguenti caratteristiche: - un array è ordinato: agli elementi dell array è assegnato un ordine

Dettagli

PRESENTAZIONE DI UN SMS AL GATEWAY

PRESENTAZIONE DI UN SMS AL GATEWAY Interfaccia Full Ascii Con questa interfaccia è possibile inviare i dati al Server utilizzando solo caratteri Ascii rappresentabili e solo i valori che cambiano tra un sms e l altro, mantenendo la connessione

Dettagli

Il ciclo di vita del software

Il ciclo di vita del software Il ciclo di vita del software Il ciclo di vita del software Definisce un modello per il software, dalla sua concezione iniziale fino al suo sviluppo completo, al suo rilascio, alla sua successiva evoluzione,

Dettagli

Informatica Applicata

Informatica Applicata Ing. Irina Trubitsyna Concetti Introduttivi Programma del corso Obiettivi: Il corso di illustra i principi fondamentali della programmazione con riferimento al linguaggio C. In particolare privilegia gli

Dettagli

RAPPRESENTAZIONE BINARIA DEI NUMERI. Andrea Bobbio Anno Accademico 1996-1997

RAPPRESENTAZIONE BINARIA DEI NUMERI. Andrea Bobbio Anno Accademico 1996-1997 1 RAPPRESENTAZIONE BINARIA DEI NUMERI Andrea Bobbio Anno Accademico 1996-1997 Numeri Binari 2 Sistemi di Numerazione Il valore di un numero può essere espresso con diverse rappresentazioni. non posizionali:

Dettagli

CORSO DI ALGORITMI E PROGRAMMAZIONE. JDBC Java DataBase Connectivity

CORSO DI ALGORITMI E PROGRAMMAZIONE. JDBC Java DataBase Connectivity CORSO DI ALGORITMI E PROGRAMMAZIONE JDBC Java DataBase Connectivity Anno Accademico 2002-2003 Accesso remoto al DB Istruzioni SQL Rete DataBase Utente Host client Server di DataBase Host server Accesso

Dettagli

Trasmissione Seriale e Parallela. Interfacce di Comunicazione. Esempio di Decodifica del Segnale. Ricezione e Decodifica. Prof.

Trasmissione Seriale e Parallela. Interfacce di Comunicazione. Esempio di Decodifica del Segnale. Ricezione e Decodifica. Prof. Interfacce di Comunicazione Università degli studi di Salerno Laurea in Informatica I semestre 03/04 Prof. Vincenzo Auletta auletta@dia.unisa.it http://www.dia.unisa.it/professori/auletta/ 2 Trasmissione

Dettagli

AA 2006-07 LA RICORSIONE

AA 2006-07 LA RICORSIONE PROGRAMMAZIONE AA 2006-07 LA RICORSIONE AA 2006-07 Prof.ssa A. Lanza - DIB 1/18 LA RICORSIONE Il concetto di ricorsione nasce dalla matematica Una funzione matematica è definita ricorsivamente quando nella

Dettagli

END-TO-END SERVICE QUALITY. LA CULTURA DELLA QUALITÀ DAL CONTROLLO DELLE RISORSE ALLA SODDISFAZIONE DEL CLIENTE

END-TO-END SERVICE QUALITY. LA CULTURA DELLA QUALITÀ DAL CONTROLLO DELLE RISORSE ALLA SODDISFAZIONE DEL CLIENTE END-TO-END SERVICE QUALITY. LA CULTURA DELLA QUALITÀ DAL CONTROLLO DELLE RISORSE ALLA SODDISFAZIONE In un mercato delle Telecomunicazioni sempre più orientato alla riduzione delle tariffe e dei costi di

Dettagli

Guida ai Servizi Voce per il Referente. Guida ai Servizi Voce per il Referente

Guida ai Servizi Voce per il Referente. Guida ai Servizi Voce per il Referente Guida ai Servizi Voce per il Referente Guida ai Servizi Voce per il Referente 1 Sommario 1 Introduzione... 3 1.1 Accesso al Self Care Web di Rete Unica... 4 2 Servizi Aziendali... 6 2.1 Centralino - Numero

Dettagli

AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Unified Process. Prof. Agostino Poggi

AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Unified Process. Prof. Agostino Poggi AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma Unified Process Prof. Agostino Poggi Unified Process Unified Software Development Process (USDP), comunemente chiamato

Dettagli

/** * VETTORE DINAMICO elementi */ private Vector elementi; /** * METODO COSTRUTTORE */ public coda() { elementi=new Vector(); }

/** * VETTORE DINAMICO elementi */ private Vector elementi; /** * METODO COSTRUTTORE */ public coda() { elementi=new Vector(); } import java.util.*; class coda * Questa classe contiene tutti i metodi per la gestione della coda * @author D'Ambrosio Giovanni Classe 4D I.T.I.S. Grottaminarda * @version 26/02/2010 * VETTORE DINAMICO

Dettagli

METODO DELLE FORZE 1. METODO DELLE FORZE PER LA SOLUZIONE DI STRUTTURE IPERSTATICHE. 1.1 Introduzione

METODO DELLE FORZE 1. METODO DELLE FORZE PER LA SOLUZIONE DI STRUTTURE IPERSTATICHE. 1.1 Introduzione METODO DELLE FORZE CORSO DI PROGETTZIONE STRUTTURLE a.a. 010/011 Prof. G. Salerno ppunti elaborati da rch. C. Provenzano 1. METODO DELLE FORZE PER L SOLUZIONE DI STRUTTURE IPERSTTICHE 1.1 Introduzione

Dettagli

Elementi di UML (7): Diagrammi dei componenti e di deployment

Elementi di UML (7): Diagrammi dei componenti e di deployment Elementi di UML (7): Diagrammi dei componenti e di deployment Università degli Studi di Bologna Facoltà di Scienze MM. FF. NN. Corso di Laurea in Scienze di Internet Anno Accademico 2004-2005 Laboratorio

Dettagli

Ricerca Operativa Branch-and-Bound per problemi di Programmazione Lineare Intera

Ricerca Operativa Branch-and-Bound per problemi di Programmazione Lineare Intera Ricerca Operativa Branch-and-Bound per problemi di Programmazione Lineare Intera L. De Giovanni AVVERTENZA: le note presentate di seguito non hanno alcuna pretesa di completezza, né hanno lo scopo di sostituirsi

Dettagli

Le funzioni. Funzioni. Funzioni. Funzioni. Funzioni. Funzioni

Le funzioni. Funzioni. Funzioni. Funzioni. Funzioni. Funzioni Funzioni Le funzioni Con il termine funzione si intende, in generale, un operatore che, applicato a un insieme di operandi, consente di calcolare un risultato, come avviene anche per una funzione matematica

Dettagli

SOFTWARE GESTIONE SMS DA INTERFACCE CL MANUALE D INSTALLAZIONE ED USO

SOFTWARE GESTIONE SMS DA INTERFACCE CL MANUALE D INSTALLAZIONE ED USO CLSMS SOFTWARE GESTIONE SMS DA INTERFACCE CL MANUALE D INSTALLAZIONE ED USO Sommario e introduzione CLSMS SOMMARIO INSTALLAZIONE E CONFIGURAZIONE... 3 Parametri di configurazione... 4 Attivazione Software...

Dettagli

CHE COS È DOCFLY FATTURAZIONE PA... 3 1.1 IL GESTIONALE WEB... 3 1.2 ACCESSO ALL INTERFACCIA WEB... 4 1.3 FUNZIONALITÀ DELL INTERFACCIA WEB...

CHE COS È DOCFLY FATTURAZIONE PA... 3 1.1 IL GESTIONALE WEB... 3 1.2 ACCESSO ALL INTERFACCIA WEB... 4 1.3 FUNZIONALITÀ DELL INTERFACCIA WEB... 1. CHE COS È DOCFLY FATTURAZIONE PA... 3 1.1 IL GESTIONALE WEB... 3 1.2 ACCESSO ALL INTERFACCIA WEB... 4 1.3 FUNZIONALITÀ DELL INTERFACCIA WEB... 5 1.3.1 CREAZIONE GUIDATA DELLA FATTURA IN FORMATO XML

Dettagli

Corso di Informatica Generale (C. L. Economia e Commercio) Ing. Valerio Lacagnina Rappresentazione in virgola mobile

Corso di Informatica Generale (C. L. Economia e Commercio) Ing. Valerio Lacagnina Rappresentazione in virgola mobile Problemi connessi all utilizzo di un numero di bit limitato Abbiamo visto quali sono i vantaggi dell utilizzo della rappresentazione in complemento alla base: corrispondenza biunivoca fra rappresentazione

Dettagli

Il mio ricorso alla CEDU: Come presentarlo e in che modo lo stesso viene gestito

Il mio ricorso alla CEDU: Come presentarlo e in che modo lo stesso viene gestito Il mio ricorso alla CEDU: Come presentarlo e in che modo lo stesso viene gestito La Corte dichiara inammissibili la maggior parte dei ricorsi senza esaminarli nel merito, a causa del mancato rispetto dei

Dettagli

Minimizzazione di Reti Logiche Combinatorie Multi-livello

Minimizzazione di Reti Logiche Combinatorie Multi-livello Minimizzazione di Reti Logiche Combinatorie Multi-livello Maurizio Palesi Maurizio Palesi 1 Introduzione Obiettivo della sintesi logica: ottimizzazione delle cifre di merito area e prestazioni Prestazioni:

Dettagli

PRONTUARIO. DELLE PRINCIPALI NOVITA IN MATERIA DI PROCEDIMENTI E TERMINI PROCESSUALI (ad uso delle segreterie)

PRONTUARIO. DELLE PRINCIPALI NOVITA IN MATERIA DI PROCEDIMENTI E TERMINI PROCESSUALI (ad uso delle segreterie) Codice del processo amministrativo - Commissione per l esame dei profili organizzativi ed informatici - PRONTUARIO DELLE PRINCIPALI NOVITA IN MATERIA DI PROCEDIMENTI E TERMINI PROCESSUALI (ad uso delle

Dettagli

R.Focardi Laboratorio di Ingegneria del Software 6. 1

R.Focardi Laboratorio di Ingegneria del Software 6. 1 Networking Java permette comunicazioni in rete basate sul concetto di socket, che permette di vedere la comunicazione in termini di flusso (stream), in modo analogo all input-output di file, usando Stream

Dettagli

Analisi dei requisiti e casi d uso

Analisi dei requisiti e casi d uso Analisi dei requisiti e casi d uso Indice 1 Introduzione 2 1.1 Terminologia........................... 2 2 Modello del sistema 4 2.1 Requisiti hardware........................ 4 2.2 Requisiti software.........................

Dettagli

UML Component and Deployment diagram

UML Component and Deployment diagram UML Component and Deployment diagram Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Università di Catania I diagrammi UML Classificazione

Dettagli

Nuova disciplina sanzionatoria degli assegni bancari

Nuova disciplina sanzionatoria degli assegni bancari Legge 15 dicembre 1990, n. 386, come modificata dal Decreto Legislativo 30 dicembre 1999, n. 507. Nuova disciplina sanzionatoria degli assegni bancari Art. 1. Emissione di assegno senza autorizzazione

Dettagli

Consideriamo due polinomi

Consideriamo due polinomi Capitolo 3 Il luogo delle radici Consideriamo due polinomi N(z) = (z z 1 )(z z 2 )... (z z m ) D(z) = (z p 1 )(z p 2 )... (z p n ) della variabile complessa z con m < n. Nelle problematiche connesse al

Dettagli

MANUALE OPERATIVO PER L UTENTE DEL SISTEMA DI TICKETING OTRS

MANUALE OPERATIVO PER L UTENTE DEL SISTEMA DI TICKETING OTRS MANUALE OPERATIVO PER L UTENTE DEL SISTEMA DI TICKETING OTRS PER LA GESTIONE DELLE RICHIESTE RELATIVE ALL APPLICATIVO UGOV - CONTABILITÀ OTRS (Open-source Ticket Request System) e' un pacchetto software

Dettagli

REGOLAMENTO RIGUARDANTE LA PORTABILITA DEI NUMERI PER I SERVIZI DI COMUNICAZIONI MOBILI E PERSONALI

REGOLAMENTO RIGUARDANTE LA PORTABILITA DEI NUMERI PER I SERVIZI DI COMUNICAZIONI MOBILI E PERSONALI REGOLAMENTO RIGUARDANTE LA PORTABILITA DEI NUMERI PER I SERVIZI DI COMUNICAZIONI MOBILI E PERSONALI Articolo 1 (Definizioni)... 2 Articolo 2 (Disposizioni Generali)... 3 Articolo 3 (Soluzioni tecniche

Dettagli

Prova di Esame - Rete Internet (ing. Giovanni Neglia) Prova completa Mercoledì 2 Marzo 2005, ore 14.30

Prova di Esame - Rete Internet (ing. Giovanni Neglia) Prova completa Mercoledì 2 Marzo 2005, ore 14.30 Prova di Esame - Rete Internet (ing. Giovanni Neglia) Prova completa Mercoledì 2 Marzo 2005, ore 14.30 NB: alcune domande hanno risposta multipla: si richiede di identificare TUTTE le risposte corrette.

Dettagli

Guida al backup. 1. Introduzione al backup. Backup dei dati una parte necessaria nella gestione dei rischi. Backup su nastro media ideale

Guida al backup. 1. Introduzione al backup. Backup dei dati una parte necessaria nella gestione dei rischi. Backup su nastro media ideale 1. Introduzione al backup Guida al backup Backup dei dati una parte necessaria nella gestione dei rischi Con l aumentare dei rischi associati a virus, attacchi informatici e rotture hardware, implementare

Dettagli

Problem Management. Obiettivi. Definizioni. Responsabilità. Attività. Input

Problem Management. Obiettivi. Definizioni. Responsabilità. Attività. Input Problem Management Obiettivi Obiettivo del Problem Management e di minimizzare l effetto negativo sull organizzazione degli Incidenti e dei Problemi causati da errori nell infrastruttura e prevenire gli

Dettagli

Luca Mari, Sistemi informativi applicati (reti di calcolatori) appunti delle lezioni. Architetture client/server: applicazioni client

Luca Mari, Sistemi informativi applicati (reti di calcolatori) appunti delle lezioni. Architetture client/server: applicazioni client Versione 25.4.05 Sistemi informativi applicati (reti di calcolatori): appunti delle lezioni Architetture client/server: applicazioni client 1 Architetture client/server: un esempio World wide web è un

Dettagli

Laboratorio di Sistemi Fattoriale di un numero Jsp [Java]

Laboratorio di Sistemi Fattoriale di un numero Jsp [Java] Desideriamo realizzare una applicazione web che ci consenta di calcolare il fattoriale di un numero. L'esercizio in sé non particolarmente difficile, tuttavia esso ci consentirà di affrontare il problema

Dettagli

Gestione Email Gruppo RAS Carrozzerie Convenzionate

Gestione Email Gruppo RAS Carrozzerie Convenzionate Email Ras - CARROZZIERI Pag. 1 di 17 Gestione Email Gruppo RAS Carrozzerie Convenzionate Notizie Generali Email Ras - CARROZZIERI Pag. 2 di 17 1.1 Protocollo Gruppo RAS Questo opuscolo e riferito al Protocollo

Dettagli

Ultimo aggiornamento avvenuto il 18 giugno 2014. Sostituisce la versione del 2 maggio 2013 nella sua interezza.

Ultimo aggiornamento avvenuto il 18 giugno 2014. Sostituisce la versione del 2 maggio 2013 nella sua interezza. Condizioni di utilizzo aggiuntive di Acrobat.com Ultimo aggiornamento avvenuto il 18 giugno 2014. Sostituisce la versione del 2 maggio 2013 nella sua interezza. SERVIZI ONLINE ADOBE RESI DISPONIBILI SU

Dettagli

Guida alla compilazione

Guida alla compilazione Guida alla compilazione 1 Guida alla compilazione... 1 PARTE I REGISTRAZIONE ORGANIZZAZIONE... 5 LA PRIMA REGISTRAZIONE... 5 ACCESSO AREA RISERVATA (LOGIN)...11 ANAGRAFICA ORGANIZZAZIONE...12 ANAGRAFICA

Dettagli

Semplici Algoritmi di Ordinamento

Semplici Algoritmi di Ordinamento Fondamenti di Informatica Semplici Algoritmi di Ordinamento Fondamenti di Informatica - D. Talia - UNICAL 1 Ordinamento di una sequenza di elementi Esistono molti algoritmi di ordinamento. Tutti ricevono

Dettagli

www.sanzioniamministrative.it

www.sanzioniamministrative.it SanzioniAmministrative. it Normativa Legge 15 dicembre 1990, n. 386 "Nuova disciplina sanzionatoria degli assegni bancari" (Come Aggiornata dal Decreto Legislativo 30 dicembre 1999, n. 507) Art. 1. Emissione

Dettagli

Dall italiano alla logica proposizionale

Dall italiano alla logica proposizionale Rappresentare l italiano in LP Dall italiano alla logica proposizionale Sandro Zucchi 2009-10 In questa lezione, vediamo come fare uso del linguaggio LP per rappresentare frasi dell italiano. Questo ci

Dettagli

FIRESHOP.NET. Gestione Utility & Configurazioni. Rev. 2014.3.1 www.firesoft.it

FIRESHOP.NET. Gestione Utility & Configurazioni. Rev. 2014.3.1 www.firesoft.it FIRESHOP.NET Gestione Utility & Configurazioni Rev. 2014.3.1 www.firesoft.it Sommario SOMMARIO Introduzione... 4 Impostare i dati della propria azienda... 5 Aggiornare il programma... 6 Controllare l integrità

Dettagli

Fondamenti di Informatica e Laboratorio T-AB T-16 Progetti su più file. Funzioni come parametro. Parametri del main

Fondamenti di Informatica e Laboratorio T-AB T-16 Progetti su più file. Funzioni come parametro. Parametri del main Fondamenti di Informatica e Laboratorio T-AB T-16 Progetti su più file. Funzioni come parametro. Parametri del main Paolo Torroni Dipartimento di Elettronica, Informatica e Sistemistica Università degli

Dettagli

P a s q u a l e t t i V e r o n i c a

P a s q u a l e t t i V e r o n i c a PHP: OOP Pasqualetti Veronica Oggetti Possiamo pensare ad un oggetto come ad un tipo di dato più complesso e personalizzato, non esistente fra i tipi tradizionali di PHP, ma creato da noi. 2 Gli oggetti

Dettagli

PROGRAMMAZIONE ORIENTATA AGLI OGGETTI in C++

PROGRAMMAZIONE ORIENTATA AGLI OGGETTI in C++ PROGRAMMAZIONE ORIENTATA AGLI OGGETTI in C++ Classi ed oggetti. Classi derivate, ereditarietà e polimorfismo. Template Capitoli 12, 13, 14 Luis Joyannes Aguilar. Fondamenti di Programmazione in C++. Algoritmi,

Dettagli

Travature reticolari piane : esercizi svolti De Domenico D., Fuschi P., Pisano A., Sofi A.

Travature reticolari piane : esercizi svolti De Domenico D., Fuschi P., Pisano A., Sofi A. Travature reticolari piane : esercizi svolti e omenico., Fuschi., isano., Sofi. SRZO n. ata la travatura reticolare piana triangolata semplice illustrata in Figura, determinare gli sforzi normali nelle

Dettagli

SMS API. Documentazione Tecnica YouSMS SOAP API. YouSMS Evet Limited 2015 http://www.yousms.it

SMS API. Documentazione Tecnica YouSMS SOAP API. YouSMS Evet Limited 2015 http://www.yousms.it SMS API Documentazione Tecnica YouSMS SOAP API YouSMS Evet Limited 2015 http://www.yousms.it INDICE DEI CONTENUTI Introduzione... 2 Autenticazione & Sicurezza... 2 Username e Password... 2 Connessione

Dettagli

Plesk Automation. Parallels. Domande tecniche più frequenti

Plesk Automation. Parallels. Domande tecniche più frequenti Parallels Plesk Automation Primo trimestre, 2013 Domande tecniche più frequenti Questo documento ha come scopo quello di rispondere alle domande tecniche che possono sorgere quando si installa e si utilizza

Dettagli