Comunicazione nei Sistemi Distribuiti Parte 2 Corso di Sistemi - PDF document

Macroarea di Ingegneria Dipartimento di Ingegneria Civile e Ingegneria Informatica Comunicazione nei Sistemi Distribuiti Parte 2 Corso di Sistemi Distribuiti e Cloud Computing A.A. 2019/20 Valeria Cardellini Laurea Magistrale in Ingegneria Informatica Comunicazione orientata ai messaggi • RPC e RMI migliorano la trasparenza della distribuzione • Ma sono sincroni – Sincronia nel tempo: attesa per risposta – Sincronia nello spazio: i dati condivisi sono noti – Funzionalità e comunicazione sono accoppiate • Quali modelli di comunicazione per un miglior disaccoppiamento? • Comunicazione orientata ai messaggi ⎼ Funzionalità e comunicazione sono disaccoppiate – Di tipo transiente • Berkeley socket: già esaminata in altri corsi • Message Passing Interface (MPI) – Di tipo persistente • Message Oriented Middleware (MOM) Valeria Cardellini – SDCC 2019/20 1

Message Passing Interface (MPI) • Libreria per lo scambio di messaggi tra processi in esecuzione su nodi diversi – Specifica della sola interfaccia (http://www.mpi-forum.org/) – Diverse implementazioni, tra cui Open MPI (http://www.open-mpi.org/) e MPICH (http://www.mcs.anl.gov/research/projects/mpich2/) – Standard de facto per la comunicazione tra i nodi di un sistema che esegue un programma parallelo sviluppato per un ’ architettura a memoria distribuita • MPI definisce una serie di primitive per la comunicazione tra processi; in particolare: – Primitive per la comunicazione punto-punto : per l’invio e la ricezione di un messaggio tra due processi diversi – Primitive per la comunicazione collettiva Valeria Cardellini – SDCC 2019/20 2 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 Significato Aggiunge il messaggio in uscita ad un buffer per l’invio MPI_Bsend Invia il messaggio e aspetta finché non viene copiato in un MPI_Send buffer locale o remoto Invia il messaggio e aspetta finché non inizia la ricezione MPI_Ssend Invia il riferimento al messaggio in uscita e continua MPI_Isend Riceve il messaggio; si blocca se non ce ne sono MPI_Recv Valeria Cardellini – SDCC 2019/20 3

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) { MPI_Send(buf, count, datatype, //Invia un messaggio al processo 1 dest, tag, comm) strcpy(message, "PROVA"); MPI_Send(message, strlen(message)+1, MPI_CHAR, 1, 99, MPI_COMM_WORLD); printf("%d) Ho inviato: '%s'\n", myrank, message); } else if (myrank==1) { //Riceve il messaggio dal processo 0 MPI_Recv(message, 20, MPI_CHAR, 0, 99, MPI_COMM_WORLD, &status); printf("%d) Ho ricevuto: '%s'\n", myrank, message); } MPI_Finalize(); MPI_Recv(buf, count, datatype, return 0; source, tag, comm, status) } Valeria Cardellini – SDCC 2019/20 4 Message-oriented middleware • Communication middleware that supports sending and receiving messages in a persistent way • Loose coupling among system/application components – Decoupling in time and space – Can also support synchronization decoupling • Two patterns: – Message queue – Publish-subscribe (pub/sub) • And two related types of systems: – Message queue system (MQS) – Pub/sub system Valeria Cardellini – SDCC 2019/20 5

Queue message pattern • Messages are put into queue • Multiple consumers can read from the queue • Each message is delivered to only one consumer • Principles – Loose coupling – Service statelessness • Services minimize resource consumption by deferring the management of state information when necessary • Apps: – Task scheduling, load balancing, collaboration Valeria Cardellini – SDCC 2019/20 6 Queue message pattern B issues a response message back to A A sends a message to B Valeria Cardellini – SDCC 2019/20 7

Message queue API • Basic interface to a queue in a MQS: – put : nonblocking send • Append a message to a specified queue – get : blocking receive • Block until the specified queue is nonempty and remove the first message • Variations: allow searching for a specific message in the queue, e.g., using a matching pattern – poll : nonblocking receive • Check a specified queue for message and remove the first • Never block – notify : nonblocking receive • Install a handler (callback function) to be automatically called when a message is put into the specified queue Valeria Cardellini – SDCC 2019/20 8 Publish/subscribe pattern • Application components can publish asynchronous messages (e.g., event notifications), and/or declare their interest in message topics by issuing a subscription Valeria Cardellini – SDCC 2019/20 9

Publish/subscribe pattern • Multiple consumers can subscribe to topic with or without filters • Subscriptions are collected by an event dispatcher component, responsible for routing events to all matching subscribers – For scalability reasons, its implementation can be distributed • High degree of decoupling among components – Easy to add and remove components – Appropriate for dynamic environments Valeria Cardellini – SDCC 2019/20 10 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, i.e., one-to-one communication – Pub/sub channel: delivers messages to multiple receivers, i.e., one-to-many communication Valeria Cardellini – SDCC 2019/20 11

Publish/subscribe API • 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 Valeria Cardellini – SDCC 2019/20 12 MOM functionalities • MOM handles the complexity of addressing, routing, availability of communicating application components (or applications), and message format transformations Source: “Cloud Computing Patterns”, http://bit.ly/2hZv6Xs Valeria Cardellini – SDCC 2019/20 13

MOM functionalities • Let us analyze – Semantics delivery – Message routing – Message transformations Valeria Cardellini – SDCC 2019/20 14 Semantics delivery in MOM At-least-once delivery How can MOM ensure that messages are received successfully? – By sending ack for each retrieved message and resending message if message is not received – Be careful: app should be tolerant to message duplications Valeria Cardellini – SDCC 2019/20 15

Semantics delivery in MOM Exactly-once delivery How can MOM ensure that a message is delivered only exactly once to a receiver? – By filtering possible message duplicates automatically – Upon creation, each message is associated with a unique message ID, which is used to filter message duplicates during their traversal from sender to receiver – Messages must also survive MOM components’ failures Valeria Cardellini – SDCC 2019/20 16 Semantics delivery in MOM Transaction-based delivery How can MOM ensure that messages are only deleted from a message queue if they have been received successfully? – MOM and the receiver participate in a transaction: all operations involved in the reception of a message are performed under one transactional context guaranteeing ACID behavior Valeria Cardellini – SDCC 2019/20 17

Semantics delivery in MOM Timeout-based delivery How can MOM ensure that messages are only deleted from a message queue if they have been received successfully at least once? – Messages are not deleted immediately from the queue, but marked as being invisible until a visibility timeout expires – Invisible message cannot be read by another receiver – After receiver ack of message receipt, the message is deleted from the queue Valeria Cardellini – SDCC 2019/20 18 Message routing: general model • Queues are managed by queue managers (QMs) – An application can put messages only into a local queue – Getting a message is possible by extracting it from a local queue only • QMs need to route messages – Function as message-queuing “relays” that interact with distributed applications and each other – Support the idea of an overlay network – Also special queue managers that operate as routers Valeria Cardellini – SDCC 2019/20 19