ComunicazioneSD - Università degli Studi di Roma "Tor Vergata"
Transcript
ComunicazioneSD - Università degli Studi di Roma "Tor Vergata"
Università degli Studi di Roma “Tor Vergata” Facoltà di Ingegneria • Si basa sempre sullo scambio di messaggi – Invio e ricezione di messaggi (a basso livello) • Per permettere lo scambio di messaggi, le parti devono accordarsi su diversi aspetti – Quanti volt per segnalare un bit 0 e quanti per un bit 1? – Quanti bit per un intero? – Come fa il destinatario a sapere quale è l’ultimo bit del messaggio? – Come può capire se un messaggio è stato danneggiato e cosa fare quando se ne accorge? – … Valeria Cardellini - SD A.A. 2011/12 1 • Soluzione (già nota): suddividere il problema in livelli – Ciascun livello in un sistema comunica con lo stesso livello nell’altro sistema – Modello di riferimento ISO/OSI • Adattamento del modello di riferimento tradizionale per le comunicazioni di rete – – – – Protocolli di livello più basso Protocolli di trasporto Protocolli middleware Protocolli applicativi Valeria Cardellini - SD A.A. 2011/12 2 • Livello middleware: fornisce servizi comuni e protocolli general-purpose – di alto livello – indipendenti dalle specifiche applicazioni – che possono essere usati da altre applicazioni • Alcuni esempi: – – – – – – Obiettivo di queste lezioni Protocolli middleware di comunicazione: per invocare procedure remote o metodi remoti, accodare messaggi, supportare streaming e multicasting Protocolli di naming: per permettere la condivisione di risorse tra applicazioni Protocolli di sicurezza: per consentire alle applicazioni di comunicare in modo sicuro Protocolli di commit distribuiti: per stabilire che una certa operazione sia portata a termine da tutte le parti coinvolte o non abbia alcun effetto Protocolli di locking distribuiti Protocolli di consistenza dei dati Valeria Cardellini - SD A.A. 2011/12 3 • Distinguiamo la comunicazione in base a: – Persistenza • Comunicazione persistente o transiente – Sincronizzazione • Comunicazione sincrona o asincrona – Dipendenza dal tempo • Comunicazione discreta e a stream Valeria Cardellini - SD A.A. 2011/12 4 • Comunicazione persistente – Il messaggio immesso viene memorizzato dal middleware di comunicazione per tutto il tempo necessario alla consegna – Non occorre che il mittente continui l’esecuzione dopo l’invio del messaggio – Non è necessario che il destinatario sia in esecuzione quando il messaggio è inviato • Comunicazione transiente – Il messaggio è memorizzato dal middleware solo finché mittente e destinatario sono in esecuzione – Se la consegna non è possibile, il messaggio viene cancellato – E’ il caso tipico della comunicazione di rete a livello di trasporto: i router memorizzano ed inoltrano; se non è possibile inoltrare, cancellano Valeria Cardellini - SD A.A. 2011/12 5 • Comunicazione sincrona – Una volta sottomesso il messaggio, il mittente si blocca finché l’operazione non è completata – L’invio e la ricezione sono operazioni bloccanti – Fino a quando si blocca il mittente? • Finché il middleware non prende il controllo della trasmissione • Finché il messaggio non viene consegnato al destinatario • Finché il messaggio non viene elaborato dal destinatario Valeria Cardellini - SD A.A. 2011/12 6 • Comunicazione asincrona – Una volta sottomesso il messaggio, il mittente continua l’elaborazione: il messaggio viene memorizzato temporaneamente dal middleware fino ad avvenuta trasmissione – L’invio è un’operazione non bloccante – La ricezione può essere bloccante o non bloccante Valeria Cardellini - SD A.A. 2011/12 7 • Comunicazione discreta – Ogni messaggio costituisce un’unità di informazione completa • Comunicazione a stream (streaming) – Comporta l’invio di molti messaggi, in relazione temporale tra loro o in base all’ordine di invio, che servono a ricostruire un’informazione completa Valeria Cardellini - SD A.A. 2011/12 8 • Quali sono le possibili combinazioni reali tra persistenza e sincronizzazione? • Comunicazione persistente e asincrona – Ad es., posta elettronica • Comunicazione persistente e sincrona – Mittente bloccato fino alla copia (garantita) del messaggio presso il destinatario • Comunicazione transiente e asincrona – Mittente non attende ma messaggio perso se destinatario non raggiungibile (ad es. UDP) • Comunicazione transiente e sincrona a) mittente bloccato fino alla copia del messaggio nel destinatario b) mittente bloccato fino alla copia (non garantita) del messaggio nello spazio del destinatario (ad es. RPC asincrona) c) mittente bloccato fino alla ricezione di un messaggio di risposta dal destinatario (ad es. RPC sincrona e RMI) Valeria Cardellini - SD A.A. 2011/12 9 • Il messaggio di richiesta e/o risposta può andare perduto – La comunicazione su rete è sempre soggetta a fallimento • Il server può subire un crash – Prima dell’esecuzione – Dopo l’esecuzione • Il client può subire un crash Valeria Cardellini - SD A.A. 2011/12 10 • Quale è la semantica della comunicazione in presenza di errori? • Dipende dalla combinazione di tre meccanismi di base 1. Lato client: riprova (Request Retry – RR1) – Il client continua a provare finché ottiene risposta o è certo del guasto del server 2. Lato server: filtra i duplicati (Duplicate Filtering – DF) – Il server scarta gli eventuali duplicati di richieste provenienti dallo stesso client 3. Lato server: ritrasmetti le risposte (Result Retransmit – RR2) – Il server conserva le risposte per poterle ritrasmettere senza ricalcolarle – Meccanismo necessario se l’operazione non è idempotente • Operazione idempotente: molteplici esecuzioni dell’operazione producono gli stessi effetti di una sola esecuzione dell’operazione Valeria Cardellini - SD A.A. 2011/12 11 • Semantica may-be (forse) – Il messaggio può arrivare o meno – Nessun meccanismo (RR1, DF, RR2) in uso – Non si fanno azioni per garantire l’affidabilità della comunicazione – Ad es. best-effort in IP o UDP Client Invio richiesta Server Messaggio richiesta Messaggio risposta Processamento Invio risposta PERSO Valeria Cardellini - SD A.A. 2011/12 12 • Semantica at-least-once (almeno una volta) – Il messaggio, se arriva, arriva almeno una volta • Anche più volte, a causa della duplicazione dovuta alle ritrasmissioni – In caso di insuccesso, nessuna informazione – Il client usa RR1, ma il server non usa né DF né RR2 • Il server non si accorge delle ritrasmissioni – Adatta per operazioni idempotenti – All’arrivo di una risposta, il client non sa quante volte sia stata calcolata dal server: non conosce per certo lo stato del server Valeria Cardellini - SD A.A. 2011/12 13 Client timeout Invio richiesta timeout Invio richiesta timeout Invio richiesta Messaggio richiesta Server PERSO Ritrasmetti messaggio richiesta Messaggio risposta Processamento Invio risposta PERSO Ritrasmetti messaggio richiesta Messaggio risposta Processamento Invio risposta Valeria Cardellini - SD A.A. 2011/12 14 • Semantica at-most-once (al più una volta) – Il messaggio, se arriva, arriva al più una volta • Il client sa che la risposta è stata calcolata una sola volta • In caso di insuccesso, nessuna informazione; la risposta non arriva soltanto in presenza di guasti permanenti del server – Tutti e 3 i meccanismi in uso (RR1, DF, RR2) • Il client effettua ritrasmissioni • Il server mantiene uno stato per riconoscere i messaggi già ricevuti e per non eseguire operazioni più di una volta – Adatta per qualunque tipo di operazione • Anche non idempotente – Semantica che non mette vincoli sulle azioni conseguenti • No coordinamento tra client e server: in caso di errore, il client non sa se il server ha eseguito l’operazione, mentre il server ignora se il client sa che ha eseguito l’operazione • Possibile inconsistenza sull’accordo tra client e server Valeria Cardellini - SD A.A. 2011/12 15 Client timeout Invio richiesta timeout Invio richiesta timeout Invio richiesta Messaggio richiesta Server PERSO Ritrasmetti messaggio richiesta Messaggio risposta PERSO Ritrasmetti messaggio richiesta Messaggio risposta Registrazione richiesta Processamento Invio risposta Registrazione risposta Filtraggio duplicato Invio risposta Valeria Cardellini - SD A.A. 2011/12 16 • Semantica exactly-once (esattamente una volta) – Accordo completo sull’interazione • Il messaggio arriva una sola volta oppure o è arrivato o non è stato considerato da entrambi: semantica tutto o niente • Se va tutto bene: il messaggio arriva una sola volta e viene trattato una sola volta, riconoscendo i duplicati • Se qualcosa va male: client o server sanno se il messaggio è arrivato (e considerato una sola volta - tutto) o se non è arrivato; se non è arrivato, il tutto può essere riportato indietro (niente) – Semantica con conoscenza concorde dello stato dell’altro e senza ipotesi di durata massima del protocollo – Ha bisogno di ulteriori meccanismi (ad es. replicazione trasparente, meccanismi di recovery) per tollerare guasti lato server Valeria Cardellini - SD A.A. 2011/12 17 • Programmazione di rete esplicita – Chiamata diretta all’API socket e scambio esplicito di messaggi – Usata nella maggior parte delle applicazioni di rete note (ad es. Web browser, Web server) – La distribuzione non è trasparente – Gran parte del peso dello sviluppo sulle spalle del programmatore • Come innalzare il livello di astrazione della programmazione distribuita? Fornendo uno strato intermedio (middleware) fra SO ed applicazioni che: – Nasconda la complessità degli strati sottostanti – Liberi il programmatore da compiti automatizzabili – Migliori la qualità del software mediante il riuso di soluzioni consolidate, corrette ed efficienti Valeria Cardellini - SD A.A. 2011/12 18 • Programmazione di rete implicita – Chiamata di procedura remota (RPC) • L’applicazione distribuita è realizzata usando le chiamate di procedura, ma il processo chiamante (client) ed il processo contenente la procedura chiamata (server) possono essere su macchine diverse – Invocazione di metodo remoto (Java RMI) • L’applicazione distribuita è realizzata invocando i metodi di un oggetto di un’applicazione Java in esecuzione su una macchina remota • Trasparenza della distribuzione Applications, services RMI and RPC This chapter request-reply protocol Middleware layers marshalling and external data representation UDP and TCP Valeria Cardellini - SD A.A. 2011/12 19 • Il middleware scambia messaggi per consentire la chiamata/invocazione di procedura/metodo; occorre: – Identificare i messaggi di chiamata/invocazione ed i messaggi di risposta – Identificare univocamente procedura/metodo remota/o • Il middleware gestisce l’eterogeneità dei dati scambiati – Marshaling/unmarshaling dei parametri per gestire diversa rappresentazione dei dati – Serializzazione dei parametri (dati strutturati in flusso di byte) • Il middleware gestisce alcuni errori dovuti alla distribuzione – Implementazione errata – Errori dell’utente Valeria Cardellini - SD A.A. 2011/12 • 20 Quali sono i problemi da risolvere per realizzare la chiamata di procedura/invocazione di metodo in modo trasparente e senza sapere dove si trova la procedura chiamata/il metodo invocato? 1. Rappresentazione dei dati potenzialmente diversa su client e server – Inoltre, client e server devono coordinarsi sul protocollo di trasporto usato per lo scambio di messaggi 2. In presenza di malfunzionamenti, cosa può il client considerare certo rispetto all’esecuzione di procedura chiamata/metodo remoto? – – Nel caso locale: semantica exactly-once Nel caso remoto: semantica at-least-once oppure at-most-once 3. Come effettuare il binding al server? Valeria Cardellini - SD A.A. 2011/12 21 • Client e server potrebbero usare una diversa codifica dei dati, ad es.: – – – – Codifica di caratteri Rappresentazione di numeri interi e in virgola mobile Ordinamento dei byte (little endian vs big endian) Non solo per tipi di dato elementari ma anche strutturati • Quali alternative per gestire l’eterogeneità nella rappresentazione dei dati ed interpretare il messaggio in modo non ambiguo? 1. La codifica è specificata nel messaggio stesso 2. Il mittente del messaggio converte i dati nella rappresentazione attesa dal destinatario 3. Ogni dato è convertito in un formato comune concordato • • Mittente: da codifica proprietaria a comune Destinatario: da codifica comune a proprietaria 4. Esiste un intermediario che effettua le conversioni tra codifiche diverse Valeria Cardellini - SD A.A. 2011/12 • • 22 Confrontiamo le alternative 2 e 3, nell’ipotesi di N host che comunicano tra loro Alternativa 2: dotare ogni host di tutte le funzioni di conversione possibili per ogni rappresentazione dei dati – Alte prestazioni nella conversione – Alto numero di funzioni di conversione, pari a N*(N-1) • Alternativa 3: concordare un formato comune di rappresentazione dei dati ed ogni host possiede le funzioni di conversione da/per questo formato – Minori prestazioni nella conversione – Basso numero di funzioni di conversione, pari a 2*N Valeria Cardellini - SD A.A. 2011/12 23 • Il binding stabilisce come ottenere l’aggancio corretto tra il client ed il server che fornisce la procedura/ metodo • Due tipologie di binding: statico o dinamico • Binding statico – L’indirizzo del server è cablato all’interno del client – Semplice, costo limitato, ma mancanza di trasparenza e flessibilità • Binding dinamico – Ritarda la decisione al momento della necessità – Costi maggiori, ma trasparenza e flessibilità • Ad es. consente di dirigere le richieste sul server più scarico – Il costo deve essere comunque limitato ed accettabile Valeria Cardellini - SD A.A. 2011/12 24 • Si distinguono due fasi nella relazione client/server • Naming: fase statica, prima dell’esecuzione – Il client specifica a chi vuole essere connesso, con un nome unico identificativo del servizio – Si associano dei nomi unici di sistema alle operazioni o alle interfacce astratte e si attua il binding con l’interfaccia specifica di servizio • Addressing: fase dinamica, durante l’esecuzione – Il client deve essere realmente collegato al server che fornisce il servizio al momento dell’invocazione – Si cercano gli eventuali server pronti per il servizio – Addressing esplicito o implicito – Addressing esplicito: multicast o broadcast dal parte del client attendendo solo la prima risposta • Il supporto runtime di ogni macchina risponde se il servizio richiesto è fornito da un suo server in esecuzione Valeria Cardellini - SD A.A. 2011/12 25 – Addressing implicito: uso di un name server (o binder o directory service) che registra tutti i server e agisce su opportune tabelle di binding, prevedendo funzioni di: – ricerca di nomi, registrazione, aggiornamento, eliminazione client stub 2, 3 4 name server server stub 1 • Frequenza del binding dinamico – Ogni chiamata richiede un collegamento dinamico – Spesso, per questioni di costo, dopo aver ottenuto il primo binding lo si continua ad usare come se fosse statico – Il binding può avvenire meno frequentemente delle chiamate stesse • In genere, si usa lo stesso binding per molte chiamate allo stesso server Valeria Cardellini - SD A.A. 2011/12 26 • Remote Procedure Call (RPC) • Idea (proposta da Birrel e Nelson, 1984): utilizzare il modello client server con la stessa semantica di una chiamata di procedura – Un processo sulla macchina A invoca una procedura sulla macchina B – Il processo chiamante su A viene sospeso – Viene eseguita la procedura chiamata su B – Input ed output sono veicolati da parametri – Nessuno scambio di messaggi è visibile al programmatore Valeria Cardellini - SD A.A. 2011/12 27 • Procedura p locale • Procedura p remota Valeria Cardellini - SD A.A. 2011/12 28 • Esempio di chiamata “locale” (convenzionale): count = read(fd, buf, nbytes) • La procedura chiamante inserisce sullo stack i parametri e l’indirizzo di ritorno • La procedura chiamata (read) mette in un registro il valore di ritorno e restituisce il controllo alla procedura chiamante Valeria Cardellini - SD A.A. 2011/12 29 • Modello con stub (adattatore) • Il cliente invoca uno stub (client stub), che si incarica di tutto: – Dall’identificazione del server al trattamento dei parametri, dalla richiesta al supporto run-time all’invio della richiesta • Il server riceve la richiesta dallo stub relativo (server stub), che si incarica del trattamento dei parametri dopo avere ricevuto la richiesta pervenuta dal trasporto. Al completamento del servizio, lo stub rimanda il risultato al client • Lo sviluppo prevede la massima trasparenza – Stub prodotti in modo automatico – Lo sviluppatore progetta e si occupa solo delle reali parti applicative e logiche Valeria Cardellini - SD A.A. 2011/12 30 1. La procedura chiamata, lato client, richiama il client stub usando una normale chiamata di procedura locale 2. Il client stub costruisce un messaggio e richiama il SO locale • Marshaling dei parametri: operazione di impacchettare i parametri in un messaggio 3. Il SO del client invia il messaggio al SO remoto 4. Il SO remoto passa il messaggio al server stub 5. Il server stub spacchetta il messaggio estraendo i parametri e invoca il server • Unmarshaling dei parametri 6. Il server esegue il lavoro e restituisce il risultato al server stub 7. Il server stub lo impacchetta in un messaggio e richiama il suo SO 8. Il SO del server invia il messaggio al SO del client 9. Il SO del client passa il messaggio al client stub 10. Il client stub spacchetta il messaggio e restituisce il risultato al client Valeria Cardellini - SD A.A. 2011/12 31 • Esempio con passaggio di parametri per valore add(i, j) Valeria Cardellini - SD A.A. 2011/12 32 1. Rappresentazione dei dati 2. Procedura chiamante e chiamata in esecuzione su macchine con un diverso spazio di indirizzi: come realizzare il passaggio dei parametri per riferimento? 3. In presenza di malfunzionamenti, cosa può la procedura chiamante considerare certo rispetto all’esecuzione della procedura chiamata? 4. Come effettuare il binding alla macchina su cui viene eseguita la procedura chiamata? Valeria Cardellini - SD A.A. 2011/12 33 • Il middleware RPC fornisce un supporto automatizzato – Il codice per il marshaling/unmarshaling e la serializzazione viene generato automaticamente dal middleware e diviene parte degli stub – Tramite • Una rappresentazione della signature della procedura indipendente dal linguaggio e dalla piattaforma, scritta usando un Interface Definition Language (IDL) • Un formato comune di rappresentazione dei dati da usarsi per la comunicazione Valeria Cardellini - SD A.A. 2011/12 34 • Linguaggio per la definizione delle interfacce (Interface Definition Language - IDL) • Permette la descrizione di operazioni remote, la specifica del servizio (detta signature) e la generazione degli stub • Deve consentire – Identificazione della procedura • Uso di nome astratto del servizio, spesso prevedendo versioni diverse del servizio – Definizione astratta dei dati da trasmettere in input ed output • Uso di un linguaggio astratto di definizione dei dati (operazioni e parametri dell’interfaccia) • Supporta lo sviluppo dell’applicazione – L’interfaccia specificata dal programmatore in IDL può essere usata per generare automaticamente gli stub Valeria Cardellini - SD A.A. 2011/12 35 • Passaggio per valore (call by value) – I dati sono copiati nello stack – Il chiamato agisce su tali dati e le modifiche non influenzano il chiamante • Passaggio per riferimento (call by reference) – L’indirizzo (puntatore) dei dati è copiato nello stack – Il chiamato agisce direttamente sui dati del chiamante • Passaggio per copia/ripristino (call by copy/restore) – I dati sono copiati nello stack dal chiamante e ricopiati dopo la chiamata, sovrascrivendo il valore originale del chiamante – Implementato in pochi linguaggi di programmazione (ad es. Ada, Fortran) Valeria Cardellini - SD A.A. 2011/12 36 • Un riferimento è un indirizzo di memoria – E’ valido solo nel contesto in cui è usato • Soluzione: si simula il passaggio per riferimento usando il passaggio per copia/ripristino – Il client stub copia i dati puntati nel messaggio e lo invia al server stub – Il server stub effettua le operazioni con la copia, usando lo spazio di indirizzi della macchina ricevente – Se occorre effettuare una modifica sulla copia, questa sarà poi riportata dal client stub sul dato originale • Ottimizzazioni: – Se il client stub sa che il riferimento è un parametro di input, non serve che venga ricopiato il suo valore restituito – Se si tratta di un parametro di output, non serve effettuare la copia in partenza Valeria Cardellini - SD A.A. 2011/12 37 • In modalità sincrona, una chiamata RPC provoca il blocco del client – Se il server non deve restituire nessun risultato, il blocco del client non è necessario • Alcuni middleware RPC supportano RPC asincrone – Il client può dedicarsi ad altri task, una volta effettuata la chiamata ed aver ricevuto dal server un acknowledge che la chiamata di procedura è stata ricevuta ed avviata RPC sincrona RPC asincrona Valeria Cardellini - SD A.A. 2011/12 38 • Se la RPC produce un risultato, si può spezzare l’operazione in due (RPC sincrona differita): – Una prima RPC asincrona dal client al server per avviare l’operazione – Una seconda RPC asincrona dal server al client per restituire il risultato RPC sincrona differita • Se il client riprende l’esecuzione senza aspettare l’acknowledge, la RPC asincrona è detta “a senso unico” Valeria Cardellini - SD A.A. 2011/12 39 • Analizziamo l’implementazione ed il middleware RPC di Sun Microsystems: Open Network Computing (ONC), anche noto come SUN RPC • ONC è una suite di prodotti che include: – eXternal Data Representation (XDR): rappresentazione e conversione dati – Remote Procedure Call GENerator (RPCGEN): generazione del client e server stub – Portmapper: risoluzione indirizzo del server – Network File System (NFS): file system distribuito di Sun • Molte altre implementazioni, tra cui Distributed Computing Environment (DCE) RPC Valeria Cardellini - SD A.A. 2011/12 40 • man rpc • man rpcgen • Capitolo 16 di W.R. Stevens, “Unix Network Programming, Volume 2: Interprocess Communication”, 1999. • E. Petron, “Remote Procedure Calls”, Linux Journal, 1997. Valeria Cardellini - SD A.A. 2011/12 41 Valeria Cardellini - SD A.A. 2011/12 42 • Due parti descrittive in linguaggio XDR 1. Definizioni di programmi RPC: specifiche del protocollo RPC per le procedure (servizi) offerte, ovvero l’identificazione delle procedure ed il tipo di parametri 2. Definizioni XDR: definizioni dei tipi di dati dei parametri – Presenti solo se il tipo di dato non è già noto in XDR • Raggruppate in un unico file con estensione .x – Esempio: square.x Valeria Cardellini - SD A.A. 2011/12 43 struct square_in { /* input (argument) */ long arg1; }; struct square_out { /* output (result) */ long res1; }; program SQUARE_PROG { version SQUARE_VERS { square_out SQUAREPROC(square_in) = 1; /* procedure number = 1 */ } = 1; /* version number */ } = 0x31230000; /* program number */ Esempio: square.x Definizione della procedura remota SQUAREPROC; notare che: – Ogni definizione di procedura ha un solo parametro d’ingresso e un solo parametro d’uscita – Gli identificatori (nomi) usano lettere maiuscole – Ogni procedura è associata ad un numero di procedura unico all’interno di un programma (nell’esempio 1) Valeria Cardellini - SD A.A. 2011/12 44 • Il programmatore deve sviluppare: – il programma client: implementazione del main() e della logica necessaria per reperimento e binding del servizio/i remoto/i (esempio: square_client.c) – il programma server: implementazione di tutte le procedure (servizi) (esempio: square_server.c) • Attenzione: il programmatore non realizza il main() lato server... – Chi invoca la procedura remota (lato server)? Valeria Cardellini - SD A.A. 2011/12 45 • Esempio: quadrato di un numero intero • Esaminiamo il codice della tradizionale procedura locale #include <stdio.h> #include <stdlib.h> Esempio: square_local.c struct square_in { /* input (argument) */ long arg; }; struct square_out { /* output (result) */ long res; }; typedef struct square_in square_in; typedef struct square_out square_out; square_out *squareproc(square_in *inp) { static square_out out; } out.res = inp->arg * inp->arg; return(&out); Valeria Cardellini - SD A.A. 2011/12 46 • Procedura locale: quadrato di un numero intero (continua) int main(int argc, char **argv) { square_in in; square_out *outp; if (argc != 2) { printf("usage: %s <integer-value>\n", argv[0]); exit(1); } in.arg = atol(argv[1]); outp = squareproc(&in); printf("result: %ld\n", outp->res); exit(0); } Come si trasforma nel caso di procedura remota? Valeria Cardellini - SD A.A. 2011/12 47 • Il codice di servizio della procedura remota è quasi identico alla procedura locale #include <stdio.h> #include <rpc/rpc.h> #include “square.h” /* generated by rpcgen */ square_out *squareproc_1_svc(square_in *inp, struct svc_req *rqstp) { static square_out out; out.res1 = inp->arg1 * inp->arg1; return(&out); } Esempio: server.c • Osservazioni: – I parametri di ingresso e uscita vengono passati per riferimento – Il parametro di uscita punta ad una variabile statica (allocazione globale), per essere presente anche oltre la chiamata della procedura – Il nome della procedura cambia leggermente (si aggiunge il carattere “_” seguito dal numero di versione, tutto in caratteri minuscoli) Valeria Cardellini - SD A.A. 2011/12 48 • Queste versioni di server.c non sono corrette: perché? … square_out *squareproc_1_svc(square_in *inp, struct svc_req *rqstp) { square_out *outp; outp = (square_out *)malloc(sizeof(square_out)); outp->res1 = inp->arg1 * inp->arg1; return(outp); } … square_out *squareproc_1_svc(square_in *inp, struct svc_req *rqstp) { square_out *outp; free(outp); outp = (square_out *)malloc(sizeof(square_out)); outp->res1 = inp->arg1 * inp->arg1; return(outp); } Valeria Cardellini - SD A.A. 2011/12 49 • Questa versione di server.c è corretta: perché? … square_out *squareproc_1_svc(square_in *inp, struct svc_req *rqstp) { static square_out *outp; free(outp); outp = (square_out *)malloc(sizeof(square_out)); outp->res1 = inp->arg1 * inp->arg1; return(outp); } Valeria Cardellini - SD A.A. 2011/12 50 • Il client viene invocato col nome dell’host remoto ed il valore intero e richiede il servizio di square remoto #include <stdio.h> #include <rpc/rpc.h> #include "square.h“ /* generated by rpcgen */ int main(int argc, char **argv) { CLIENT *cl; char *server; square_in in; square_out *outp; if (argc != 3) { printf("usage: client <hostname> <integer-value>\n"); exit(1); } CLIENT *clnt_create(const char *host, unsigned long program, unsigned number versnum, const char *protocol) server = argv[1]; cl = clnt_create(server, SQUARE_PROG, SQUARE_VERS, "tcp"); Esempio: client.c Valeria Cardellini - SD A.A. 2011/12 51 if (cl == NULL) { clnt_pcreateerror(server); exit(1); } in.arg1 = atol(argv[2]); if ((outp = squareproc_1(&in, cl)) == NULL) { printf("%s", clnt_sperror(cl, argv[1])); exit(1); } printf("result: %ld\n", outp->res1); exit(0); } Valeria Cardellini - SD A.A. 2011/12 52 • clnt_create(): crea il gestore di trasporto client che gestisce la comunicazione col server – Nell’esempio: trasporto con connessione (“tcp” tra i parametri di input) • Il client deve conoscere: – il nome dell’host remoto su cui è in esecuzione il servizio – alcune informazioni per invocare il servizio stesso (programma, versione e nome della procedura) • Per la chiamata della procedura remota: – Il nome della procedura cambia: si aggiunge il carattere “_” seguito dal numero di versione (nome in caratteri minuscoli) – Due parametri di ingresso della procedura chiamata: • il parametro di ingresso vero e proprio • il gestore di trasporto del client • Il client gestisce gli errori che si possono presentare durante la chiamata remota usando le funzioni di stampa degli errori – clnt_pcreateerror() e clnt_perror() Valeria Cardellini - SD A.A. 2011/12 53 1. Definire servizi e tipi di dato (se necessario) ! square.x 2. Generare in modo automatico gli stub del client e del server e (se necessario) le funzioni di conversione XDR ! uso di RPCGEN • Genera square_clnt.c, square_svc.c, square_xdr.c, square.h 3. Realizzare i programmi client e server (client.c e server.c), compilare tutti i file sorgente (programmi client e server, stub e file per la conversione dei dati) e fare il linking dei file oggetto 4. Pubblicare i servizi (lato server) 1. Attivare il port mapper 2. Registrare i servizi presso il port mapper (lanciando il server) 5. Reperire (lato client) l’endpoint del server tramite il port mapper e creare il gestore di trasporto per l’interazione col server A questo punto l’interazione fra client e server può procedere Valeria Cardellini - SD A.A. 2011/12 54 • Un programma tipicamente contiene più procedure remote – Possibili versioni multiple di ogni procedura – Un unico argomento in ingresso ed in uscita per ogni invocazione (passaggio per copia-ripristino) • Mutua esclusione garantita dal programma (e server): di default no concorrenza lato server – Server sequenziale ed una sola invocazione eseguita per volta – Per server multithreaded (non su Linux): rpcgen con opzioni –M e –A • Fino al ritorno della procedura, il client è in attesa sincrona bloccante della risposta • Semantica at-least-once della comunicazione – Ritrasmissione allo scadere di un intervallo di time-out • UDP come protocollo di trasporto di default Valeria Cardellini - SD A.A. 2011/12 55 • Per l’identificazione globale, un messaggio di richiesta RPC deve contenere – numero di programma – numero di versione – numero di procedura • Numeri di programma (32 bit) appartenenti a: [0x00000000, 0x1fffffff]: predefinito da Sun; per applicazioni d'interesse comune [0x20000000, 0x3fffffff]: definibile dall’utente [0x40000000, 0x5fffffff]: transitorio, riservato alle applicazioni [0x6fffffff, 0xffffffff]: per estensioni future Valeria Cardellini - SD A.A. 2011/12 56 Applicazione distribuita basata su RPC Utilizzo di servizi RPC standard Definizione ed utilizzo di servizi RPC Gestione avanzata del protocollo RPC Interfaccia socket Protocolli di trasporto (UDP e TCP) Valeria Cardellini - SD A.A. 2011/12 Diversi livelli di astrazione: tradeoff tra flessibilità nel controllo e quantità di codice da sviluppare 57 • Livello alto: utilizzo di servizi RPC standard – Esempi di procedure remote pronte per essere invocate: rnusers(), rusers(), rstat() – Numeri di programmi noti • Livello intermedio: definizione ed utilizzo di nuovi servizi RPC – Due primitive: callrpc() e registerrpc() – CLIENT - callrpc(): chiamata esplicita al meccanismo RPC; provoca l’esecuzione della procedura remota – SERVER - registerrpc(): registrazione della procedura remota, associandole l’identificatore Valeria Cardellini - SD A.A. 2011/12 58 • Livello basso: gestione avanzata del protocollo RPC – Chiamata remota tramite funzioni avanzate per ottenere la massima capacità espressiva Valeria Cardellini - SD A.A. 2011/12 59 • Eterogeneità dei dati gestita tramite l’uso di un formato comune di rappresentazione • Funzioni XDR di conversione built-in, relative a: – Tipi atomici predefiniti • Ad es. xdr_bool(), xdr_char(), xdr_int() – Tipi strutturati predefiniti • Ad es. xdr_string(), xdr_array() • Ciascuna funzione XDR creata da rpcgen può essere usata sia per serializzare (encode) che per deserializzare (decode) Valeria Cardellini - SD A.A. 2011/12 60 • Prima parte del file – Definizioni XDR delle costanti – Definizioni XDR dei tipi di dato dei parametri di ingresso e uscita per tutti i tipi di dato per i quali non esiste una corrispondente funzione XDR built-in • Seconda parte del file – Definizioni XDR delle procedure • Esempio in square.x: SQUAREPROC è la procedura numero 1 della versione 1 del programma numero 0x31230000 • Da notare che per le specifiche del protocollo RPC: – Il numero di procedura zero (0) è riservato a NULLPROC – Ogni definizione di procedura ha un solo parametro d’ingresso e d’uscita – Gli identificatori di programma, versione e procedura usano tutte lettere maiuscole ed il seguente spazio di nomi: <NOMEPROGRAMMA>PROG per il nome del programma <NOMEPROGRAMMA>VERS per la versione del programma <NOMEPROCEDURA> per i nomi delle procedure Valeria Cardellini - SD A.A. 2011/12 61 • Per poter essere invocata, la procedura deve essere registrata – Identificatore in base al protocollo RPC: numero di programma (prognum), numero di versione (versnum), numero di procedura – Occorre definire anche il protocollo di trasporto (protocol) – Il client deve conoscere il numero di porta (port) su cui il server risponde • Il server deve registrare il programma RPC nella tabella dinamica dei servizi dell’host su cui è in esecuzione • Una riga di questa tabella (detta port map) contiene la tripla {prognum, versnum, protocol} e port – Manca il numero di procedura: tutte le procedure RPC all’interno di un programma condividono lo stesso gestore di trasporto • La tabella di port map è gestita da un solo processo (detto port mapper) per ogni host su cui sono eseguiti server RPC Valeria Cardellini - SD A.A. 2011/12 62 • Server port mapper (portmap) in ascolto sulla porta 111 (sia UDP che TCP) • Quando un server RPC viene lanciato, notifica al port mapper in esecuzione sull’host le informazioni sul servizio offerto – prognum, versnum, protocol e port • Prima di invocare il servizio, un client contatta il port mapper sull’host remoto per conoscere la porta corrispondente al servizio • Il port mapper registra i servizi sull’host e offre le funzionalità di: – Inserimento di un servizio – Eliminazione di un servizio – Corrispondenza tra servizio e porta – Lista dei servizi registrati Valeria Cardellini - SD A.A. 2011/12 63 • Per avere la lista di tutti i programmi RPC invocabili su di un host usare rpcinfo -p nomehost xxx:~/RPC/square$ rpcinfo -p program vers proto 100000 2 tcp 100000 2 udp 824377344 1 udp 824377344 1 tcp port 111 111 59528 49311 portmapper portmapper • Nell’output: 824377344 (= 0x31230000) è il numero di programma in square.x • /etc/rpc contiene l’elenco dei programmi RPC disponibili Valeria Cardellini - SD A.A. 2011/12 64 Data una specifica di partenza • file di linguaggio XDR – square.x RPCGEN produce in automatico • header file – square.h • file stub del client – square_clnt.c • file stub del server Analizziamoli – square_svc.c • file di routine XDR – square_xdr.c Lo sviluppatore deve realizzare • programma client – client.c • programma server – server.c Valeria Cardellini - SD A.A. 2011/12 65 square.x rpcgen #include client.c square.h square_clnt.c square_xdr.c square_svc.c gcc gcc client server server.c Valeria Cardellini - SD A.A. 2011/12 66 Valeria Cardellini - SD A.A. 2011/12 67 /* * Please do not edit this file. * It was generated using rpcgen. */ #ifndef _SQUARE_H_RPCGEN Incluso #define _SQUARE_H_RPCGEN #include <rpc/rpc.h> #ifdef __cplusplus extern "C" { #endif dai due stub In caso di nuovi tipi di dato si devono definire le nuove strutture dati per le quali saranno generate in automatico le nuove funzioni di trasformazione struct square_in { long arg1; }; typedef struct square_in square_in; struct square_out { long res1; }; typedef struct square_out square_out; #define SQUARE_PROG 0x31230000 #define SQUARE_VERS 1 Esempio: square.h Valeria Cardellini - SD A.A. 2011/12 68 #if defined(__STDC__) || defined(__cplusplus) #define SQUAREPROC 1 extern square_out * squareproc_1(square_in *, CLIENT *); extern square_out * squareproc_1_svc(square_in *, struct svc_req *); extern int square_prog_1_freeresult (SVCXPRT *, xdrproc_t, caddr_t); #else /* K&R C */ #define SQUAREPROC 1 extern square_out * squareproc_1(); extern square_out * squareproc_1_svc(); extern int square_prog_1_freeresult (); #endif /* K&R C */ /* the xdr functions */ #if defined(__STDC__) || defined(__cplusplus) extern bool_t xdr_square_in (XDR *, square_in*); extern bool_t xdr_square_out (XDR *, square_out*); #else /* K&R C */ extern bool_t xdr_square_in (); extern bool_t xdr_square_out (); #endif /* K&R C */ #ifdef __cplusplus } #endif #endif /* !_SQUARE_H_RPCGEN */ Valeria Cardellini - SD A.A. 2011/12 Esempio: square.h 69 /* * Please do not edit this file. * It was generated using rpcgen. */ #include "square.h“ bool_t xdr_square_in (XDR *xdrs, square_in *objp) { register int32_t *buf; if (!xdr_long (xdrs, &objp->arg1)) return FALSE; return TRUE; } bool_t xdr_square_out (XDR *xdrs, square_out *objp) { register int32_t *buf; if (!xdr_long (xdrs, &objp->res1)) return FALSE; return TRUE; Esempio: square_xdr.c } Valeria Cardellini - SD A.A. 2011/12 70 /* * Please do not edit this file. * It was generated using rpcgen. */ #include <memory.h> /* for memset */ #include "square.h" /* Default timeout can be changed using clnt_control() */ static struct timeval TIMEOUT = { 25, 0 }; square_out * squareproc_1(square_in *argp, CLIENT *clnt) { static square_out clnt_res; } Assegna timeout per la chiamata Reale chiamata remota memset((char *)&clnt_res, 0, sizeof(clnt_res)); nel client stub if (clnt_call (clnt, SQUAREPROC, (xdrproc_t) xdr_square_in, (caddr_t) argp, (xdrproc_t) xdr_square_out, (caddr_t) &clnt_res, TIMEOUT) != RPC_SUCCESS) { return (NULL); } Esempio: square_clnt.c return (&clnt_res); Valeria Cardellini - SD A.A. 2011/12 71 /* * Please do not edit this file. * It was generated using rpcgen. */ #include "square.h" #include <stdio.h> #include <stdlib.h> #include <rpc/pmap_clnt.h> #include <string.h> #include <memory.h> #include <sys/socket.h> #include <netinet/in.h> #ifndef SIG_PF #define SIG_PF void(*)(int) #endif Funzione di dispatching static void square_prog_1(struct svc_req *rqstp, register SVCXPRT *transp) { union { square_in squareproc_1_arg; } argument; char *result; Esempio: square_svc.c xdrproc_t _xdr_argument, _xdr_result; char *(*local)(char *, struct svc_req *); Valeria Cardellini - SD A.A. 2011/12 72 switch (rqstp->rq_proc) { case NULLPROC: (void) svc_sendreply (transp, (xdrproc_t) xdr_void, (char *)NULL); return; case SQUAREPROC: _xdr_argument = (xdrproc_t) xdr_square_in; _xdr_result = (xdrproc_t) xdr_square_out; local = (char *(*)(char *, struct svc_req *)) squareproc_1_svc; break; default: svcerr_noproc (transp); return; } memset ((char *)&argument, 0, sizeof (argument)); if (!svc_getargs (transp, (xdrproc_t) _xdr_argument, (caddr_t) &argument)) { svcerr_decode (transp); return; } result = (*local)((char *)&argument, rqstp); if (result != NULL && !svc_sendreply(transp, (xdrproc_t) _xdr_result, result)) { svcerr_systemerr (transp); } Esempio: square_svc.c Valeria Cardellini - SD A.A. 2011/12 73 } if (!svc_freeargs (transp, (xdrproc_t) _xdr_argument, (caddr_t) &argument)) { fprintf (stderr, "%s", "unable to free arguments"); exit (1); } Esempio: square_svc.c return; int main (int argc, char **argv) { register SVCXPRT *transp; Distrugge eventuali registrazioni precedenti con lo stesso numero di programma e versione Crea il gestore di protocollo che pmap_unset(SQUARE_PROG, SQUARE_VERS); utilizza socket UDP transp = svcudp_create(RPC_ANYSOCK); if (transp == NULL) { fprintf (stderr, "%s", "cannot create udp service."); exit(1); } if (!svc_register(transp, SQUARE_PROG, SQUARE_VERS, square_prog_1, IPPROTO_UDP)) { fprintf (stderr, "%s", "unable to register (SQUARE_PROG, SQUARE_VERS, udp)."); Associa la tripla {n_prog, exit(1); n_vers, protocollo} ad una } Valeria Cardellini - SD A.A. 2011/12 procedura di dispatching che implementa i vari servizi 74 transp = svctcp_create(RPC_ANYSOCK, 0, 0); if (transp == NULL) { fprintf (stderr, "%s", "cannot create tcp service."); exit(1); Crea il gestore di protocollo che } utilizza socket TCP if (!svc_register(transp, SQUARE_PROG, SQUARE_VERS, square_prog_1, IPPROTO_TCP)) { fprintf (stderr, "%s", "unable to register (SQUARE_PROG, SQUARE_VERS, tcp)."); exit(1); } Entra nel ciclo infinito di attesa e servizio della chiamata svc_run(); fprintf (stderr, "%s", "svc_run returned"); exit (1); /* NOTREACHED */ } Esempio: square_svc.c Valeria Cardellini - SD A.A. 2011/12 75 • Esempi di programmi RPC disponibili sul sito del corso – square: quadrato di un numero intero • Già esaminato – echo: ripetizione di una sequenza di caratteri – avg: valore medio di una sequenza di numeri reali – rls: listato di una directory remota • Le routine XDR in dir_xdr.c sono generate automaticamente a partire dai tipi di dato definiti in dir.x e permettono la conversione da formato locale a XDR e viceversa Valeria Cardellini - SD A.A. 2011/12 76 • “Trail: RMI”, http://download.oracle.com/javase/ tutorial/rmi/ Valeria Cardellini - SD A.A. 2011/12 77 • Il paradigma RPC può essere facilmente esteso al modello a oggetti distribuiti – Java RMI (Remote Method Invocation): RPC in Java – RMI fornisce la possibilità di richiedere l’esecuzione di metodi remoti in Java, integrando il tutto con il paradigma OO • Java RMI è un insieme di strumenti, politiche e meccanismi che permettono ad un’applicazione Java in esecuzione su un host di invocare i metodi di un oggetto di un’applicazione Java in esecuzione su un host differente – Obiettivo: rendere il più possibile simili l’involcazione locale e quella remota Valeria Cardellini - SD A.A. 2011/12 78 • Localmente viene creato solo il riferimento ad un oggetto remoto, che è effettivamente attivo su un host remoto • Il programma lato client invoca i metodi remoti attraverso questo riferimento locale • Quali sono le differenza rispetto all’invocazione di un oggetto locale? – Affidabilità, semantica della comunicazione, durata, … local! remote! invocation! A! Valeria Cardellini - SD A.A. 2011/12 B! C! E! invocation! local! invocation! local! invocation! D! remote! invocation! F! 79 • Principio base: la definizione del comportamento (interfaccia) e l’implementazione del comportamento (classe) sono concetti separati • La separazione logica tra interfaccia ed oggetto consente anche la loro separazione fisica – Interfaccia remota: specifica quali metodi dell’oggetto possono essere invocati da remoto – Lo stato interno di un oggetto non viene distribuito! remote!object! remote! interface! {! Data! m1! m2! m3! implementation! of methods! m4! m5! m6! Valeria Cardellini - SD A.A. 2011/12 80 • Al binding di un client con un oggetto server distribuito, una copia dell’interfaccia del server (stub) viene caricata nello spazio del client – Ruolo del tutto analogo a quello del client stub in ambiente RPC • La richiesta in arrivo all’oggetto remoto viene trattata da un “agente” del client, locale al server (skeleton) – Ruolo del tutto analogo a quello del server stub in ambiente RPC • Unico ambiente di lavoro come conseguenza del linguaggio Java, ma eterogeneità dei sistemi – Grazie alla portabilità del codice Java Valeria Cardellini - SD A.A. 2011/12 81 • Come in RPC, anche in RMI si usa il proxy pattern: i due proxy (stub dal lato client e skeleton dal lato server) nascondono al livello applicativo la natura distribuita dell’applicazione – Stub: proxy locale sul nodo client su cui vengono fatte le invocazioni destinate all’oggetto remoto – Skeleton: proxy remoto sul nodo server che riceve le invocazioni fatte sullo stub e le realizza effettuando le corrispondenti chiamate sul server Valeria Cardellini - SD A.A. 2011/12 82 • Stub e skeleton rendono possibile la chiamata di un servizio remoto come se fosse locale, agendo da proxy – Sono generati automaticamente • (De)serializzazione supportata direttamente da Java – Grazie all’uso del bytecode, non c’è bisogno di (un)marshaling come in RPC, ma i dati vengono semplicemente (de)serializzati utilizzando le funzionalità offerte direttamente a livello di linguaggio – Serializzazione: trasformazione di oggetti complessi in sequenze di byte • metodo writeObject() su uno stream di output – Deserializzazione: decodifica di una sequenza di byte e costruzione di una copia dell’oggetto originale • metodo readObject() da uno stream di input Valeria Cardellini - SD A.A. 2011/12 83 • Passi per la comunicazione 1. Il client ottiene un’istanza dello stub (come?) 2. Il client invoca i metodi sullo stub 3. Lo stub effettua la serializzazione delle informazioni per l’invocazione (ID del metodo e argomenti) e le invia allo skeleton in un messaggio 4. Lo skeleton riceve il messaggio ed effettua la deserializzazione dei dati ricevuti, invoca la chiamata sull’oggetto che implementa il server (dispatching), effettua la serializzazione del valore di ritorno e lo invia allo stub in un messaggio 5. Lo stub effettua la deserializzazione del valore di ritorno e restituisce il risultato al client Valeria Cardellini - SD A.A. 2011/12 84 • RMI Registry: è il binder per Java RMI (per default porta 1099) • Servizio di naming che consente al server di registrare i suoi oggetti remoti e al client di recuperarne i riferimenti associati • Funziona come punto di indirezione • Alcune limitazioni: non è trasparente alla locazione, non gestisce la sicurezza Valeria Cardellini - SD A.A. 2011/12 85 • Architettura a strati • Solo chiamate sincrone e bloccanti RMI Registry Client Server Stub Skeleton Remote Ref. Layer Remote Ref. Layer Transport Layer Transport Layer Java Virtual Machine Java Virtual Machine Rete Protocollo orientato alla connessione (TCP) Valeria Cardellini - SD A.A. 2011/12 86 • Remote Reference Layer – Fornisce il supporto alle chiamate inoltrate dallo stub – Definisce e supporta la semantica dell’invocazione e della comunicazione – Scambia dati con il Transport Layer • Transport Layer – Localizza il server RMI relativo all’oggetto remoto richiesto, gestisce le connessioni e le trasmissioni (sequenziali, serializzate) fra i diversi spazi di indirizzi (JVM diverse) – Usa un protocollo proprietario: Java Remote Method Protocol – Possibilità di utilizzare protocolli applicativi diversi, purché siano orientati alla connessione • Ad es. HTTP per poter invocare oggetti remoti che sono in esecuzione su macchine protette da firewall Valeria Cardellini - SD A.A. 2011/12 87 • Realizzare i componenti remoti lato server – Definizione del comportamento: interfaccia che • • • – Implementazione del comportamento: classe che • • • • Deve essere dichiarata public Deve estendere java.rmi.Remote Ogni metodo solleva l’eccezione java.rmi.RemoteException per proteggere l’applicazione da anomalie derivanti dall’utilizzo di risorse remote Implementa l’interfaccia definita Estende java.rmi.UnicastRemoteObject Occorre anche registrare il servizio, invocando il metodo bind/ rebind sul registry (nella classe java.rmi.Naming) Realizzare i componenti locali lato client ! Bisogna ottenere il riferimento all’oggetto remoto, invocando il metodo lookup sul registry Valeria Cardellini - SD A.A. 2011/12 • 88 Dopo aver sviluppato il codice, è necessario: 1. Compilare le classi sviluppate 2. A partire da Java SE 5, le classi per stub e skeleton sono generate dinamicamente • Per versioni precedenti, occorre usare il compilatore RMI rmic per pre-generare le classi stub e skeleton; inoltre, la classe stub deve essere localmente disponibile sul lato client 3. Attivare l’RMI registry manualmente (comando rmiregistry), che viene lanciato in un processo separato (rispetto a quello in cui è eseguito il server RMI) ed ha struttura e comportamento standard • In alternativa, si può creare all’interno del codice server un proprio registry locale tramite il metodo createRegistry (in java.rmi.registry) 4. Avviare il server 5. Avviare il client A questo punto l’interazione tra client e server può procedere Valeria Cardellini - SD A.A. 2011/12 89 • L’interfaccia estende l’interfaccia Remote • Ciascun metodo remoto – Deve lanciare una RemoteException public interface EchoInterface extends java.rmi.Remote{ String getEcho(String echo) throws java.rmi.RemoteException; } • L’invocazione dei metodi remoti non è completamente trasparente – Ha un solo parametro di uscita; nessuno, uno o più parametri di ingresso – I parametri di ingresso del metodo remoto possono essere • passati per valore, se sono tipi primitivi o oggetti che implementano l’interfaccia Serializable: serializzazione/ deserializzazione ad opera di stub/skeleton • oppure per riferimento, se sono oggetti Remote Valeria Cardellini - SD A.A. 2011/12 • 90 public class EchoRMIServer extends UnicastRemoteObject La classe che implementa il implements EchoInterface{ server //Costruttore – Estende la classe public EchoRMIServer() UnicastRemoteObject throws RemoteException – Implementa tutti i metodi definiti { super(); } nell’interfaccia //Implementazione del metodo remoto – Il metodo super()chiama il dichiarato nell’interfaccia costruttore della classe public String getEcho(String echo) UnicastRemoteObject che throws RemoteException esegue le inizializzazioni { return echo; } necessarie per consentire di public static void main(String[] args) { rimanere in attesa di richieste // Registrazione del servizio remote su una porta e poterle try gestire { EchoRMIServer serverRMI = new EchoRMIServer(); Naming.rebind(“EchoService”, serverRMI); } catch (Exception e) {e.printStackTrace(); System.exit(1); } } } Valeria Cardellini - SD A.A. 2011/12 91 • • • public class EchoRMIServer extends UnicastRemoteObject Nel metodo main si crea l’istanza dell’oggetto server; una implements EchoInterface{ volta creato, l’oggetto è pronto //Costruttore public EchoRMIServer() per accettare richieste remote throws RemoteException L’RMI registry locale al server { super(); } registra tutti i servizi //Implementazione del metodo remoto dichiarato nell’interfaccia – Metodi bind/rebind della public String getEcho(String echo) classe Naming (rebind throws RemoteException rimpiazza un binding già esistente) { return echo; } public static void main(String[] args) { – Tante bind/rebind quanti // Registrazione del servizio sono gli oggetti server da try registrare, ognuno con un { EchoRMIServer serverRMI = proprio nome logico new EchoRMIServer(); Registrazione nel servizio di Naming.rebind(“EchoService”, serverRMI); } naming offerto dall’RMI registry catch (Exception e) – bind/rebind solo su RMI {e.printStackTrace(); System.exit(1); } registry locale } } Valeria Cardellini - SD A.A. 2011/12 92 • Servizi acceduti tramite l’interfaccia, ottenuta con una lookup all’RMI registry • • public class EchoRMIClient { //Avvio del client RMI public static void main(String[] args) { Reperimento di un riferimento bufferedReader stdIn = remoto new BufferedReader( new InputStreamReader(System.in)); – Ossia un’istanza di stub try dell’oggetto remoto (non della { classe dello stub, che di solito si //Connessione al servizio RMI remoto assume già presente sul client) EchoInterface serverRMI = (EchoInterface) Naming.lookup(“EchoService”); Invocazione del metodo remoto //Interazione con l’utente String message, echo; – Chiamata sincrona bloccante System.out.print(“Messaggio? “); con i parametri specificati message = stdIn.readLine(); nell’interfaccia //Richiesta del servizio remoto echo = serverRMI.getEcho(message); System.out.println(“Echo: “+echo+”\n”); } catch (Exception e) Vedi esempio completo sul sito del corso Valeria Cardellini - SD A.A. 2011/12 {e.printStackTrace(); System.exit(1); } } } 93 • Lato server 1. Compilazione javac EchoInterface.java javac EchoRMIServer.java 2. Generazione stub e skeleton (necessaria solo prima di Java SE 5) rmic EchoRMIServer EchoRMIServer_Stub.class 3. Esecuzione lato server Avvio in background del registry: rmiregistry & Avvio del server: java EchoRMIServer • Lato client 1. Compilazione javac EchoRMIClient.java 2. Esecuzione lato client java EchoRMIClient Valeria Cardellini - SD A.A. 2011/12 94 • I metodi di un oggetto remoto possono essere invocati in modo concorrente da molteplici client – Dalla specifica: “Since remote method invocation on the same remote object may execute concurrently, a remote object implementation needs to make sure its implementation is thread-safe” • Per proteggere metodi remoti da accessi concorrenti “pericolosi” garantendo la thread safety occorre definire il metodo come synchronized • Esempio: metodo remoto che incrementa un valore Valeria Cardellini - SD A.A. 2011/12 95 • Usando Java RMI sviluppare il codice per l’interfaccia MathServices con i seguenti metodi remoti: public double sqroot (double value); public double square(double value); e sviluppare il client che invoca tali metodi remoti Valeria Cardellini - SD A.A. 2011/12 96 • SUN RPC: visione a processi; trasparenza all’accesso incompleta e no trasparenza all’ubicazione • Entità che si possono richiedere: solo operazioni o funzioni • Semantica di comunicazione (default): at-least-once • Modi di comunicazione: sincroni e asincroni • Durata massima ed eccezioni: timeout per ritrasmissione e casi di errore • Ricerca del server: port mapper sul server • Presentazione dei dati: IDL specifico (XDR) e generazione stub • Passaggio dei parametri: per copia-ripristino • Varie estensioni, tra cui broadcast (più risposte da molteplici server anziché una sola) e sicurezza Valeria Cardellini - SD A.A. 2011/12 97 • Java RMI: visione per sistemi ad oggetti; trasparenza all’accesso, no trasparenza all’ubicazione e non maschera totalmente la distribuzione (semantica passaggio parametri, interfacce ed eccezioni remote) • Entità che si possono richiedere: metodi di oggetti via interfacce • Semantica di comunicazione: at-most-once • Modi di comunicazione: solo sincroni • Durata massima ed eccezioni: trattamento di casi di errore • Ricerca del server: uso di registry • Presentazione dei dati: generazione stub e skeleton • Passaggio dei parametri: di default per valore (tipi di dato primitivi e oggetti serializable), nel caso di oggetti con interfacce remotizzabili per riferimento (oggetti remote) Valeria Cardellini - SD A.A. 2011/12 98 • RPC e RMI migliorano la trasparenza all’accesso • Ma non sono sempre meccanismi adatti a supportare la comunicazione in un SD – Ad es. quando non si può essere certi che il destinatario sia in esecuzione – La natura essenzialmente sincrona delle RPC comporta una perdita di efficacia nella comunicazione • Alternativa: comunicazione orientata ai messaggi – Di tipo transiente • Berkeley socket: già esaminata in altri corsi • Message Passing Interface (MPI) – Di tipo persistente • Sistemi a code di messaggi o Message Oriented Middleware (MOM) Valeria Cardellini - SD A.A. 2011/12 99 • Libreria per lo scambio di messaggi tra processi in esecuzione su nodi diversi – Specifica della sola interfaccia (http://www.mpi-forum.org/) – Diverse implementazioni, tra cui Open MPI (http:// www.open-mpi.org/) e MPICH (http://www.mcs.anl.gov/ research/projects/mpich2/) – Standard de facto per la comunicazione tra i nodi di un sistema che esegue un programma parallelo sviluppato per un’architettura a memoria distribuita • MPI definisce una serie di primitive per la comunicazione tra processi; in particolare: – Primitive per la comunicazione punto-punto: per l’invio e la ricezione di un messaggio tra due processi diversi – Primitive per la comunicazione collettiva Valeria Cardellini - SD A.A. 2011/12 100 • Principali primitive per la comunicazione punto-punto: – MPI_Send e MPI_Recv: comunicazione bloccante • MPI_Send con modalità sincrona o bufferizzata a seconda dell’implementazione – MPI_Bsend: invio bloccante bufferizzato – MPI_Ssend: invio sincrono bloccante – MPI_Isend e MPI_Irecv: comunicazione non bloccante Primitive MPI Significato MPI_Bsend Aggiunge un messaggio in uscita ad un buffer per l’invio MPI_Send Invia un messaggio e aspetta finché non viene copiato in un buffer locale o remoto MPI_Ssend Invia un messaggio e aspetta finché non inizia la ricezione MPI_Isend Invia il riferimento ad un messaggio in uscita e continua MPI_Recv Riceve un messaggio; si blocca se non ce ne sono Valeria Cardellini - SD A.A. 2011/12 101 #include <stdio.h> #include <string.h> #include <mpi.h> int main (int argc, char **argv) { int myrank; char message[20]; MPI_Status status; MPI_Init(&argc, &argv); MPI_Comm_rank(MPI_COMM_WORLD, &myrank); printf("Il mio rank e' : %d\n", myrank); if (myrank == 0) { MPI_Send(buf, count, datatype, //Invia un messaggio al processo 1 dest, tag, comm) strcpy(message, "PROVA"); MPI_Send(message, strlen(message)+1, MPI_CHAR, 1, 99, MPI_COMM_WORLD); printf("%d) Ho inviato: '%s'\n", myrank, message); } else if (myrank==1) { //Riceve il messaggio dal processo 0 MPI_Recv(message, 20, MPI_CHAR, 0, 99, MPI_COMM_WORLD, &status); printf("%d) Ho ricevuto: '%s'\n", myrank, message); } MPI_Finalize(); MPI_Recv(buf, count, datatype, return 0; source, tag, comm, status) } Valeria Cardellini - SD A.A. 2011/12 102 • Idea base di un MOM (o sistema a code di messaggi): le applicazioni distribuite comunicano inserendo messaggi in apposite code – Di solito ogni applicazione ha la sua coda privata (esistono anche code condivise da più applicazioni) – Eccellente supporto per comunicazioni persistenti e asincrone • Il mittente ha soltanto la garanzia che il suo messaggio venga inserito nella coda del destinatario – Nessuna garanzia che il destinatario prelevi il messaggio dalla sua coda – Disaccoppiamento temporale tra mittente e destinatario (già esaminato per publish/subscribe) • Un messaggio può contenere qualunque dato e deve essere indirizzato opportunamente – Nome univoco a livello del sistema Valeria Cardellini - SD A.A. 2011/12 103 • Principali primitive offerte dall’API di un MOM: – put: invio non bloccante di un messaggio • Il messaggio viene aggiunto ad una coda • Operazione asincrona ! come trattare il caso di coda piena? – get: ricezione bloccante di un messaggio • Si blocca finché la coda non è più vuota e preleva il primo messaggio (oppure si blocca in attesa di un messaggio specifico) • Operazione sincrona rispetto alla presenza di messaggi in coda – poll: ricezione non bloccante di un messaggio • Controlla se ci sono messaggi in una coda e rimuove il primo (oppure un messaggio specifico), senza bloccarsi – notify: ricezione non bloccante di un messaggio • Installa un handler (funzione di callback) che avvisa il destinatario quando viene inserito un messaggio in una coda • Il meccanismo di callback separa la coda dall’attivazione del destinatario Valeria Cardellini - SD A.A. 2011/12 104 • I messaggi possono essere inseriti/letti solo in/da code locali al mittente/destinatario – Inserimento in coda sorgente (o di invio) – Lettura da coda di destinazione (o di ricezione) – La coda appare locale sia al mittente che al destinatario (trasparenza della distribuzione) – E’ il sistema ad occuparsi del trasferimento dei messaggi • Il MOM deve mantenere la corrispondenza tra ogni coda e la sua posizione sulla rete (servizio di naming) Valeria Cardellini - SD A.A. 2011/12 105 • L’architettura generale di un • Il MOM realizza un overlay MOM scalabile richiede un network con topologia insieme di gestori (router o relay) propria e distinta specializzati nel servizio di routing dei messaggi da un – Occorre un servizio di routing gestore all’altro • Una sottorete connessa di router conosce la topologia della rete logica (statica) e si occupa di far pervenire il messaggio dalla coda del mittente a quella del destinatario • Topologie di rete complesse e variabili (scalabili) richiedono la gestione dinamica delle corrispondenze codaposizione di rete (analogia con routing in reti IP) Valeria Cardellini - SD A.A. 2011/12 106 • L’area di applicazione più importante dei MOM è l’integrazione di applicazioni in ambito aziendale (Enterprise Application Integration, EAI) – Le applicazioni devono essere in grado di interpretare il formato dei messaggi (struttura e rappresentazione dei dati) • Soluzioni possibili per gestire l’eterogeneità dei messaggi (3 su 4 già esaminate): – – – – Codifica del formato contenuta nel messaggio Ogni destinatario è in grado di comprendere ogni formato Formato comune dei messaggi Gateway di livello applicativo (broker) in grado di effettuare le conversioni tra formati diversi • La soluzione generalmente adottata nei MOM si basa sulla presenza di message broker Valeria Cardellini - SD A.A. 2011/12 107 • Gestisce l’eterogeneità delle applicazioni – Trasforma i messaggi in ingresso nel formato adatto all’applicazione destinataria, fornendo trasparenza di accesso ai messaggi – Gestisce un repository delle regole e dei programmi che consentono la conversione dei messaggi – Per ragioni di scalabilità la sua implementazione può essere distribuita broker Anche detta architettura Hub-and-Spoke • Esempi di MOM con broker – IBM WebSphere MQ – Microsoft Message Queueing (MSMQ) – Java Message Service (JMS): un’API MOM per Java Valeria Cardellini - SD A.A. 2011/12 108 • MOM molto diffuso (~40% del mercato) e supportato • I messaggi sono gestiti dai queue manager (QM) – Le applicazioni possono inserire/estrarre messaggi solo nelle/dalle code locali o attraverso un meccanismo RPC • Il trasferimento dei messaggi da una coda all’altra di QM diversi avviene tramite canali di comunicazione unidirezionali ed affidabili gestiti da message channel agent (MCA) che si occupano di tutti i i dettagli – Stabilire canali usando gli strumenti messi a disposizione dai protocolli di rete – Tipo di messaggi – Invio/ricezione dei pacchetti • Ogni canale ha una coda di invio Valeria Cardellini - SD A.A. 2011/12 109 • Il trasferimento sul canale può avvenire solo se entrambi gli MCA sono attivi – Il sistema MQ fornisce meccanismi per avviare automaticamente un MCA • Il routing è sotto il controllo di una gestione di sistema statica e non flessibile – L’amministratore stabilisce in fase di configurazione le opportune interconnessioni tra QM in tabelle di routing Valeria Cardellini - SD A.A. 2011/12 110 • Indirizzo di destinazione: nome del gestore di destinazione + nome della coda di destinazione • Elemento della tabella di routing: <destQM, sendQ> – destQM: nome del gestore di destinazione – sendQ: nome della coda d’invio locale • Quali sono i problemi del routing nel sistema MQ? Valeria Cardellini - SD A.A. 2011/12 111 • Per favorire l’integrazione di applicazioni, MQ Broker può intervenire sui messaggi – Trasformando formati – Attuando il content-based routing dei messaggi – Lavorando su informazioni di applicazione, per specificare sequenze di azioni Valeria Cardellini - SD A.A. 2011/12 112 • I tipi di comunicazione analizzati finora sono basati su uno scambio di unità di informazioni discreto, ovvero indipendente dal tempo – Le relazioni temporali tra i dati non sono fondamentali per l’interpretazione dei dati • Nei media continui i valori sono dipendenti dal tempo – Audio, video, animazioni, dati di sensori (temperatura, pressione, …) • Data stream: una sequenza (flusso) di unità di dati dipendenti dal tempo – Ad es. stream audio, stream video – Requisiti temporali espressi come requisiti di qualità del servizio (Quality of Service, QoS) Valeria Cardellini - SD A.A. 2011/12 113 • Vincoli temporali sulla modalità trasmissiva dei dati – Trasmissione asincrona • Preserva l’ordinamento, ma non la distanza temporale tra unità dati dello stream • Non ci sono quindi restrizioni temporali – Trasmissione sincrona • Preserva l’ordinamento e garantisce un tempo massimo di trasmissione per ogni unità dati dello stream – Trasmissione isocrona • Aggiunge rispetto alla modalità sincrona la garanzia di un tempo minimo di trasmissione ! bounded (delay) jitter Valeria Cardellini - SD A.A. 2011/12 114 • Definizione: consideriamo solo stream di dati continui con trasmissione isocrona • Alcune caratteristiche comuni – Gli stream sono unidirezionali – Generalmente c’è un’unica sorgente ed una o più destinazioni • Gli stream possono essere semplici o compositi • Stream semplici – Una semplice sequenza di dati • Stream compositi – Internamente strutturati e composti da stream semplici (substream), con requisiti temporali tra i substream che li compongono – Ad es. film con 1 substream video e 2 substream audio per effetto stereo – Problema di sincronizzazione Valeria Cardellini - SD A.A. 2011/12 115 • In uno stream è essenziale che siano preservate le relazioni temporali tra le unità dati • Il termine QoS (Quality of Service) è usato per descrivere i requisiti di un’applicazione verso una certa risorsa – Alcune applicazioni richiedono livelli minimi garantiti, altre richiedono qualità in termini statistici (es. elaborazione remota di immagini mediche vs. video entertainment) • Metriche per specificare la QoS a livello applicativo – Il bit rate a cui devono essere trasportati i dati – Il tempo massimo di set up di una sessione (quando un’applicazione può iniziare ad inviare dati) – Il tempo massimo di trasporto (quanto impiega un’unità di dati ad arrivare al destinatario) – La varianza massima del tempo di trasmissione (jitter) – Il tempo massimo di round-trip Valeria Cardellini - SD A.A. 2011/12 116 • Come garantire la QoS considerando che lo stack di protocolli Internet si basa su un servizio a datagram e di tipo best-effort? – A livello di rete – A livello applicativo • Esistono vari meccanismi a livello di rete – Ad es. DiffServ (Differentiated Services), un modello di servizio e relativa architettura con l’obiettivo di differenziare i servizi in Internet • Supportando meccanismi di classificazione del traffico • I pacchetti possono essere trattati con diversa priorità, ad es. classi di inoltro rapido ed inoltro assicurato • Non necessariamente supportato dai router Valeria Cardellini - SD A.A. 2011/12 117 • Uso di buffer per ridurre lo jitter • Uso del frame interleaving per ridurre gli effetti della perdita dei pacchetti (quando più frame sono nello stesso pacchetto) Trasmissione noninterleaved Trasmissione interleaved Valeria Cardellini - SD A.A. 2011/12 118 • Problema: dato uno stream composito, come mantenere la sincronizzazione tra i diversi stream semplici componenti? – Ad es. effetto stereo con due canali audio: la differenza di sincronizzazione tra i due substream deve essere inferiore a 20-30 µsec! • Soluzione possibile: sincronizzazione esplicita – Applicazione del principio dell’algoritmo token bucket usato per il filtraggio del traffico Valeria Cardellini - SD A.A. 2011/12 119 • Comunicazione multicast: schema di comunicazione in cui i dati sono inviati a molteplici destinatari – Comunicazione broadcast: caso particolare della multicast, in cui i dati sono spediti a tutti i destinatari connessi in rete – Esempi di applicazioni multicast one-to-many: distribuzione di risorse audio/video, distribuzione di file – Esempi di applicazioni multicast many-to-many: servizi di conferenza, giochi multiplayer, simulazioni distribuite interattive Unicast di un video a 1000 utenti Multicast di un video a 1000 utenti Valeria Cardellini - SD A.A. 2011/12 120 • Multicast a livello di protocolli di rete – Multicast a livello IP basato sui gruppi • Gruppo: host interessati alla stessa applicazione multicast • Indirizzo IP di classe D assegnato al gruppo – La replicazione dei pacchetti e il routing sono gestiti dai router – Uso limitato nelle applicazioni per: • mancanza di uno sviluppo su larga scala (solo circa 5% degli AS supporta il multicast) • problema di tener traccia dell’appartenenza ad un gruppo • Multicast a livello applicativo – La replicazione dei pacchetti e il routing sono gestiti dagli end host – Strutturato: creazione di percorsi di comunicazione espliciti – Non strutturato: basato su gossip Valeria Cardellini - SD A.A. 2011/12 121 • Idea di base del multicasting applicativo – Organizzare i nodi in una rete overlay – Usare tale rete overlay per diffondere le informazioni • Come costruire la rete overlay? – Nodi organizzati in un albero • Unico percorso tra ogni coppia di nodi – Nodi organizzati in una mesh (rete a maglia) • Molti percorsi tra ogni coppia di nodi Valeria Cardellini - SD A.A. 2011/12 122 • Esempio: costruzione di un albero per il multicasting applicativo in Scribe – Scribe: sistema publish/subscribe decentralizzato basato su Pastry – Pastry: rete P2P strutturata basata su DHT 1. Il nodo che inizia la sessione multicast genera l’identificatore, detto groupId, del gruppo di multicast 2. Cerca (tramite Pastry) il nodo responsabile per groupId 3. Tale nodo diventa la radice dell’albero di multicast 4. Se il nodo P vuole unirsi all’albero di multicast identificato da groupId invia una richiesta di JOIN 5. Quando la richiesta di JOIN arriva al nodo Q • Q non ha mai ricevuto una richiesta di JOIN per groupId Q diventa forwarder, P diventa figlio di Q e Q inoltra la richiesta di JOIN verso la radice • oppure Q è già un forwarder per groupId P diventa figlio di Q; non occorre inoltrare la richiesta di JOIN alla radice Riferimento: M. Castro et al., “SCRIBE: A large-scale and decentralised application-level multicast infrastructure”, IEEE JSAC, Oct. 2002. Valeria Cardellini - SD A.A. 2011/12 123 forwarder radice forwarder join() join() forwarder radice forwarder forwarder radice forwarder forwarder join() Valeria Cardellini - SD A.A. 2011/12 124 • Stress sui collegamenti: quante volte un messaggio di multicasting applicativo attraversa lo stesso collegamento fisico? – Esempio: il messaggio da A a D attraversa <Ra,Rb> due volte • Stretch: rapporto tra il tempo di trasferimento nell’overlay network e quello nella rete sottostante – Esempio: i messaggi da B a C seguono un percorso con costo 71 a livello applicativo, ma 47 a livello di rete stretch=71/47 Valeria Cardellini - SD A.A. 2011/12 125 • Protocolli di tipo probabilistico, detti anche epidemici o di gossiping – Essendo basati sulla teoria della diffusione delle epidemie o del gossip nelle reti sociali • Permettono la rapida diffusione delle informazioni in reti a larghissima scala attraverso la scelta casuale dei destinatari successivi tra quelli noti al mittente – Ogni nodo, per inviare un messaggio, recapita il messaggio ad un sottoinsieme, scelto casualmente, dei nodi nella rete – Ogni nodo che lo riceve ne rinvierà una copia ad un altro sottoinsieme, anch’esso scelto casualmente, e così via • Caratteristiche della diffusione delle informazioni basata su gossip – Scalabilità: ogni nodo invia soltanto un numero limitato di messaggi, indipendentemente dalla dimensione complessiva della rete – Affidabilità e robustezza: grazie alla ridondanza dei messaggi Valeria Cardellini - SD A.A. 2011/12 126 • Definiti nel 1987 di Demers et al. in un lavoro sulla garanzia di consistenza nei database replicati • Idea di base: assumendo che non vi siano conflitti di scrittura – Le operazioni di aggiornamento sono eseguite inizialmente su una o alcune repliche – Una replica comunica il suo stato aggiornato ad un numero limitato di vicini – La propagazione dell’aggiornamento è lazy (non immediata) – Al termine, ogni aggiornamento dovrebbe raggiungere tutte le repliche Riferimento: A. Demers et al., “Epidemic Algorithms for Replicated Database Maintenance”, Proc. 6th Symp. on Principles of Distributed Computing, pp. 1-12, Aug. 1987. ACM. Valeria Cardellini - SD A.A. 2011/12 127 • Principi di funzionamento: anti-entropia e gossiping • Anti-entropia: modello di propagazione in cui ciascuna replica sceglie a caso un’altra replica e si scambiano gli aggiornamenti, giungendo al termine ad uno stato identico su entrambe • Gossiping: una replica che è stata appena aggiornata (ossia infettata) contatta un certo numero di repliche scelte casualmente inviandogli il proprio aggiornamento (infettandole a loro volta) Valeria Cardellini - SD A.A. 2011/12 128 • Un nodo P sceglie casualmente un altro nodo Q nel sistema scelta • Tre strategie di aggiornamento: – push: P invia soltanto i suoi aggiornamenti a Q – pull: P si prende soltanto i nuovi aggiornamenti da Q – push-pull: P e Q si scambiano reciprocamente gli aggiornamenti (dopodiché possiedono le stesse informazioni) dati scelta dati scelta dati • Osservazione: la strategia push-pull impiega solo O(log(N)) round per propagare un singolo aggiornamento a tutti gli N nodi del sistema – Round: intervallo di tempo in cui ogni nodo ha preso almeno una volta l’iniziativa di scambiare aggiornamenti Valeria Cardellini - SD A.A. 2011/12 129 • Modello di base: un nodo P che è stato appena aggiornato, contatta un nodo Q scelto a caso; se Q ha già ricevuto l’aggiornamento (è già infetto), P smette con probabilità 1/k di contattare altri nodi • Se s è la frazione di nodi non ancora aggiornati, si dimostra che s = e!(k+1)(1!s) • Per garantire che tutti i nodi siano aggiornati, occorre combinare il gossiping puro con l’anti-entropia Valeria Cardellini - SD A.A. 2011/12 130 • Due peer P e Q, con P che ha scelto Q per lo scambio di dati Active thread (peer P): (1) selectPeer(&Q); (2) selectToSend(&bufs); (3) sendTo(Q, bufs); (4) (5) receiveFrom(Q, &bufr); (6) selectToKeep(cache, bufr); (7) processData(cache); -----> <----- Passive thread (peer Q): (1) (2) (3) receiveFromAny(&P, &bufr); (4) selectToSend(&bufs); (5) sendTo(P, bufs); (6) selectToKeep(cache, bufr); (7) processData(cache) • Quali sono gli aspetti cruciali? – La selezione dei peer – La selezione dei dati scambiati – Il processamento dei dati ricevuti Riferimento: A.-M. Kermarrec, M. van Steen, “Gossiping in Distributed Systems”, ACM Operating System Review 41(5), Oct. 2007. Valeria Cardellini - SD A.A. 2011/12 131 • La diffusione dell’informazione è l’applicazione classica e più popolare del gossiping nei SD – Valida alternativa rispetto al flooding • Nel caso di flooding – Ogni nodo che riceve il messaggio lo invia a tutti i suoi vicini – Il messaggio viene scartato quando il suo TTL diviene nullo Round 2 Round 1 Round 3 Messaggi inviati: 18 Nodi raggiunti: 8 su 9 Valeria Cardellini - SD A.A. 2011/12 132 • Nel caso di gossiping semplice – Il messaggio viene inviato con una probabilità di gossiping p for each messaggio m if random(0,1) < p then invia m Round 1 p p Round 2 p Round 3 p p p p p p p p Valeria Cardellini - SD A.A. 2011/12 Messaggi inviati: 11 Nodi raggiunti: 6 su 9 133 • Oltre alla diffusione dell’informazione… • Peer sampling – Per fornire a ciascun peer una lista di peer da contattare • Monitoring di nodi e risorse in sistemi distribuiti a larga scala • Computazioni distribuite per l’aggregazione di dati, in particolare in reti di sensori – Computazione di valori aggregati (ad es. somma, media, massimo, quantili) – Ad es. nel caso di calcolo della media • Siano x0,i e x0,j i valori al tempo t=0 posseduti dai nodi i e j • Dopo il gossiping tra i e j: x1,i,x1,j "(x0,i + x0,j)/2 Valeria Cardellini - SD A.A. 2011/12 134