Comunicazione nei Sistemi Distribuiti

Transcript

1 Università degli Studi di Roma Tor Vergata Dipartimento di Ingegneria Civile e Ingegneria Informatica Comunicazione nei Sistemi Distribuiti Corso di Sistemi Distribuiti e Cloud Computing A.A. 2013/14 Valeria Cardellini Comunicazione nei SD 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 - SDCC 2013/14 1

2 Protocolli a livelli 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 - SDCC 2013/14 2 Protocolli middleware 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 - SDCC 2013/14 3

3 Tipi di comunicazione Distinguiamo la comunicazione in base a: Persistenza Comunicazione persistente o transiente Sincronizzazione Comunicazione sincrona o asincrona Dipendenza dal tempo Comunicazione discreta o streaming Valeria Cardellini - SDCC 2013/14 4 Comunicazione persistente o transiente 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, ma cancellano se non è possibile inoltrare Valeria Cardellini - SDCC 2013/14 5

4 Comunicazione sincrona 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? Varie alternative: 1. finché il middleware non prende il controllo della trasmissione 2. finché il messaggio non viene consegnato al destinatario 3. finché il messaggio non viene elaborato dal destinatario Valeria Cardellini - SDCC 2013/14 6 Comunicazione asincrona 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 - SDCC 2013/14 7

5 Comunicazione discreta o streaming 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 - SDCC 2013/14 8 Tipi di comunicazione e loro combinazione Quali sono le possibili combinazioni reali tra persistenza e sincronizzazione? a) Comunicazione persistente e asincrona Ad es., posta elettronica b) Comunicazione persistente e sincrona Mittente bloccato fino alla copia (garantita) del messaggio presso il destinatario c) Comunicazione transiente e asincrona Mittente non attende ma messaggio perso se destinatario non raggiungibile (ad es. UDP) Comunicazione transiente e sincrona d) mittente bloccato fino alla copia (non garantita) del messaggio nello spazio del destinatario (ad es. RPC asincrona) e) mittente bloccato fino alla consegna del messaggio al destinatario f) mittente bloccato fino alla ricezione di un messaggio di risposta dal destinatario (ad es. RPC sincrona e RMI) Valeria Cardellini - SDCC 2013/14 9

6 Persistent communication Persistent asynchronous communication Persistent synchronous communication Valeria Cardellini - SDCC 2013/14 10 Transient communication Transient asynchronous communication Receipt-based synchronous communication Valeria Cardellini - SDCC 2013/14 11

7 Transient communication (2) Delivery-based synchronous communication Response-based synchronous communication Valeria Cardellini - SDCC 2013/14 12 Semantica della comunicazione ed errori Diverse tipologie di failure nella comunicazione tra client e server 1. Il messaggio di richiesta e/o risposta può andare perduto Da The Eight Fallacies of Distributed Computing : la rete è affidabile 2. Il server può subire un crash Prima dell esecuzione del servizio richiesto Dopo l esecuzione del servizio richiesto 3. Il client può subire un crash Valeria Cardellini - SDCC 2013/14 13

8 Semantica della comunicazione ed errori (2) 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/risultati di una sola esecuzione dell operazione Valeria Cardellini - SDCC 2013/14 14 Semantica may-be Semantica may-be (forse) Il messaggio può arrivare o meno Non si attuano azioni per garantire l affidabilità della comunicazione: nessun meccanismo (RR1, DF, RR2) in uso Ad es. best-effort in IP o UDP Client Server Invio richiesta Messaggio richiesta PERSO Messaggio risposta Processamento Invio risposta Valeria Cardellini - SDCC 2013/14 15

9 Semantica at-least-once 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 Il server può aver eseguito l operazione ma subire un crash prima dell invio della risposta: allo scadere del timeout il client invia la stessa richiesta ed il server esegue nuovamente l operazione ed invia la risposta al client Valeria Cardellini - SDCC 2013/14 16 Semantica at-least-once (2) Client Invio richiesta Messaggio richiesta Server timeout Invio richiesta timeout Invio richiesta timeout PERSO Ritrasmetti messaggio richiesta Messaggio risposta PERSO Ritrasmetti messaggio richiesta Messaggio risposta Processamento Invio risposta Processamento Invio risposta Valeria Cardellini - SDCC 2013/14 17

10 Semantica at-most-once 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 caso di guasto permanente 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 - SDCC 2013/14 18 Semantica at-most-once (2) Client Invio richiesta Messaggio richiesta Server timeout Invio richiesta timeout Invio richiesta timeout 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 - SDCC 2013/14 19

11 Semantica exactly-once Semantica exactly-once (esattamente una volta) E lo scenario migliore ma di difficile attuazione in un sistema distribuito 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 sulla durata massima del protocollo No durata massima: semantica scarsamente praticabile in un sistema reale Ha bisogno di ulteriori meccanismi per tollerare guasti lato server Replicazione trasparente, write-ahead logging e recovery Valeria Cardellini - SDCC 2013/14 20 Programmazione di applicazioni di rete 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 - SDCC 2013/14 21

12 Programmazione di applicazioni di rete (2) 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 marshalling and external data representation Middleware layers UDP and TCP Valeria Cardellini - SDCC 2013/14 22 Requisiti del middleware di comunicazione 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 - SDCC 2013/14 23

13 Problemi 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 - SDCC 2013/14 24 Eterogeneità nella rappresentazione dei dati Client e server potrebbero usare una diversa codifica dei dati, ad es.: Codifica dei 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 - SDCC 2013/14 25

14 Eterogeneità nella rappresentazione dei dati 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 - SDCC 2013/14 26 Binding del server 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 - SDCC 2013/14 27

15 Binding dinamico 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 - SDCC 2013/14 28 Binding dinamico (2) 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 - SDCC 2013/14 29

16 Chiamata a procedura remota 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 - SDCC 2013/14 30 Chiamata a procedura remota (2) L idea di RPC è stata sviluppata in molte tecnologie progettate nel corso degli anni, tra cui: Java RMI SOAP ZeroC Ice Prestazioni ottimizzate, vedi Microsoft.NET CORBA Distributed Ruby (DRb) Remote Python Call (RPyC) JSON-RPC Valeria Cardellini - SDCC 2013/14 31

17 Chiamata di una procedura Procedura p locale Procedura p remota Valeria Cardellini - SDCC 2013/14 32 Chiamata di una procedura locale Esempio di chiamata locale (convenzionale): count = read(fd, buf, nbytes) La procedura chiamante inserisce nello 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 - SDCC 2013/14 33

18 Modello con stub (adattatore) Il cliente invoca uno stub (client stub), che si incarica di tutto: Dall identificazione del server alla gestione dei parametri, dalla richiesta al supporto run-time all invio della richiesta Il server riceve la richiesta dallo stub relativo (server stub), che gestisce i parametri dopo avere ricevuto la richiesta dal livello di trasporto. Al completamento del servizio, il server stub invia 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 Architettura RPC Valeria Cardellini - SDCC 2013/14 34 Passi di una RPC 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 - SDCC 2013/14 35

19 Passi di una RPC (2) Esempio con passaggio di parametri per valore add(i, j) Valeria Cardellini - SDCC 2013/14 36 Problemi RPC 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 - SDCC 2013/14 37

20 Rappresentazione dei dati 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 - SDCC 2013/14 38 IDL per RPC 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 - SDCC 2013/14 39

21 Tipi di passaggio dei parametri 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 - SDCC 2013/14 40 Problemi per il passaggio di parametri 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 - SDCC 2013/14 41

22 RPC asincrona 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 - SDCC 2013/14 42 RPC asincrona (2) 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 Se il client riprende l esecuzione senza aspettare l ack, la RPC asincrona è detta a senso unico RPC sincrona differita Valeria Cardellini - SDCC 2013/14 43

23 Implementazione del middleware RPC 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 di dati Remote Procedure Call GENerator (RPCGEN): generazione client stub 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 - SDCC 2013/14 44 Riferimenti per SUN RPC man rpc man rpcgen Capitolo 16 di W.R. Stevens, Unix Network Programming, Volume 2: Interprocess Communication, E. Petron, Remote Procedure Calls, Linux Journal, Valeria Cardellini - SDCC 2013/14 45

24 SUN RPC e stack OSI Valeria Cardellini - SDCC 2013/14 46 Definizione del programma RPC 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 - SDCC 2013/14 47

25 Definizione della procedura remota 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 */ } = 0x ; /* 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 - SDCC 2013/14 48 Implementazione del programma RPC 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 - SDCC 2013/14 49

26 RPC: un semplice esempio 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 - SDCC 2013/14 50 RPC: un semplice esempio (2) 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 - SDCC 2013/14 51

27 Sviluppo della procedura di servizio 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 - SDCC 2013/14 52 Sviluppo della procedura di servizio (2) 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 - SDCC 2013/14 53

28 Sviluppo della procedura di servizio (3) 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 - SDCC 2013/14 54 Sviluppo del programma client 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 - SDCC 2013/14 55

29 Sviluppo del programma client (2) 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 - SDCC 2013/14 56 Sviluppo del programma client (3) 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: nome dell host remoto su cui è in esecuzione il servizio 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: parametro di ingresso vero e proprio 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 - SDCC 2013/14 57

30 Passi di base per lo sviluppo di SUN RPC 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 - SDCC 2013/14 58 Caratteristiche di SUN RPC 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 - SDCC 2013/14 59

31 Identificazione di messaggi RPC 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: [0x , 0x1fffffff]: predefinito da Sun; per applicazioni d'interesse comune [0x , 0x3fffffff]: definibile dall utente [0x , 0x5fffffff]: transitorio, riservato alle applicazioni [0x6fffffff, 0xffffffff]: per estensioni future Valeria Cardellini - SDCC 2013/14 60 Livelli di SUN RPC 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) Diversi livelli di astrazione: tradeoff tra flessibilità nel controllo e quantità di codice da sviluppare Valeria Cardellini - SDCC 2013/14 61

32 Livelli di SUN RPC (2) 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 - SDCC 2013/14 62 Livelli di SUN RPC (3) Livello basso: gestione avanzata del protocollo RPC Chiamata remota tramite funzioni avanzate per ottenere la massima capacità espressiva Valeria Cardellini - SDCC 2013/14 63

33 external Data Rapresentation (XDR) 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 - SDCC 2013/14 64 Definizione del file.x 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 0x 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 - SDCC 2013/14 65

34 Server: registrazione procedura 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 - SDCC 2013/14 66 Port mapper 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 - SDCC 2013/14 67

35 Port mapper (2) 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 port tcp 111 portmapper udp 111 portmapper udp tcp Nell output: (= 0x ) è il numero di programma in square.x /etc/rpc contiene l elenco dei programmi RPC disponibili Valeria Cardellini - SDCC 2013/14 68 Processo di sviluppo Data una specifica di partenza file di linguaggio XDR square.x RPCGEN produce header file square.h client stub square_clnt.c server stub square_svc.c routine XDR square_xdr.c Lo sviluppatore scrive programma client client.c programma server server.c Valeria Cardellini - SDCC 2013/14 69

36 File prodotti da rpcgen: square.h /* * Please do not edit this file. * It was generated using rpcgen. */ #ifndef _SQUARE_H_RPCGEN #define _SQUARE_H_RPCGEN #include <rpc/rpc.h> #ifdef cplusplus extern "C" { #endif struct square_in { long arg1; }; typedef struct square_in square_in; struct square_out { long res1; }; typedef struct square_out square_out; Incluso dai due stub In caso di nuovi tipi di dato occorre definire le nuove strutture dati per le quali saranno generate in automatico le nuove funzioni di trasformazione #define SQUARE_PROG 0x #define SQUARE_VERS 1 Esempio: square.h Valeria Cardellini - SDCC 2013/14 70 File prodotti da rpcgen: square.h (2) #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 Esempio: square.h #endif /*!_SQUARE_H_RPCGEN */ Valeria Cardellini - SDCC 2013/14 71

37 File prodotti da rpcgen: square_xdr.c /* * Please do not edit this file. * It was generated using rpcgen. */ #include "square.h bool_t xdr_square_in (XDR *xdrs, square_in *objp) { } if (!xdr_long (xdrs, &objp->arg1)) return FALSE; return TRUE; bool_t xdr_square_out (XDR *xdrs, square_out *objp) { } if (!xdr_long (xdrs, &objp->res1)) return FALSE; return TRUE; Esempio: square_xdr.c Valeria Cardellini - SDCC 2013/14 72 File prodotti da rpcgen: client stub /* * 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 }; Timeout per la chiamata square_out * squareproc_1(square_in *argp, CLIENT *clnt) { static square_out clnt_res; } 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); } return (&clnt_res); Esempio: square_clnt.c Valeria Cardellini - SDCC 2013/14 73

38 File prodotti da rpcgen: server stub /* * 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; xdrproc_t _xdr_argument, _xdr_result; char *(*local)(char *, struct svc_req *); Esempio: square_svc.c Valeria Cardellini - SDCC 2013/14 74 File prodotti da rpcgen: server stub (2) 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 - SDCC 2013/14 75

39 } File prodotti da rpcgen: server stub (3) if (!svc_freeargs (transp, (xdrproc_t) _xdr_argument, (caddr_t) &argument)) { fprintf (stderr, "%s", "unable to free arguments"); exit (1); } return; int main (int argc, char **argv) { register SVCXPRT *transp; 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)."); exit(1); } Esempio: square_svc.c Distrugge eventuali registrazioni precedenti con lo stesso numero di programma e versione Associa la tripla {prognum, versnum, protocol} alla procedura di dispatching che implementa i vari servizi Valeria Cardellini - SDCC 2013/14 76 } File prodotti da rpcgen: server stub (4) 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); } svc_run(); fprintf (stderr, "%s", "svc_run returned"); exit (1); /* NOTREACHED */ Entra nel ciclo infinito di attesa e servizio della chiamata Esempio: square_svc.c Valeria Cardellini - SDCC 2013/14 77

40 Esempi RPC 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 - SDCC 2013/14 78 Riferimenti per Java RMI Trail: RMI, W. Grosso, Java RMI, O Reilly, Valeria Cardellini - SDCC 2013/14 79

41 Java RMI: motivazioni 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 invocare un metodo (di un interfaccia remota) su un oggetto remoto 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 altro host Obiettivo: rendere il più possibile simili l invocazione locale e quella remota Valeria Cardellini - SDCC 2013/14 80 Java RMI: generalità Localmente viene creato solo il riferimento ad un oggetto remoto, che è effettivamente attivo su un host remoto Il client invoca i metodi remoti attraverso il riferimento locale Quali sono le differenze rispetto all invocazione di un metodo locale? Affidabilità, semantica della comunicazione, durata, A remote invocation B local C invocation local E invocation local invocation D remote invocation F Valeria Cardellini - SDCC 2013/14 81

42 Java RMI: generalità (2) 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! remoteobject Data remote interface m1 m2 implementation { m3 of methods m4 m5 m6 Valeria Cardellini - SDCC 2013/14 82 Java RMI: generalità (3) Al binding di un client con un oggetto server distribuito, una copia dell interfaccia del server (stub) viene caricata nello spazio del client Ruolo analogo al client stub in ambiente RPC La richiesta in arrivo all oggetto remoto viene trattata da un agente del client, locale al server (skeleton) Ruolo al 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 - SDCC 2013/14 83

43 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 Stub e skeleton Stub e skeleton rendono possibile la chiamata di un servizio remoto come se fosse locale, agendo da proxy Sono generati automaticamente Valeria Cardellini - SDCC 2013/14 84 Serializzazione/deserializzazione (De)serializzazione supportata direttamente da Java Grazie all uso del bytecode, non c è bisogno di (un)marshaling come in RPC, ma i dati vengono (de)serializzati utilizzando le funzionalità offerte direttamente a livello di linguaggio Serializzazione: trasformazione di oggetti complessi in semplici 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 Stub e skeleton utilizzano queste due funzionalità per lo scambio dei parametri di ingresso e uscita con l host remoto Valeria Cardellini - SDCC 2013/14 85

44 Serializzazione/deserializzazione (2) Esempio di oggetto serializzabile Record con scrittura su stream Record record = new Record(); FileOutputStream fos = new FileOutputStream( data.ser ); ObjectOutputStream oos = new ObjectOutputStream(fos); oos.writeobject(record); FileInputStream fis = new FileInputStream( data.ser ); ObjectInputStream ois = new ObjectInputStream(fis); record = (Record)ois.readObject(); Si possono usare soltanto istanze di oggetti serializzabili, ovvero che: implementano l interfaccia Serializable contengono esclusivamente oggetti (o riferimenti a oggetti) serializzabili Alla deserializzazione sarà ricreata una copia dell istanza trasmessa usando il.class (deve essere accessibile!) dell oggetto e le informazioni ricevute Valeria Cardellini - SDCC 2013/14 86 Interazione tra stub e skeleton Passi per la comunicazione 1. Il client ottiene un istanza dello stub (come?) 2.Il client invoca i metodi sullo stub La sintassi di una invocazione remota è identica a quella locale 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 - SDCC 2013/14 87

45 RMI Registry: 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 RMI registry Valeria Cardellini - SDCC 2013/14 88 Architettura Java RMI Architettura a strati Solo chiamate sincrone e bloccanti Client RMI Registry 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 - SDCC 2013/14 89

46 Architettura Java RMI (2) 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 di dati (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 - SDCC 2013/14 90 Passi essenziali per l uso l di Java RMI Realizzare i componenti remoti lato server Definizione del comportamento: interfaccia che E dichiarata public per poter essere utilizzata da altre JVM Estende java.rmi.remote Ogni metodo remoto deve sollevare l eccezione java.rmi.remoteexception per proteggere l applicazione da anomalie derivanti da rete o indisponibilità del server (può anche sollevare eccezioni specifiche dell applicazione) Implementazione del comportamento: classe che Implementa l interfaccia definita Estende java.rmi.unicastremoteobject unicast perché viene definito il riferimento ad un solo oggetto remoto Codice del server: Istanzia l oggetto remoto Lo registra presso l RMI registry, invocando il metodo bind/rebind (in java.rmi.naming) Valeria Cardellini - SDCC 2013/14 91

47 Passi essenziali per l uso l di Java RMI (2) Realizzare i componenti locali lato client! Ottiene il riferimento all oggetto remoto, invocando il metodo lookup sul registry Lo assegna ad una variabile che ha l interfaccia remota come tipo Valeria Cardellini - SDCC 2013/14 92 Passi per l utilizzo l di Java RMI (2) 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 automaticamente a runtime Per SE precedenti, si usa il compilatore RMI rmic per pregenerare le classi stub e skeleton; inoltre, la classe stub deve essere localmente disponibile sul 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) Registry locale al server per motivi di sicurezza 4. Avviare il server 5. Avviare il client A questo punto l interazione tra client e server può procedere Valeria Cardellini - SDCC 2013/14 93

48 Esempio echo: : interfaccia L interfaccia estende l interfaccia Remote Ciascun metodo remoto Deve lanciare una RemoteException Per le eccezioni relative a failure durante la comunicazione L invocazione dei metodi remoti non è completamente trasparente import java.rmi.remote; import java.rmi.remoteexception; public interface EchoInterface extends Remote{ String getecho(string echo) throws RemoteException; Un solo parametro di uscita; nessuno, uno o più parametri di ingresso Passaggio dei parametri di ingresso del metodo remoto: per valore, se sono tipi primitivi (boolean, char, int, ) o oggetti che implementano l interfaccia java.io.serializable: serializzazione/deserializzazione ad opera di stub/skeleton per riferimento, se sono oggetti Remote Valeria Cardellini - SDCC 2013/14 94 } La classe che implementa il server Estende la classe UnicastRemoteObject Implementa tutti i metodi definiti nell interfaccia Il metodo super()chiama il costruttore della classe UnicastRemoteObject che esegue le inizializzazioni necessarie per consentire di rimanere in attesa di richieste su una porta e gestirle Esempio echo: : server public class EchoRMIServer extends UnicastRemoteObject implements EchoInterface{ //Costruttore public EchoRMIServer() throws RemoteException { super(); } //Implementazione del metodo remoto dichiarato nell interfaccia public String getecho(string echo) throws RemoteException { return echo; } public static void main(string[] args) { // Registrazione del servizio try { EchoRMIServer serverrmi = new EchoRMIServer(); Naming.rebind( EchoService, serverrmi); } catch (Exception e) {e.printstacktrace(); System.exit(1); } } } Valeria Cardellini - SDCC 2013/14 95

49 In main si crea l istanza dell oggetto server; una volta creato, l oggetto è pronto per accettare richieste remote L RMI registry locale al server registra i servizi Metodi bind/rebind della classe Naming (rebind rimpiazza un binding già esistente) Tante bind/rebind quanti sono gli oggetti server da registrare, ognuno con un proprio nome logico Registrazione nel servizio di Esempio echo: : server (2) naming offerto dall RMI registry bind/rebind solo su RMI registry locale per motivi di sicurezza public class EchoRMIServer extends UnicastRemoteObject implements EchoInterface{ //Costruttore public EchoRMIServer() throws RemoteException { super(); } //Implementazione del metodo remoto dichiarato nell interfaccia public String getecho(string echo) throws RemoteException { return echo; } public static void main(string[] args) { // Registrazione del servizio try { EchoRMIServer serverrmi = new EchoRMIServer(); Naming.rebind( EchoService, serverrmi); } catch (Exception e) {e.printstacktrace(); System.exit(1); } } } Valeria Cardellini - SDCC 2013/14 96 Servizi acceduti tramite l interfaccia, ottenuta tramite lookup all RMI registry Reperimento di un riferimento remoto Ossia un istanza di stub dell oggetto remoto (non della classe dello stub, che di solito si assume già presente sul client) Invocazione del metodo remoto Chiamata sincrona bloccante con i parametri specificati nell interfaccia Esempio completo sul sito del corso Esempio echo: client public class EchoRMIClient { //Avvio del client RMI public static void main(string[] args) { bufferedreader stdin = new BufferedReader( new InputStreamReader(System.in)); try { //Connessione al servizio RMI remoto EchoInterface serverrmi = (EchoInterface) Naming.lookup( EchoService ); //Interazione con l utente String message, echo; System.out.print( Messaggio? ); message = stdin.readline(); //Richiesta del servizio remoto echo = serverrmi.getecho(message); System.out.println( Echo: +echo+ \n ); } catch (Exception e) {e.printstacktrace(); System.exit(1); } } } Valeria Cardellini - SDCC 2013/14 97

50 Esempio echo: : compilazione ed esecuzione Lato server 1. Compilazione javac EchoInterface.java javac EchoRMIServer.java 2. Generazione stub e skeleton (necessaria solo prima di Java SE 5) rmic EchoRMIServer 3. Esecuzione lato server Avvio in background del registry: Avvio del server: java EchoRMIServer EchoRMIServer_Stub.class rmiregistry & Lato client 1. Compilazione javac EchoRMIClient.java 2. Esecuzione lato client java EchoRMIClient Valeria Cardellini - SDCC 2013/14 98 In locale: Passaggio dei parametri Per valore: tipi primitivi Per riferimento: tutti gli oggetti Java (tramite indirizzo) In remoto (problemi nel riferimento/indirizzo): Per valore: tipi primitivi e Serializable Object Oggetti la cui locazione non è rilevante per lo stato sono passati per valore: ne viene serializzata l istanza che sarà deserializzata a destinazione per crearne una copia locale Per riferimento remoto: Remote Object via RMI Oggetti la cui funzione è strettamente legata alla località in cui eseguono (server) sono passati per riferimento: ne viene serializzato lo stub, creato automaticamente a partire dalla classe dello stub. Ogni istanza di stub identifica l oggetto remoto al quale si riferisce attraverso un identificativo (ObjID) che è univoco rispetto alla JVM dove l oggetto remoto si trova Valeria Cardellini - SDCC 2013/14 99

51 Concorrenza su oggetti remoti 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 - SDCC 2013/ Distributed garbage collection Java RMI si pone il problema di eliminare gli oggetti remoti che non sono più riferiti Allo scopo l oggetto remoto deve conoscere in ogni istante quanti stub lo stanno riferendo Ma sono possibili guasti di rete, crash del client, Per risolvere questo problema, RMI richiede un alto grado di coordinamento, che è adatto solo per sistemi locali di piccole dimensioni: analizziamo perché Valeria Cardellini - SDCC 2013/14 101

52 Distributed garbage collection (2) Java RMI utilizza un algoritmo di garbage collection basato sul conteggio dei riferimenti Ogni JVM aggiorna una serie di contatori, ciascuno associato ad un determinato oggetto Ogni contatore rappresenta il numero dei riferimenti ad un certo oggetto che in quel momento sono attivi nella JVM Ogni volta che viene creato un riferimento ad un oggetto remoto, il relativo contatore viene incrementato Alla prima occorrenza, il client invia un messaggio al server per avvertirlo Quando un riferimento viene eliminato, il relativo contatore viene decrementato. Se si tratta dell ultima occorrenza, il client avverte il server Quando non ci sono più stub che stanno usando l oggetto remoto, il server dealloca la memoria attraverso una garbage collection locale Valeria Cardellini - SDCC 2013/ Distributed garbage collection (3) Java RMI si pone il problema del crash di un client Per risolvere tale problema, viene usato un meccanismo basato su lease (contratto) Il client detiene il contratto e deve rinnovarlo ad intervalli regolari Se il client non rinnova il lease, il server assume che il client sia caduto o ci siano stati problemi di rete, quindi decrementa il contatore dei riferimenti remoti Anche in questo caso abbiamo una soluzione ad alto costo (dal punto di vista dell overhead di comunicazione) non attuabile in ambienti non locali e geograficamente molto distribuiti Valeria Cardellini - SDCC 2013/14 103

53 Esempio: compute engine Implementare un compute engine E un oggetto remoto che consente ad un server di ricevere dei task dai client, eseguirli e restituire il risultato Il task viene definito dal client ma viene eseguito sulla macchina del server Il task può variare indipendentemente dal server, l importante è che rispetti una determinata interfaccia Il compute engine scarica dal client il codice del task e lo esegue all interno della propria JVM Due interfacce per implementare un compute engine Interfaccia remota Compute, che consenta ai client di inviare task al compute engine Interfaccia Task, che consenta al compute engine di eseguire i task Per il codice vedi Valeria Cardellini - SDCC 2013/ Esempio: compute engine (2) Il codice di questo esempio contiene anche: Caricamento dinamico delle classi: tramite web server Usando la proprietà java.rmi.server.codebase Creazione ed installazione di un security manager e definizione dei relativi file di policy Valeria Cardellini - SDCC 2013/14 105

54 Esercizio 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 - SDCC 2013/ Confronto tra SUN RPC e Java RMI 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 client stub e server stub Passaggio dei parametri: per copia-ripristino Varie estensioni, tra cui broadcast (più risposte da molteplici server anziché una sola) e sicurezza Valeria Cardellini - SDCC 2013/14 107

55 Confronto tra SUN RPC e Java RMI (2) 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: RMI registry Presentazione dei dati: Java come IDL e generazione stub e skeleton Passaggio dei parametri: per valore (tipi primitivi e oggetti serializable), per riferimento nel caso di oggetti con interfacce remotizzabili (oggetti remote) Valeria Cardellini - SDCC 2013/ Comunicazione orientata ai messaggi 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 - SDCC 2013/14 109

56 Message Passing Interface (MPI) Libreria per lo scambio di messaggi tra processi in esecuzione su nodi diversi Specifica della sola interfaccia ( Diverse implementazioni, tra cui Open MPI ( e MPICH ( 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 - SDCC 2013/ Comunicazione punto-punto in MPI 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 MPI_Bsend MPI_Send MPI_Ssend MPI_Isend MPI_Recv Significato Aggiunge un messaggio in uscita ad un buffer per l invio Invia un messaggio e aspetta finché non viene copiato in un buffer locale o remoto Invia un messaggio e aspetta finché non inizia la ricezione Invia il riferimento ad un messaggio in uscita e continua Riceve un messaggio; si blocca se non ce ne sono Valeria Cardellini - SDCC 2013/14 111

57 Esempio di comunicazione in MPI #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) { //Invia un messaggio al processo 1 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(); return 0; MPI_Send(buf, count, datatype, dest, tag, comm) MPI_Recv(buf, count, datatype, source, tag, comm, status) Valeria Cardellini - SDCC 2013/ Middleware orientato ai messaggi (MOM) Idea base di un MOM (o sistema a code di messaggi): la comunicazione tra applicazioni avviene tramite messaggi inseriti in/prelevati da apposite code Generalmente coda privata per ogni applicazione (esistono anche code condivise da più applicazioni) Supporto per comunicazione persistente e asincrona Il mittente ha soltanto la garanzia che il suo messaggio venga inserito nella coda del destinatario Non c è garanzia che il destinatario prelevi il messaggio dalla sua coda Disaccoppiamento temporale tra mittente e destinatario Un messaggio può contenere qualunque dato e deve essere indirizzato opportunamente Nome univoco a livello del sistema Valeria Cardellini - SDCC 2013/

58 API di MOM 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 - SDCC 2013/ Architettura di MOM I messaggi sono 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 - SDCC 2013/14 115

59 Architettura di MOM (2) L architettura generale di un MOM scalabile richiede un insieme di gestori (router o relay) specializzati nel servizio di routing dei messaggi da un gestore all altro Il MOM realizza un overlay network con topologia propria e distinta Occorre un servizio di routing 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 - SDCC 2013/ Message broker 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 - SDCC 2013/14 117

60 Message broker (2) Gestisce l eterogeneità delle applicazioni Trasforma i messaggi in ingresso nel formato adatto all applicazione destinataria, fornendo trasparenza di accesso Gestisce un repository di regole e programmi che consentono la conversione dei messaggi Per motivi di scalabilità ed affidabilità, la sua implementazione può essere distribuita broker Anche architettura Hub-and-Spoke Valeria Cardellini - SDCC 2013/ Some products for MOM Examples of MOM products IBM WebSphere MQ Microsoft Message Queueing (MSMQ) Java Message Service (JMS): API MOM for Java Oracle Streams Advanced Queuing (AQ) Amazon Simple Queue Service (SQS) Valeria Cardellini - SDCC 2013/14 119

61 IBM WebSphere MQ MOM molto diffuso (~40% del mercato) con architettura distribuita Messaggi gestiti da queue manager (QM) Le applicazioni possono inserire/estrarre messaggi solo nelle/dalle code locali o attraverso un meccanismo RPC Trasferimento dei messaggi da una coda all altra di QM diversi tramite canali di comunicazione unidirezionali ed affidabili gestiti da message channel agent (MCA) che si occupano di tutti i dettagli Stabilire canali di comunicazione Tipo dei messaggi Invio/ricezione dei pacchetti Ogni MCA ha una coda di invio Valeria Cardellini - SDCC 2013/ IBM WebSphere MQ (2) 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 Durante la fase di configurazione l amministratore definisce le opportune interconnessioni tra QM in tabelle di routing Valeria Cardellini - SDCC 2013/14 121

62 IBM WebSphere MQ (3) 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 - SDCC 2013/ IBM WebSphere MQ (4) 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 - SDCC 2013/14 123

63 Amazon Simple Queue Service Cloud-based message queue service that allows to decouple the components of a cloud application Message queues are hosted within AWS infrastructure Message payload can contain up to 256 KB of text data Messages are stored in queues for a limited period of time Components using SQS can run independently and asynchronously and can be developed with different technologies A received message is locked during processing If processing fails, the lock expires and the message is available again Can be combined with Amazon SNS To send identical copies of a message to multiple SQS queues in parallel For an example of application, see Valeria Cardellini - SDCC 2013/ Main operations in SQS interface CreateQueue, ListQueues, DeleteQueue: create, list, delete queues SendMessage, ReceiveMessage: add/receive messages to/from a specified queue ChangeMessageVisibility: change the visibility timeout of previously received message DeleteMessage: remove a received message from a specified queue SetQueueAttributes: control queue settings GetQueueAttributes: get information about a queue Valeria Cardellini - SDCC 2013/14 125

64 Comunicazione orientata agli stream 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 - SDCC 2013/ Comunicazione orientata agli stream (2) 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 - SDCC 2013/14 127

65 Stream 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 - SDCC 2013/ Stream e QoS 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 Bit rate a cui devono essere trasportati i dati Tempo massimo di set up di una sessione (quando un applicazione può iniziare ad inviare dati) Tempo massimo di trasporto (quanto impiega un unità di dati ad arrivare al destinatario) Varianza massima del tempo di trasmissione (jitter) Tempo massimo di round-trip Valeria Cardellini - SDCC 2013/14 129

66 Garantire la QoS 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 (campo Differentiated Services nell header IP) I pacchetti possono essere trattati con diversa priorità, ad es. classi di inoltro rapido ed inoltro assicurato Non necessariamente supportato dai router Valeria Cardellini - SDCC 2013/ Garantire la QoS: : a livello applicativo Uso di buffer per ridurre lo jitter Uso del frame interleaving per ridurre gli effetti della perdita dei pacchetti (se ci sono più frame nello stesso pacchetto) Trasmissione noninterleaved Trasmissione interleaved: più semplice ricostruire o riparare lo stream Valeria Cardellini - SDCC 2013/14 131

67 Sincronizzazione degli stream 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 µsec! Soluzione possibile: sincronizzazione esplicita Si applica il principio dell algoritmo token bucket usato per il filtraggio del traffico Valeria Cardellini - SDCC 2013/ Comunicazione multicast 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 - SDCC 2013/14 133

68 Tipologie di multicast Multicast a livello di protocolli di rete Multicast a livello applicativo Valeria Cardellini - SDCC 2013/ Multicasting a livello di rete Replicazione dei pacchetti e routing gestiti dai router Multicast a livello IP (IPMC) basato sui gruppi Generalizza UDP con trasmissione uno-a-molti Gruppo: insieme di host interessati alla stessa applicazione multicast Indirizzo IP da a assegnato al gruppo Protocollo IGMP (Internet Group Management Protocol) per il join al gruppo Uso limitato 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 Ad es. disabilitato in tutte le piattaforme Cloud a causa del problema del broadcast storm (aumento esponenziale del traffico di rete con possibile saturazione completa) Valeria Cardellini - SDCC 2013/14 135

69 Multicasting applicativo La replicazione dei pacchetti e il routing sono gestiti dagli end host Multicasting applicativo di tipo Strutturato: creazione di percorsi di comunicazione espliciti Non strutturato: basato su gossip Idea di base: 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 - SDCC 2013/ Valeria Cardellini - SDCC 2013/14 Multicasting applicativo (2) 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

70 Multicasting applicativo (3) radice forwarder forwarder radice join() forwarder forwarder join() forwarder radice forwarder forwarder join() Valeria Cardellini - SDCC 2013/ Costi del multicasting applicativo 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 - SDCC 2013/14 139

71 Valeria Cardellini - SDCC 2013/14 Protocolli basati su gossiping 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 140 Principi dei protocolli di gossiping 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 ACM. Valeria Cardellini - SDCC 2013/14 141

72 Principi dei protocolli di gossiping (2) 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 - SDCC 2013/ Anti-entropia Un nodo P sceglie casualmente un altro nodo Q nel sistema 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) 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 scelta dati scelta dati scelta dati Valeria Cardellini - SDCC 2013/14 143

73 Gossiping 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 - SDCC 2013/ Un protocollo di gossiping in generale Due peer P e Q, con P che ha scelto Q per lo scambio di dati Active thread (peer P): Passive thread (peer Q): (1) selectpeer(&q); (1) (2) selecttosend(&bufs); (2) (3) sendto(q, bufs); -----> (3) receivefromany(&p, &bufr); (4) (4) selecttosend(&bufs); (5) receivefrom(q, &bufr); <----- (5) sendto(p, bufs); (6) selecttokeep(cache, bufr); (6) selecttokeep(cache, bufr); (7) processdata(cache); (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 Valeria Cardellini - SDCC 2013/14 145

74 Gossiping e flooding a confronto 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 (possiamo considerarlo una degenerazione del gossiping) Il messaggio viene scartato quando il suo TTL diviene nullo Round 1 Round 2 Round 3 Messaggi inviati: 18 Nodi raggiunti: 8 su 9 Valeria Cardellini - SDCC 2013/ Gossiping e flooding a confronto (2) Nel caso di gossiping semplice Il messaggio viene inviato con una probabilità di gossiping p for each msg m p if random(0,1) < p then send m Round 1 Round 2 Round 3 p p p p p p p p p p Messaggi inviati: 11 Nodi raggiunti: 7 su 9 Valeria Cardellini - SDCC 2013/14 147

75 Altre applicazioni del gossiping nei SD 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 x 0,i e x 0,j i valori al tempo t=0 posseduti dai nodi i e j Dopo il gossiping tra i e j: x 1,i,x 1,j!(x 0,i + x 0,j )/2 Valeria Cardellini - SDCC 2013/ Implementare un protocollo di gossiping Quali problemi specifici occorre affrontare per implementare un protocollo di gossiping? Membership: come i vari processi possono conoscersi tra loro e quanti conoscenti occorre avere Consapevolezza della rete: come far sì che i rapporti fra processi riflettano la topologia della rete, in modo da ottenere prestazioni soddisfacenti Gestione dei buffer: quali informazioni scartare quando la memoria è piena Filtraggio dei messaggi: come considerare il reale interesse da parte dei processi e ridurre la probabilità che ricevano informazioni a cui non sono interessati Valeria Cardellini - SDCC 2013/14 149

76 Blind counter rumor mongering A node n initiates a broadcast Send the message m to B neighbors, chosen at random When a node p receives a message m from another node q If p has received m no more than F times then p sends m to B uniformly randomly chosen neighbors that p knows have not yet seen m p knows if its neighbor q has already seen the message m only if p has sent it to q previously, or if p received the message from q Valeria Cardellini - SDCC 2013/ Analysis of blind counter rumor mongering Difficult to obtain analytical expressions to describe the behavior of a gossiping protocol, even for relatively simple topologies simulation analysis Assume Barabási network topology: 1000 nodes with an average node degree of 6 Rumor mongering vs flooding scalability (F=2, B=2) Source: The cost of application-level broadcast in a fully decentralized peer-to-peer network Valeria Cardellini - SDCC 2013/14 151