IPC (Inter Process Communication) (parte 1)disys/sidys4_IPC1_14.pdf · La sincronìa nella...
Transcript of IPC (Inter Process Communication) (parte 1)disys/sidys4_IPC1_14.pdf · La sincronìa nella...
CdL MAGISTRALE in INFORMATICA
A.A. 2014-2015
corso di “Sistemi Distribuiti”
4. IPC (Inter Process Communication) (parte 1):
le forme ed i modelli della comunicazione tra processi
Prof. S.Pizzutilo
Elementi caratterizzanti la comunicazione tra processi
Communication
Software structure
Naming
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.
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
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.
Le forme della comunicazione
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 + oggetti (di dati) di lunghezza variabile
Message passing p2 p1
Dati o puntatore
ai dati N. di byte/ tipi dati elementi
Identificatore del messaggio
Indirizzo indirizzo processo processo ricevente mittente
header
Shared data p1 p2 memoria condivisa
CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti -
I modelli di comunicazione
Client-server Function shipping Group multicast
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.
Cor r i sponde 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.
Peer to Peer
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.
Tratto da : Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Request-reply communication
Request
Server Client
doOperation
(wait)
(continuation) Reply message
getRequest execute method
message select object
sendReply
Primitive di comunicazione
Comunicazione basata su due primitive : send e receive
send receive
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.
send receive
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
Processo client
Processo server
Kernel A Kernel B
send receive
Processo receiver Processo
sender
acknowledge
timer
CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti -
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.
Comunicazione asincrona (o non bloccante)
Processo sender
timer Processo receiver
CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti -
La sincronìa nella comunicazione
primitiva blocking send primitiva blocking receive
Comunicazione sincrona (o bloccante)
Comunicazione asincrona (o non bloccante)
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.
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.
Tecniche di sincronizzazione del buffer
Persistenza e Sincronìa nella Comunicazione (1)
a) Comunicazione persistente asincrona b) Comunicazione persistente sincrona
2-22.1
CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti -
Comunicazione persistente = un messaggio immesso per essere trasmesso viene memorizzato per tutto il tempo che serve per consegnarlo al destinatario (ad es. e-mail )
Rif.: A.Tanenbaum,M.Van Steen “Sistemi distribuiti” Pearson Prentice Hall 2007 )
Transienza e Sincronìa nella Comunicazione (2)
c) Comunicazione transiente asincrona d) Comunicazione transiente sincrona basata su ACK
CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti
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 )
Transienza e Sincronìa nella Comunicazione (3)
e) Comunicazione transiente sincrona basata sulla spedizione f) Comunicazione transiente sincrona basata sulla risposta
sincronìa
Rif.: A.Tanenbaum,M.Van Steen “Sistemi distribuiti” Pearson Prentice Hall 2007 )
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
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 -
Tratto da: Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Sockets and ports
message
agreed port any port socket socket
Internet address = 138.37.88.249 Internet address = 138.37.94.248 other ports
client server
Tratto da : Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000
Sockets used for streams
Requesting a connection Listening and accepting a connection
bind(s, ServerAddress); listen(s,5);
sNew = accept(s, ClientAddress);
n = read(sNew, buffer, amount)
s = socket(AF_INET, SOCK_STREAM,0)
connect(s, ServerAddress)
write(s, "message", length)
s = socket(AF_INET, SOCK_STREAM,0)
ServerAddress and ClientAddress are socket addresses
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 direttamente tra due device.
Uno stream effettuato tra due applicazioni su due host diversi.
Rif.: A.Tanenbaum,M.Van Steen “Sistemi distribuiti” Pearson Prentice Hall 2007 )
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 -
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 -
Garantire QoS (1)
Il principio dell’algoritmo token bucket
Rif.: A.Tanenbaum,M.Van Steen “Sistemi distribuiti” Pearson Prentice Hall 2007 )
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.
• 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.
Garantire QoS (2)
Characteristics of the Input Service Required
• maximum data unit size (bytes) • Token bucket rate (bytes/sec) • Token bucket size (bytes) • Maximum transmission rate (bytes/sec)
• Loss sensitivity (bytes) • Loss interval (µsec) • Burst loss sensitivity (data units) • Minimum delay noticed (µsec) • Maximum delay variation (µsec) • Quality of guarantee
CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti -
Rif.: A.Tanenbaum,M.Van Steen “Sistemi distribuiti” Pearson Prentice Hall 2007 )
Sincronizzazione degli stream
Il principio della sincronizzazione esplicita a livello delle unità di dati
CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti -
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
Comunicazione indiretta
Condivisione di buffer § P1, P2, e P3 condividono il buffer A. § P1, invia; P2 e P3 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 -
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.
Buffering
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.
Null buffer (sincrono)
Single message buffer (sincrono)
messaggio1 Unbounded-capacity buffer (asincrono)
Finite-bound buffer (asincrono)
Processo A
messaggio2
buffer Processo B
messaggio2
CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti -
Condizioni di eccezione
§ Gestione di unsuccessful communication (error messages) Terminazione del processo Messaggi perduti Messaggi alterati
§ Flow-controlled communication (sincronizzazione dei processi attraverso il buffer)
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:
Problema generale: il message passing non rende trasparente la comunicazione
timer
sender receiver
ackn
Failure handling
• perdita request • perdita response • crash del computer ricevente
ackn
request
replay
4 messages IPC protocol
sender receiver
3 messages IPC protocol
request
replay
ackn
2 messages IPC protocol
request
replay
request
Re-request ackn replay
timeout
Meccanismo di timeout su acknowledge
CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti -
Idempotenza (ripetibilità) Caratteristica operativa in base alla quale un’operazione produce gli stessi risultati indipendentemente da quante volte viene ripetuta
request
replay
Re-request
replay
timeout
Processo di calcolo con parametro prodotto x’ = x - y
Processo di calcolo con parametro prodotto x’’ = x’ - y
comunicazione non-idempotente
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 Replay con valore
x’’ = x’ - y anziché x’
CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti -