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. 2016/17 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? 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 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 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 consenso distribuito, tra cui commit distribuito (per stabilire che una transazione sia portata a termine da tutte le parti coinvolte o non abbia alcun effetto) Protocolli di locking distribuiti Protocolli di consistenza dei dati 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 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 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 ricevuto dal destinatario 3. finché il messaggio non viene elaborato dal destinatario 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 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 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) 9

6 Persistent communication a) Persistent asynchronous communication b) Persistent synchronous communication 10 Transient communication c) Transient asynchronous communication d) Receipt-based synchronous communication 11

7 Transient communication (2) e) Delivery-based synchronous communication f) Response-based synchronous communication 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ò essere perso o ritardato, oppure la connessione resettata La rete è affidabile ( The Eight Fallacies of Distributed Computing ) 2. Il server può subire un crash a. prima di eseguire il servizio richiesto b. dopo aver eseguito il servizio richiesto Il client non può distinguere tra a e b 3. Il client può subire un crash 13

8 Semantica della comunicazione ed errori (2) In un sistema distribuito quale è la semantica della comunicazione in presenza di errori? Semantica may-be Semantica at-least-once Semantica at-most-once Semantica exactly-once 14 Meccanismi di base La semantica della comunicazione dipende dalla combinazione di tre meccanismi di base 1. Lato client: riprova (Request Retry RR1) Il client continua a provare finché ottiene risposta oppure è certo del guasto del server dopo un certo numero di retry senza risposta 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 nel caso riceva una richiesta duplicata Meccanismo necessario se l operazione eseguita dal server non è idempotente Operazione idempotente (i.e., priva di effetti collaterali): molteplici esecuzioni dell operazione producono gli stessi effetti/risultati di una sola esecuzione dell operazione, ad es. operazione read-only oppure x=1 15

9 Semantica may-be Semantica may-be (forse) Il messaggio può essere consegnato 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 16 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 della ritrasmissione del messaggio di richiesta e conseguente duplicazione Adatta per operazioni idempotenti (server stateless) All arrivo di una risposta, il client non sa quante volte sia stata calcolata dal server (almeno una): non conosce lo stato del server Il server può aver eseguito l operazione ma subire un crash prima di inviare la risposta: allo scadere del timeout il client invia la stessa richiesta ed il server esegue nuovamente l operazione ed invia la risposta al client 17

10 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 18 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, se riceve la risposta, essa è stata calcolata dal server una sola volta In caso di insuccesso, nessuna informazione (at-most-once: la risposta è stata calcolata al più una volta, ma possibilmente anche nessuna) Tutti e 3 i meccanismi in uso (RR1, DF, RR2) Il client effettua ritrasmissioni Il server mantiene uno stato per riconoscere messaggi di richiesta già ricevuti e 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 19

11 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 20 At-most-once: implementation issues Server detects duplicate requests and returns previous reply instead of re-running server operation (handler) How to detect a duplicate request? Client includes a unique ID (XID) with each request and uses same XID for re-send Some at-most-once complexities How to ensure XID is unique? - Server must eventually discard info about old requests: when is discard safe? Can use sliding windows and sequence numbers Can discard information older than maximal message lifetime - How to handle duplicate requests while original one is still executing? Server: if seen[xid] else r = old[xid] r = handler() old[xid] = r seen[xid] = true 21

12 Semantica exactly-once Semantica exactly-once (esattamente una volta) E lo scenario migliore ma di difficile attuazione in un sistema distribuito Richiede accordo completo sull interazione Il messaggio arriva una sola volta oppure non è 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: è una soluzione scarsamente praticabile in un sistema reale! Occorrono ulteriori meccanismi per tollerare guasti lato server Replicazione trasparente, write-ahead logging e recovery 22 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 (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 23

13 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 24 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 (dati assemblati/ disassemblati in modo opportuno per la trasmissione in un messaggio) usato ad es. da RPC oppure Serializzazione dei parametri (dati strutturati in flusso di byte) usato ad es. da Java RMI e.net Il middleware gestisce alcuni errori dovuti alla distribuzione Implementazione errata Errori dell utente 25

14 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 Client e server devono anche coordinarsi sul protocollo di trasporto usato per lo scambio di messaggi 2. In presenza di malfunzionamenti, il client di cosa può essere certo rispetto all esecuzione di procedura chiamata/metodo remoto? Procedura locale: semantica exactly-once Procedura remota: semantica at-least-once o at-most-once 3. Il client come può effettuare il binding al server? 26 Eterogeneità nella rappresentazione dei dati Client e server possono 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 27

15 Eterogeneità nella rappresentazione dei dati (2) Confrontiamo le alternative 2 e 3, nell ipotesi di N componenti che comunicano tra loro Alternativa 2: dotare ogni componenti 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 componente possiede le funzioni di conversione da/per questo formato Minori prestazioni nella conversione Basso numero di funzioni di conversione, pari a 2*N 28 Semantics of remote call/method We already considered semantics of communication Exactly once semantics is difficult to implement: communication middleware generally implements weaker semantics At-least-once semantics: if the client received a reply from the server, that remote call/method has been executed at least once on the server At-most-once semantics: if the client gets a reply from the server, it means that the remote call/method has been executed at most once on the server 29

16 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 nel codice del client Semplice ed economico, ma mancanza di trasparenza e flessibilità Binding dinamico Ritarda la decisione al momento dell esecuzione 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 30 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: broadcast o multicast da 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 31

17 Binding dinamico (2) Addressing implicito: presenza di name server (anche binder, directory service, registry service) che registra i servizi ed agisce su opportune tabelle di binding, fornendo funzioni di: ricerca, registrazione, aggiornamento, eliminazione di servizi client stub 4 server stub 2, 3 name server 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ò così avvenire meno frequentemente delle chiamate stesse In genere, si usa lo stesso binding per molte chiamate allo stesso server 32 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 33

18 Why RPC Implemented and used in most distributed systems, including cloud computing systems Developed and employed in many technologies and languages, among which: Java RMI Go SOAP Ice (Internet Communication Engine) Microsoft.NET CORBA Distributed Ruby (DRb) Remote Python Call (RPyC) JSON-RPC BERT-RPC, used by GitHub 34 Chiamata di una procedura Procedura p locale Procedura p remota 35

19 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 36 Architettura RPC Modello con stub (adattatore o proxy) Il client invoca il 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 dal 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 stub Trasparenza Stub prodotti in modo automatico Lo sviluppatore progetta e si occupa solo delle parti applicative e logiche 37

20 Passi di una RPC 1. Lato client, la procedura chiamata invoca il client stub tramite una normale chiamata di procedura locale 2. Il client stub costruisce un messaggio e richiama il SO locale Marshaling dei parametri: operazione di impacchettare in un messaggio i parametri, convertendoli in formato comune 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 prelevando i parametri e convertendoli in formato locale, e invoca il server come una procedura locale 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 (marshaling dei parametri) 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 (unmarshaling dei parametri) e restituisce il risultato al client 38 Passi di una RPC (2) Esempio con passaggio di parametri per valore add(i, j) 39

21 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ò il chiamante considerare certo rispetto all esecuzione della procedura chiamata? 4. Come effettuare il binding alla macchina su cui viene eseguita la procedura chiamata? 40 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 41

22 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 non ambigua del servizio 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 42 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) 43

23 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 44 RPC asincrona In modalità sincrona, una chiamata RPC provoca il blocco del client Non necessario se il server non deve restituire nessun risultato Alcuni middleware RPC supportano RPC asincrona Il client può dedicarsi ad altri task, una volta effettuata la chiamata ed aver ricevuto dal server un ack che la chiamata di procedura è stata ricevuta ed avviata Ad es. Go RPC sincrona RPC asincrona 45

24 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 46 RPC and transparency Is RPC really transparent: can we really just treat remote procedure calls as local procedure calls? Not quite Performance Local call: maybe 10 cycles = ~3 ns RPC: ms on a LAN => ~10K-100K slower Consider context switching costs, copy costs, interprocess communication overhead, In WAN: can easily be millions of times slower Failures Also security, concurrent requests, 47

25 Implementazione del middleware RPC Analizziamo l implementazione ed il middleware RPC di Sun Microsystems: Open Network Computing (ONC), anche noto come SUN RPC Implementazione basilare e largamente usata 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 48 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,

26 SUN RPC e stack OSI 50 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 51

27 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) 52 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)? 53

28 RPC: un esempio per iniziare 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); } 54 RPC: un esempio per iniziare (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? 55

29 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) 56 Sviluppo del programma client Il client viene lanciato con l hostname 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 57

30 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); } 58 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: 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() 59

31 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 60 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 61

32 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) 62 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 63

33 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 RPC 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 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 64 Port mapper Port mapper (portmap) in ascolto su porta 111 (sia UDP che TCP) dell host remoto Quando un server RPC viene lanciato, notifica al port mapper le informazioni sul servizio offerto prognum, versnum, protocol e port Prima di invocare il servizio, il client stub 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 65

34 Port mapper (2) Per avere la lista di tutti i programmi RPC invocabili sull 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 66 Processo di sviluppo in SUN RPC Data una specifica di partenza Scritta in XDR square.x RPCGEN produce Header 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 67

35 Esempi RPC Esempi di programmi RPC sul sito del corso square: quadrato di un numero intero Esaminiamo il codice di client stub e server stub 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 68 Riferimenti per Java RMI Trail: RMI, W. Grosso, Java RMI, O Reilly,

36 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 remoto in esecuzione su un altro host Obiettivo: rendere l invocazione locale e quella remota il più possibile simili Ma la trasparenza non è completa 70 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 71

37 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! remote object Data remote interface m1 m2 implementation { m3 of methods m4 m5 m6 72 Java RMI: generalità (3) Al binding del client con l oggetto server remoto, la 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 analogo 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 73

38 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 relative 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 Client invokes a method Client Client OS Client machine Network Proxy Same interface as object Skeleton invokes same method at object Server machine Server Marshalled invocation is passed across network Skeleton Server OS Object State Method Interface Stub e skeleton rendono possibile la chiamata di un servizio remoto come se fosse locale, agendo da proxy Sono generati automaticamente 74 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 75

39 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 76 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 Sintassi dell invocazione remota identica a quella locale 3. Lo stub effettua la serializzazione delle informazioni per l invocazione (ID del metodo e parametri) 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 77

40 RMI Registry: binder per Java RMI (porta 1099) che funziona come punto di indirezione Servizio di naming che consente al server di registrare il suo oggetto remoti e al client di recuperarne lo stub RMI registry URL RMI: inizia con rmi: e contiene un hostname (opzionale), un numero di porta (opzionale) e il nome dell oggetto remoto Alcune limitazioni: no trasparenza all ubicazione, no gestione della sicurezza 78 Passi essenziali per usare 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 errori di 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 (singolo indirizzo IP e porta, i.e. l oggetto remoto è non replicato) Codice del server: Istanzia l oggetto remoto Registra l oggetto presso l RMI registry, invocando il metodo bind/ rebind (in java.rmi.naming); rebind sostituisce un eventuale associazione già esistente 79

41 Passi essenziali per usare 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 80 Passi essenziali per usare Java RMI (3) Dopo aver sviluppato il codice, occorre: 1. Compilare le classi sviluppate Classi per stub e skeleton sono generate automaticamente a runtime a partire da Java SE 5 Per SE precedenti: usare il compilatore RMI rmic per pregenerare le classi stub e skeleton; inoltre, la classe stub deve essere localmente disponibile sul client 2. 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 3. Avviare il server 4. Avviare il client A questo punto l interazione tra client e server può procedere 81

42 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 82 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); } } } 83

43 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); } } } 84 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 Vedere 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); } } } 85

44 Esempio echo: compilazione ed esecuzione Lato server 1. Compilazione javac EchoInterface.java javac EchoRMIServer.java 2. Solo se < Java SE 5: generazione stub e skeleton rmic EchoRMIServer 3. Esecuzione lato server Avvio in background del registry: rmiregistry [registryport] & Avvio del server: java EchoRMIServer EchoRMIServer_Stub.class Lato client 1. Compilazione javac EchoRMIClient.java 2. Esecuzione lato client java EchoRMIClient 86 Passaggio dei parametri In locale: Per valore: tipi primitivi Per riferimento: tutti gli oggetti Java (tramite indirizzo) In remoto (problemi nel riferimento/indirizzo): Per valore: tipi primitivi e oggetti serializzabili 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 87

45 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 88 Architettura Java RMI Architettura a strati 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) 89

46 Architettura Java RMI (2) Remote Reference Layer Definisce e supporta la semantica dell invocazione e della comunicazione Fornisce il supporto alle chiamate inoltrate dallo stub 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) Implementa il protocollo proprietario Java Remote Method Protocol su TCP Possibilità di utilizzare protocolli applicativi diversi, purché orientati alla connessione Ad es. HTTP per poter invocare oggetti remoti che sono in esecuzione su macchine protette da firewall 90 Distributed garbage collection Java RMI si pone il problema di eliminare gli oggetti remoti per i quali non ci sono più riferimenti L oggetto remoto deve quindi conoscere in ogni istante quanti stub lo stanno riferendo Ma sono possibili guasti di rete, crash del client, Per risolvere il problema, RMI richiede un alto grado di coordinamento, che è adatto solo per applicazioni di piccola/media scala su rete locale: analizziamo perché 91

47 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 92 Distributed garbage collection (3) Java RMI si pone il problema del crash di un client Per risolverlo, utilizza 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 E una soluzione costosa in termini di overhead di comunicazione, quindi non adatta per applicazioni a larga scala e geograficamente distribuite 93

48 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 Codice su 94 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 95

49 Confronto tra SUN RPC e Java RMI SUN RPC: visione a processi, trasparenza all accesso incompleta, 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 trattamento di casi di errore Ricerca del server: port mapper sul server Presentazione dei dati: IDL specifico (XDR) e generazione automatica di 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 96 Confronto tra SUN RPC e Java RMI (2) Java RMI: visione ad oggetti, trasparenza all accesso, no trasparenza all ubicazione, distribuzione non totalmente trasparente (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 automatica di stub e skeleton Passaggio dei parametri: per valore (tipi primitivi e oggetti serializable), per riferimento nel caso di oggetti con interfacce remotizzabili (oggetti remote) 97

50 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) 98 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 ( 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 99

51 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 il messaggio in uscita ad un buffer per l invio Invia il messaggio e aspetta finché non viene copiato in un buffer locale o remoto Invia il messaggio e aspetta finché non inizia la ricezione Invia il riferimento al messaggio in uscita e continua Riceve il messaggio; si blocca se non ce ne sono 100 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) 101

52 Middleware orientato ai messaggi (MOM) Idea base di un MOM (o sistema a code di messaggi): la comunicazione tra componenti dell applicazione distribuita 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 No garanzia che il destinatario prelevi il messaggio Disaccoppiamento temporale tra mittente e destinatario Alcuni MOM supportano anche disaccoppiamento di sincronia Un messaggio può contenere qualunque dato e deve essere indirizzato opportunamente Nome univoco a livello del sistema 102 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 103

53 Architettura di MOM I messaggi sono inseriti/letti in/da code 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) Generalmente la coda memorizza il messaggio finché non viene recuperato da un destinatario Il MOM si occupa del trasferimento dei messaggi Il MOM mantiene la corrispondenza tra ogni coda e la sua posizione sulla rete (servizio di naming) 104 MOM functionalities The MOM handles the complexity of addressing, routing, availability of communication partners, and message format transformations Source: Cloud Computing Patterns 105

54 Architettura di MOM: routing L architettura di un MOM scalabile richiede un insieme di gestori (router) 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 di router conosce la topologia della rete logica (spesso statica) e si occupa di far pervenire il messaggio dalla coda del mittente a quella del destinatario Topologie di rete complesse e scalabili richiedono la gestione dinamica delle corrispondenze codaposizione di rete (analogia con routing in reti IP) 106 Message broker L area di applicazione più importante dei MOM è l Enterprise Application Integration (EAI) Le applicazioni devono poter 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 (message broker) in grado di effettuare le conversioni tra formati diversi La soluzione generalmente adottata nei MOM si basa sulla presenza di message broker 107

55 Message broker (2) Gestisce l eterogeneità delle applicazioni Trasforma i messaggi in ingresso nel formato adatto all applicazione destinataria, fornendo trasparenza di accesso Aggrega messaggi, decompone messaggi 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 108 Some products for MOM Examples of MOM products IBM MQ Microsoft Message Queueing (MSMQ) Java Message Service (JMS): API MOM for Java Open MQ RabbitMQ Apache ActiveMQ Apache Kafka Also Cloud-based MOM products Amazon Simple Queue Service (SQS) Google Cloud Pub/Sub Also emerging open standard protocols for message queues, which are platform- and vendor-agnostic and aim to provide interoperability between MOMs Advanced Message Queueing Protocol (AMQP) Simple (or Streaming) Text Oriented messaging Protocol (STOMP) 109

56 Some examples of MOM usage 1. Use MOM to accept and forward messages which are sent by a producer and received by a consumer 2. Use MOM to distributed timeconsuming tasks among multiple workers 3. Use MOM to deliver messages to multiple consumers (pub/sub pattern) 4. Use MOM to build a logging system 5. Use MOM to run a function on a remote node and wait for the result Source: Getting started with RabbitMQ 110 IBM MQ MOM molto diffuso con architettura distribuita Messaggi e code 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: Stabilire canali di comunicazione Tipo dei messaggi Invio/ricezione dei messaggi Ogni MCA ha una coda di invio 111

57 IBM MQ (2) Il trasferimento sul canale può avvenire solo se entrambi gli MCA sono attivi MQ fornisce meccanismi per avviare automaticamente un MCA Il routing è sotto il controllo di una gestione di sistema statica e poco flessibile Durante la fase di configurazione l amministratore definisce le opportune interconnessioni tra QM in tabelle di routing 112 IBM MQ (3) 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 113

58 Amazon Simple Queue Service (SQS) Cloud-based message queue service based on a polling model Goal: to decouple the components of cloud applications Message queues are hosted within AWS infrastructure Messages are stored in queues for a limited period of time Application components using SQS can run independently and asynchronously and be developed with different technologies A received message is locked during processing (visibility timeout) If processing fails, the lock expires and the message is available again Applies timeout-based delivery Cloud pattern Can be combined with Amazon SNS To push a message to multiple SQS queues in parallel 114 Amazon SQS: timeout-based delivery In SQS, messages are only deleted from a message queue if they have been received properly Timeout-based delivery pattern Messages are not deleted immediately from the queue, but marked as being invisible Invisible message: cannot be read by another client After client acknowledgement of the message receipt, the message is deleted from the queue 115

59 Amazon SQS: API CreateQueue, ListQueues, DeleteQueue Create, list, delete queues SendMessage, ReceiveMessage Add/receive messages to/from a specified queue (message size up to 256 KB) DeleteMessage Remove a received message from a specified queue (the component must delete the message after receiving and processing it) ChangeMessageVisibility Change the visibility timeout of a specified message in a queue (when received, the message remains in the queue upon it is deleted explicitly by the receiver) SetQueueAttributes, GetQueueAttributes Control queue settings, get information about a queue 116 Amazon SQS: example Example of application: online photo processing service sqs-public-images.s3.amazonaws.com/ Building_Scalabale_EC2_applications_with_SQS2.pdf 117

60 Publish/subscribe pattern Publish/subscribe pattern A sibling of message queue pattern but further generalizes it by delivering a message to multiple consumers Message queue: delivers messages to only one receiver Pub/sub channel: delivers messages to multiple receivers Some frameworks (e.g., RabbitMQ, Kafka) support both patterns 118 API of publish/subscribe system Calls that capture the core of any pub/sub system: publish(event): to publish an event Events can be of any data type supported by the given implementation languages and may also contain meta-data subscribe(filter expr, notify_cb, expiry) sub handle: to subscribe to an event Takes a filter expression, a reference to a notify callback for event delivery, and an expiry time for the subscription registration. Returns a subscription handle unsubscribe(sub handle) notify_cb(sub_handle, event): called by the pub/sub system to deliver a matching event 119

61 Apache Kafka General-purpose, distributed pub/sub system Allows to implement either message queue or pub/sub pattern Originally developed in 2010 by LinkedIn Written in Scala Maintains feeds of messages in categories called topics Runs as a cluster comprised of one or more servers each of which is called a broker Brokers rely on Apache Zookeeper for coordination Messages are persisted on disk and replicated within the cluster to prevent data loss At least-once delivery Source: Kafka: A Distributed Messaging System for Log Processing, Apache Kafka used in Monasca Monasca is a monitoring-as-a-service solution integrated with OpenStack Uses Kafka as message queue system 121

62 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, dati di sensori, tweet, 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) 122 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 123

63 Stream Definizione: consideriamo per ora 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 124 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 125

64 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 Ongoing work: sfruttare le potenzialità offerte da SDN 126 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 127

65 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 128 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 129

66 Multicast a livello di rete Tipologie di multicast Multicast a livello applicativo 130 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, identificati da uno stesso indirizzo IP 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) 131

67 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 132 Multicasting applicativo (2) Esempio: costruzione di un albero per il multicasting applicativo in Scribe Scribe: sistema pub-sub decentralizzato basato su Pastry Pastry: rete P2P strutturata basata su DHT già esaminata 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

68 Multicasting applicativo (3) radice forwarder forwarder radice join() forwarder forwarder join() forwarder radice forwarder forwarder join() 134 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 135

69 Protocolli basati su gossiping Protocolli di tipo probabilistico, detti anche di gossiping o epidemici Essendo basati sulla teoria del gossip nelle reti sociali o della diffusione delle epidemie 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 invia 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 136 Le origini Protocolli di gossiping definiti nel 1987 da Demers et al. in un lavoro sulla garanzia di consistenza in database replicati su centinaia di server Idea di base: assumendo che non vi siano conflitti di scrittura (ovvero aggiornamenti indipendenti) 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. 137

70 Why gossiping in large scale DSs? Several attractive properties of gossip-based information dissemination for large scale distributed systems Simplicity of gossiping algorithms Lack of centralized control and bottlenecks Scalability: each peer sends only a limited number of messages, independently from the overall size of the system Reliability and robustness: thanks to message redundancy 138 Where gossiping is used today? Some examples: Amazon uses a gossip protocol to quickly spread information throughout the S3 system. This allows Amazon S3 to quickly route around failed or unreachable servers, among other things. status.aws.amazon.com/s html Amazon s Dynamo uses a gossip-based failure detection service The basic information exchange in BitTorrent is based on gossip 139

71 Principi dei protocolli di gossiping Principi di funzionamento: anti-entropia e gossiping Anti-entropia: modello di propagazione in cui ciascun peer sceglie a caso un altro peer e si scambiano gli aggiornamenti, giungendo al termine ad uno stato simile su entrambi i peer Gossiping: un peer che è stato appeno aggiornato (ossia infettato) contatta un certo numero di peer scelti casualmente inviandogli il proprio aggiornamento (infettandoli a loro volta) 140 Anti-entropia Obiettivo: aumentare la similarità tra peer, aumentando così l ordine (il motivo del nome!) Un peer P sceglie casualmente un altro peer Q nel sistema; come lo aggiorna? 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) scelta Osservazione: la strategia push-pull impiega solo O(log N) round per propagare un aggiornamento agli N peer del sistema dati scelta dati scelta Round (o ciclo) di gossip: intervallo di tempo in cui ogni peer ha preso almeno una volta l iniziativa di scambiare aggiornamenti dati 141

72 Gossiping Un peer P che è stato appena aggiornato, contatta un peer Q scelto a caso Se Q ha già ricevuto l aggiornamento (è già infetto), P perde interesse a diffondere il gossip e con probabilità pari a peer 1/k smette di contattare altri nodi Se s è la frazione di peer non ancora aggiornati, si dimostra che s = e (k+1)(1 s) Al crescere di k aumenta la probabilità che l aggiornamento si diffonda Per garantire che un ampio numero di peer sia aggiornato, occorre combinare il gossiping puro con l anti-entropia 142 Un protocollo di gossiping in generale Due peer P e Q, con P che ha scelto Q per lo scambio di dati; P è eseguito una volta ad ogni round (ogni Δ unità di tempo) 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

73 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 peer 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 Peer raggiunti: 8 su 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 if random(0,1) < p then send m Round 1 Round 2 Round 3 p p p p p p p p p p p Messaggi inviati: 11 Peer raggiunti: 7 su 9 145

74 Nature of gossiping Probabilistic Gossiping vs flooding Takes a localized decision but results in a global state Lightweight Fault tolerant Flooding has advantages Universal coverage and minimal state information but it floods the networks with redundant messages Gossiping goals Reduce the number of redundant transmissions that occur with flooding while trying to retain its advantages but due to its probabilistic nature, gossiping cannot guarantee that all the peers are reached and it requires more time to complete than flooding 146 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 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 usando strategia push-pull: x 1,i, x 1,j (x 0,i + x 0,j )/2 147

75 Implementare un protocollo di gossiping Quali problemi specifici occorre affrontare per implementare un protocollo di gossiping? Membership: come i vari peer possono conoscersi tra loro e quanti conoscenti occorre avere Consapevolezza della rete: come far sì che i collegamenti fra peer 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 peer e ridurre la probabilità che ricevano informazioni a cui non sono interessati 148 Two gossiping protocols We now examine two examples of gossiping protocols Blind counter rumor mongering Bimodal multicast 149

76 Blind counter rumor mongering Why that name for this gossiping protocol? Rumor mongering (def: the act of spreading rumours, also known as gossip): a node with hot rumor will periodically infect other nodes Blind: loses interest regardless of the recipient (why) Counter: loses interest after F contacts (when) A node n initiates a broadcast by sending the message m to B of its neighbors, chosen at random.! When (node p receives a message m from node q)! If (p has received m no more than F times)! p sends m to B uniformly randomly chosen neighbors that p knows have not yet seen m. Note that p knows if its neighbor r has already seen the message m only if p has sent it to r previously, or if p received the message from r 150 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 151

77 Bimodal multicast Also called pbcast (probabilistic broadcast) Composed by two phases: 1. Message distribution phase: a process sends a multicast with no particular reliability guarantees IP multicast if available, otherwise some application-level multicast such as Scribe trees 2. Gossip repair phase: after a process receives a message, it begins to gossip about the message to a set of peers (called fanout) Gossip occurs at regular intervals and offers the processes a chance to compare their states and fill any gaps in the message sequence Source: K.P. Birman, M. Hayden, O. Ozkasap, Z. Xiao, M. Budiu, and Y. Minsky. Bimodal multicast. ACM Trans. Comput. Syst. 17, 2 (May 1999), Bimodal multicast: message distribution p 1 p 2 p 3 p 4 p 5 Send messages In red: failed messages p 6 time Start by using unreliable multicast to rapidly distribute the message But some messages may not get through, and some processes may be faulty So initial state involves partial distribution of multicast(s) 153

78 p 1 p 2 Bimodal multicast: gossip repair Send digests p 3 p 4 p 5 p 6 Periodically (e.g., every 100 ms) each process sends a digest describing its state to some randomly selected process The digest identifies messages: it does not include them 154 p 1 p 2 p 3 p 4 p 5 Bimodal multicast: gossip repair (2) Solicit message copies p 6 Recipient checks the gossip digest against its own history and solicits a copy of any missing message from the process that sent the gossip 155

79 Bimodal multicast: gossip repair (3) p 1 p 2 p 3 p 4 p 5 Send message copies p 6 Processes respond to solicitations received during a round of gossip by retransmitting the requested message Various optimizations (not examined) pbcast is almost always delivered to most or to few processes and almost never to some processes (see graph) Atomicity = almost all or almost none Why bimodal? There are two phases? Nope; description of duals modes of result p{#processes=k} 1.E+00 1.E-05 1.E-10 1.E-15 1.E-20 Pbcast bimodal delivery distribution Either sender fails or data gets through with high probability 2. A second bimodal 1.E-25 characteristic is due to 1.E-30 delivery latencies, with one distribution of very low latencies (messages that arrive without loss in the first phase) and a second distribution with higher latencies (messages that had to be repaired in the second phase) number of processes to deliver pbcast 157