corso di Sistemi Distribuiti 4. IPC (Inter Process Communication) (parte 1): le forme ed i modelli della comunicazione tra processi

Transcript

1 CdL MAGISTRALE in INFORMATICA A.A corso di Sistemi Distribuiti 4. IPC (Inter Process Communication) (parte 1): le forme ed i modelli della comunicazione tra processi Prof. S.Pizzutilo

2 Elementi caratterizzanti la comunicazione tra processi Communication Software structure Le performance e l affidabilità delle tecniche di comunicazione usate per l implementazione dei S.D. sono critici per le performance dell intero sistema. Per comunicare occorre 1) capacità di trasferimento di dati da un processo di invio ad un altro processo di ricezione, 2) capacità di sincronizzare le attività di invio e di ricezione. L openess è realizzata attraverso il disegno e la costruzione di componenti software (interfacce) ben definite. L astrazione dati è una importante tecnica di disegno di tali componenti software in cui i servizi possono essere visti come gestori di oggetti di un tipo di dati e l interfaccia ad un servizio può essere visto come un set di operazioni sul dato. Naming I nomi (e gli identificatori) assegnati alle risorse di un S.D. devono avere un significato globale indipendente dalle locazioni delle risorse e devono essere supportati (gestiti) da un sistema di interpretazione (name service) in grado di tradurli per consentire un accesso trasparente da parte di tutti i nodi del sistema

3 Le forme della comunicazione p1 memoria condivisa p2 Shared data Message passing p1 p2 Messaggio : blocco di informazioni in un formato deciso dal processo mittente in modo che sia interpretabile dal processo ricevente. Struttura del messaggio : header di lunghezza fissa + Dati o puntatore ai dati N. di byte/ tipi dati elementi oggetti (di dati) di lunghezza variabile Identificatore del messaggio Indirizzo processo ricevente header indirizzo processo mittente CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti -

4 I modelli di comunicazione Client-server Function shipping Group multicast Peer to Peer 1) trasmissione di una richiesta da un processo (client) ad un altro processo (server) 2) esecuzione della richiesta sul server 3) trasmissione di una risposta dal server al client Ogni richiesta contiene un identificatore che viene usato anche dal server per trasmettere la risposta al client. E una estensione del modello client-server in cui il client non invia un messaggio con solo dati, bensì la procedura intera con cui il server deve operare sui dati. Il server in tal caso opera come ambiente di esecuzione (o interprete) dei programmi che il client gli invia. Corrisponde ad un message passing con un target multiplo, formato da un gruppo di processi destinatari/server. In questo caso ad un singolo send corrisponde un receive eseguito da ciascun membro di un gruppo di processi. Per localizzare un oggetto. Per aumentare fault tolerance. Per un multiple update. Ogni computer (nodo autonomo ed indipendente) può operare indifferentemente come client o come server, consentendo accessi condivisi a diverse risorse (come file, periferiche e sensori) senza la necessità di un server centrale. Ciò comporta che ciascun computer della rete utilizzi programmi compatibili che consentano questo tipo di comunicazione.

5 Request-reply communication Client Server dooperation (wait) (continuation) Request message Reply message getrequest select object execute method sendreply Tratto da : Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 Addison-Wesley Publishers 2000

6 Primitive di comunicazione Comunicazione basata su due primitive : send e receive send receive receive send I costrutti send e receive realizzano un azione di MESSAGE PASSING tra processi. L azione di message passing consiste nella trasmissione ( attraverso un processo di send) di un insieme di valori di dati (messaggio) mediante uno specifico meccanismo di comunicazione (canale o porta) e l accettazione di tale messaggio da parte di un processo di receive.

7 Comunicazione sincrona (o bloccante) send (dest, &sptr) receive ( addr, &rptr) Spedisce il messaggio puntato da &sptr al processo identificato da dest e blocca il mittente (client) finchè non sia stato completamente spedito il messaggio Blocca addr finchè non arriva il massaggio nel buffer puntato da &rptr timer Processo client Processo server Processo sender Processo receiver Kernel A Kernel B acknowledge send receive CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti -

8 Comunicazione asincrona (o non bloccante) Il message passing ASINCRONO (o non-bloccante) si ottiene quando il messaggio viene posto in coda in attesa che il ricevente lo accetti, senza quindi che il mittente rimanga bloccato in attesa dell acknowledge. timer Processo receiver Processo sender CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti -

9 La sincronìa nella comunicazione Comunicazione sincrona (o bloccante) Comunicazione asincrona (o non bloccante) primitiva blocking send primitiva blocking receive primitiva non-blocking send primitiva non-blocking receive Dopo l esecuzione della send, il processo che invia il messaggio può riprendere l esecuzione appena il messaggio viene copiato nel buffer. Il processo ricevente procede con la sua esecuzione dopo l esecuzione dell istruzione receive, che restituisce il controllo al processo ricevente immediatamente dopo aver comunicato al kernel l indirizzo del buffer che contiene il messaggio. Tecniche di sincronizzazione del buffer Polling: una primitiva test permette al ricevente di controllare lo stato del buffer: La primitiva fa un polling del kernel per controllare se il messaggio è stato completamente copiato nel buffer. Interrupt: Appena il messaggio è stato copiato nel buffer ed è pronto per essere letto dal ricevente, viene generato un interrupt per notificare al ricevente lo stato di ready.

10 Persistenza e Sincronìa nella Comunicazione (1) Comunicazione persistente = un messaggio immesso per essere trasmesso viene memorizzato per tutto il tempo che serve per consegnarlo al destinatario (ad es. ) a) Comunicazione persistente asincrona b) Comunicazione persistente sincrona Rif.: A.Tanenbaum,M.Van Steen Sistemi distribuiti Pearson Prentice Hall 2007 ) CdL in Informatica- Magistrale Sistemi Distribuiti - Università di Bari

11 Transienza e Sincronìa nella Comunicazione (2) Comunicazione transiente = un messaggio immesso per essere trasmesso viene memorizzato solo finchè le applicazioni mittente e destinataria sono in esecuzione (ad es. router) sincronìa asincronìa Rif.: A.Tanenbaum,M.Van Steen Sistemi distribuiti Pearson Prentice Hall 2007 ) c) Comunicazione transiente asincrona d) Comunicazione transiente sincrona basata su ACK CdL in Informatica- Magistrale Sistemi Distribuiti Università di Bari

12 Transienza e Sincronìa nella Comunicazione (3) sincronìa e) Comunicazione transiente sincrona basata sulla spedizione f) Comunicazione transiente sincrona basata sulla risposta Rif.: A.Tanenbaum,M.Van Steen Sistemi distribuiti Pearson Prentice Hall 2007 )

13 InterProcess Communication (IPC) Modelli e tecnologie per la comunicazione e la sincronizzazione fra processi: I tipi di comunicazione: Comunicazione diretta (es. client/server) e indiretta (es.multicast) Comunicazione discreta (es. socket) e a flussi (streaming) Le forme ed i modelli della comunicazione : Ø Sistema di comunicazione basato sui messaggi ( MOM = Message Oriented Middleware). Ø Chiamata a procedura remota (es. RPC) e la comunicazione tra oggetti (es. RMI). Ø Comunicazione Multicast. CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti

14 Comunicazione diretta Ø I processi devono nominare esplicitamente i loro interlocutori: send (P, messaggio) invia un messaggio al processo P receive(q, messaggio) riceve un messaggio dal processo Q Ø Proprietà del canale di comunicazione Ø I canali vengono stabiliti automaticamente. Ø Un canale è associato esattamente a due processi. Ø Tra ogni coppia di processi comunicanti esiste esattamente un canale. Ø Il canale può essere unidirezionale, ma in genere è bidirezionale. CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti -

15 Sockets and ports socket any port agreed port socket client message other ports server Internet address = Internet address = Tratto da: Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 Addison-Wesley Publishers 2000

16 Sockets used for streams Requesting a connection Listening and accepting a connection s = socket(af_inet, SOCK_STREAM,0) connect(s, ServerAddress) write(s, "message", length) s = socket(af_inet, SOCK_STREAM,0) bind(s, ServerAddress); listen(s,5); snew = accept(s, ClientAddress); n = read(snew, buffer, amount) ServerAddress and ClientAddress are socket addresses Tratto da : Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 Addison-Wesley Publishers 2000

17 Data Stream Modalità di scambio di sequenze (flussi) di informazioni dipendenti dal tempo e come supporto per media continui. (stream audio-video) Uno stream effettuato tra due applicazioni su due host diversi. Uno stream effettuato direttamente tra due device. Rif.: A.Tanenbaum,M.Van Steen Sistemi distribuiti Pearson Prentice Hall 2007 )

18 Data Stream type Trasmissione sincrona- viene definito un tempo massimo di trasmissione per ogni unità in uno stream di dati. Trasmissione asincrona- dati trasmessi uno dopo l altro, senza vincoli temporali su quando deve aver luogo la trasmissione dei dati. Trasmissione isocrona i dati vengono trasferiti in un certo tempo (max e min detto bounded o delay jitter) Stream semplice = sequenza di dati Stream complesso = molti stream semplici in relazione tra di loro (detti substream). Ad es. film con 1 substream video e due substream audio per effetto stereo. CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti -

19 Stream e Qualità del Servizio (QoS) I requisiti di tempo sono in genere espressi come requisiti di Qualità del Servizio (Quality of Service = QoS) Specifiche del QoS a livello applicativo: 1)Bit rate con cui devono essere trasportati i dati 2)Tempo massimo di set up di una sessione 3)Tempo di trasporto massimo 4)Varianza massima del tempo di trasmissione (jitter) 5)Tempo massimo della risposta CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti -

20 Garantire QoS (1) Il principio dell algoritmo token bucket Il secchietto di token è un meccanismo di controllo di trasmissione che determina quando e quanto traffico dati può essere trasmesso in base alla presenza o meno di token (gettoni) in un contenitore astratto (bucket). Il secchiello (bucket) contiene dunque dei token, ciascuno dei quali può rappresentare una unità in byte o un singolo pacchetto di dimensioni predeterminate. Un flusso è autorizzato a trasmettere traffico solo quando sono presenti token nel bucket. Rif.: A.Tanenbaum,M.Van Steen Sistemi distribuiti Pearson Prentice Hall 2007 ) Un token è aggiunto al secchiello ogni 1/r secondi. Il bucket può contenere al più b token. Se un token arriva quando il bucket è pieno viene scartato. Quando un pacchetto di n bytes arriva, n token vengono rimossi dal bucket, e il pacchetto viene inviato alla rete. Se sono disponibili meno di n token, nessun token viene rimosso dal bucket, e il pacchetto viene considerato come non conforme.

21 Garantire QoS (2) Characteristics of the Input maximum data unit size (bytes) Token bucket rate (bytes/sec) Token bucket size (bytes) Maximum transmission rate (bytes/sec) Service Required Loss sensitivity (bytes) Loss interval (µsec) Burst loss sensitivity (data units) Minimum delay noticed (µsec) Maximum delay variation (µsec) Quality of guarantee Rif.: A.Tanenbaum,M.Van Steen Sistemi distribuiti Pearson Prentice Hall 2007 ) CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti -

22 Sincronizzazione degli stream Il principio della sincronizzazione esplicita a livello delle unità di dati CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti -

23 Comunicazione indiretta I messaggi vengono inviati a buffer (o porte o mailbox) e da essi ricevuti. ü Ciascun buffer è idendificato con un unico id. ü I processi possono comunicare solamente se condividono un buffer. Proprietà dei canali di comunicazione: Ø Un canale viene stabilito solo se i processi hanno un buffer in comune Ø Un canale può essere associato a più di un processo. Ø Ogni coppia di processi può condividere più canali di comunicazione. Ø I canali possono essere unidirezionali o bidirezionali. Operazioni: u creare un nuovo buffer u inviare e ricevere messaggi attraverso il buffer u distruggere un buffer

24 Comunicazione indiretta Condivisione di buffer P 1, P 2, e P 3 condividono il buffer A. P 1, invia; P 2 e P 3 ricevono (multicast). Chi prende il messaggio? Soluzioni: ü Permettere ad un canale di essere associato al più a due processi. ü Permettere ad un solo processo alla volta di eseguire un operazione di ricezione. ü Permettere al sistema di selezionare arbitrariamente il ricevente. Il sistema può comunicare l identità del ricevente al trasmittente. CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti -

25 Buffering La coda dei messaggi legati ad un canale può essere implementata in tre modi: 1. Capacità zero il canale non può avere messaggi in attesa al suo interno. Il trasmittente deve attendere che il ricevente abbia ricevuto il messaggio (rendezvous). 2. Capacità limitata lunghezza finita: n messaggi. Il trasmittente deve attendere se il canale è pieno. 3. Capacità illimitata lunghezza infinita. Il trasmittente non attende mai.

26 Buffering Null buffer (sincrono) Single message buffer (sincrono) Il messaggio rimane nello spazio di indirizzi del processo inviante ed il processo send rimane sospeso finchè il ricevente non abbia lanciato un processo receive. Il messaggio può anche essere abbandonato dopo un certo intervallo di tempo (timeout) di tentativi di send. Lo stesso meccanismo di timeout può prevedere una nuova spedizione del messaggio. Unboundedcapacity buffer (asincrono) Processo A messaggio2 buffer messaggio1 messaggio2 Processo B Finite-bound buffer (asincrono) CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti -

27 Condizioni di eccezione Nella comunicazione bufferizzata, poiché l inviante non attende che il ricevente sia pronto, vi possono essere molti messaggi in attesa di essere consegnati. La dimensione del buffer potrà essere indefinita o, per rendere realizzabile la comunicazione, dovrà prevedere meccanismi di gestione dell overflow del buffer: Gestione di unsuccessful communication (error messages) Terminazione del processo Messaggi perduti Messaggi alterati Flow-controlled communication (sincronizzazione dei processi attraverso il buffer) Problema generale: il message passing non rende trasparente la comunicazione

28 Failure handling perdita request perdita response crash del computer ricevente Meccanismo di timeout su acknowledge timer 4 messages IPC protocol sender receiver request ackn replay 3 messages IPC protocol sender receiver request replay 2 messages IPC protocol request t i m e o u t request Re-request ackn ackn replay ackn replay CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti -

29 Idempotenza (ripetibilità) Caratteristica operativa in base alla quale un operazione produce gli stessi risultati indipendentemente da quante volte viene ripetuta comunicazione non-idempotente t i m e o u t request replay Re-request replay Processo di calcolo con parametro prodotto x = x - y Processo di calcolo con parametro prodotto x = x - y Replay con valore x = x - y anziché x Per ottenere una comunicazione idempotente (exactly once semantic), si fa uso di un identificatore unico per ogni request, per cui il server mantiene in memoria un data base delle replay; prima di inviare una risposta, il server controlla che non sia stata già prodotta una risposta per quella particolare request CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti -