4. IPC (Inter Process Communication) (parte 1): le forme ...disys/sidys4_IPC1.pdf · Comunicazione (3 ) e) Comunicazione transiente sincrona basata sulla spedizione f) Comunicazione

1

CdL MAGISTRALE in INFORMATICA

A.A. 2013-2014

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

Naming

Communication

Software structure 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.

2

Tratto da : Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Middleware layers

Applications, services

Middlewarelayers

request-reply protocol

marshalling and external data representation

UDP and TCP

Thischapter

RMI and RPC


Request-reply communication

Request

Server Client

doOperation

(wait)

(continuation) Reply message

getRequest execute method

message select object

sendReply

3

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 -

4

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


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

5

Persistenza e Sincronìa nella Comunicazione (1)

a)  Comunicazione persistente asincrona b) Comunicazione persistente sincrona

2-22.1


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


6

Transienza e Sincronìa nella Comunicazione (3)

e)  Comunicazione transiente sincrona basata sulla spedizione f)  Comunicazione transiente sincrona basata sulla risposta

sincronìa


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.


7

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.


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

8

Le Socket


Una socket è una astrazione software rappresentante un punto terminale di interfacciamento per la comunicazione in rete.

Esempio di comunicazione connection-oriented usando le socket

Mediante tale astrazione software è cioè possibile creare e rappresentare un terminale (interfaccia) di connessione con una semplice chiamata di funzione, al cui valore di ritorno viene associato un nome. In seguito, attraverso la manipolazione di tale entità, con altre funzioni correlate (primitive), si potrà stabilire una connessione vera e propria con entità dello stesso tipo, consentendo la comunicazione in rete.

Relazione tra protocolli, applicazioni e API socket

Applicazione

TCP

IP

Socket API

HOST

canale IP canale

Applicazione

TCP

IP

Socket API

HOST Es: ethernet Router

Implementazione dei protocolli

(S.O.)

Agli inizi degli anni 80, l’ARPA con l’Università di Berkeley crea un'interfaccia per far comunicare applicazioni che giravano su macchine UNIX connesse in rete. Fu deciso anche di adoperare per quanto possibile il sistema di chiamate a funzioni esistente in UNIX e di aggiungere un nuovo sistema di chiamate per supportare le funzioni TCP/IP. Il risultato fu una interfaccia socket BSD (Berkeley Software Distribution) UNIX. Nel 1991 la Microsoft decise di definire un'API (Application Program Interface) standard per applicazioni TCP/IP in ambiente Windows.

9

Una Socket: una visione di insieme

  Una socket è un dispositivo software che consente la comunicazione (trasferimento di dati) tra due processi su internet in una LAN

Æ  Interfaccia indipendente dalla rete Æ  Uso di un’astrazione unica per i nodi comunicanti Æ  Schema di naming a due livelli

Processo utente

Socket system call Protocollo di trasporto e di rete (TCP/IP)

Gestore di data link (ethernet) kernel


Una Socket: una visione di insieme

  Nel gergo socket uno dei processi che comunicano è chiamato Server (il receiver) e l’altro Client (il sender).

  Tra i due processi il server è quello che ha controllo maggiore, poiché è il processo che inizialmente crea la socket.

  Più client possono comunicare attraverso la stessa socket, ma solo un server può essere associato ad una definita socket.

Il fatto che un programma agisca come client o come server determina un differente uso delle API Socket

•  Il client(il sender) ha bisogno di conoscere l’indirizzo del server (ma non il viceversa)

•  Il Server (il receiver) può apprendere informazioni sull’indirizzo del client una volta stabilita la connessione


10

Le famiglie di Socket

  Esistono varie famiglie di socket. Ogni famiglia   riunisce i socket che utilizzano gli stessi protocolli (Protocol

Family) sottostanti,   supporta un sottoinsieme di stili di comunicazione e

possiede un proprio formato di indirizzamento (Address Family)

Alcuni esempi di famiglie   Unix Domain socket: file in una directory di un computer local host.

Consentono il trasferimento di dati tra processi sulla stessa macchina Unix

  Internet socket (AF_INET): consentono il trasferimento di dati tra processi posti su macchine remote connesse tramite una LAN


I tipi di Socket

  Il tipo di una socket definisce una modalità di comunicazione che una socket usa per inviare dati:

  Streaming Socket (SOCK_STREAM): Fornisce una connessione sequenziale, affidabile e full-duplex. Il protocollo TCP supporta questo tipo di socket.

  Datagram socket (SOCK_DGRAM): Supporta i datagrammi (privo di connessione, messaggi inaffidabili di una lunghezza massima prefissata). Il protocollo UDP supporta questo tipo di socket

AF_INET + SOCK_STREAM determineranno una connessione TCP, AF_INET + SOCK_DGRAM determineranno una trasmissione UDP

Osserviamo che:


11

Indirizzi La comunicazione tra programmi è possibile se si conosce l’indirizzo dei programmi che devono comunicare

Indirizzo Internet (usato da IP)

•  identificatori a 32 bit

•  notazione: 193.204.187.194

•  identifica una interfaccia

•  www.di.uniba.it 193.204.1..

Numero di porta (interpretato da TCP o UDP)

•  identificatori a 16 bit (sempre in relazione ad un IP)

•  range: • Well-Known: 01023

• Registered: 1024 49151 • Dynamic (private) 4915265535

http://www.iana.org/assignments/port-numbers 193.204.187.194 209.134.xxx.xxx

193.204.187.194

Porta

Aplicazione www E-mail

80 23


Socket, Protocolli e Porte su un singolo host

Una socket che usa la famiglia di protocolli TCP/IP è univocamente determinata da un indirizzo internet, un protocollo di comunicazione (TCP o UDP) e un numero di porta

TCP

IP

…

UDP

… 1 2 65535 … 1 2 65535 … …

… Applicazioni

Socket TCP

Porte TCP

Socket UDP

Porte UDP

Applicazioni

Host Descriptor reference Sockets bound to ports CdL in Informatica- Magistrale

Università di Bari Sistemi Distribuiti -

12

Programmazione socket Il client deve contattare il server

•  Il programma server deve essere in esecuzione come processo

•  Il programma server deve avere una porta (socket) che dia il benvenuto al contatto iniziale stabilito da un processo client in esecuzione

Il client contatta il server tramite:

•  la creazione di una socket locale

•  la specifica di un indirizzo del processo server (IP, numero di porta relativi al processo)

•  Dopo la creazione della socket nel client: TCP avvia un handshake a tre vie (tre messaggi di SYNC e ACK) e stabilisce una connessione TCP con il server

•  Durante l’handshake a tre vie il TCP server crea un nuova socket (di connessione) dedicata a quel particolare client


Esempio 1: Primitive BSD UNIX per gestire la comunicazione mediante socket

s = socket (domain, type, protocol) (C/S)

bind (s, addr, addr_len) (S)

connect (s, server_addr, server_addrlen) (S)

listen(s, backlog) (C)

snew=accept(s,client_addr,client_addrlen)(C)

nbytes = read(snew, buffer, amount) (C/S)

write(s, ”message”, msg_lenght) (C/S)

amount =recvfrom(s, buffer, sender_addr)(C/S)

sendto (s,”msg”, receiver_addr) (C/S)

Stream type

datagram type


13

Esempio2 : Interazione TCP Client/Server con WSA

Client 1.  (Inizializzare una WSA) 2.  Creare una Socket 3.  Connettersi al server 4.  Inviare e ricevere dati 5.  Chiudere la connessione

Server 1.  (Inizializzare una WSA Winsock

API) 2.  Creare una socket 3.  Assegnare un local address alla

socket 4.  Settare la socket all’ascolto 5.  Iterativamente (processo di

background): a.  Accettare una nuova

connessione b.  Inviare e ricevere dati c.  Chiudere la connessione

Le Windows Sockets (dette anche WinSock) API (WSA) sono una specifica estensione delle socket BSD UNIX elaborata per l'ambiente operativo Microsoft Windows.

STREAM SOCKET

Tratto da: Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000

Sockets used for datagrams

ServerAddress and ClientAddress are socket addresses

Sending a message Receiving a message

bind(s, ClientAddress)

sendto(s, "message", ServerAddress)

bind(s, ServerAddress)

amount = recvfrom(s, buffer, from)

s = socket(AF_INET, SOCK_DGRAM, 0) s = socket(AF_INET, SOCK_DGRAM, 0)

14

Esempio2 : Interazione UDP Client/Server con WSA

Client 1.  (Inizializzare una WSA) 2.  Creare una Socket 3.  Inviare e ricevere dati 4.  Chiudere la connessione

Server 1.  (Inizializzare una WSA) 2.  Creare una socket 3.  Assegnare un local address alla

socket 4.  Iterativamente:

a.  Inviare e ricevere dati b.  Chiudere la connessione


DATAGRAM SOCKET


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

15

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.


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.


16

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


Garantire QoS (1)

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



17

Garantire QoS (2)

Il principio dell’algoritmo token bucket



Sincronizzazione degli stream

Il principio della sincronizzazione esplicita a livello delle unità di dati


18

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.


19

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


20

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


request

replay

ackn


request

replay

request

Re-request ackn replay

timeout

Meccanismo di timeout su acknowledge


21

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’


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


22

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.

Comunicazione orientata ai messaggi

Per risolvere i problemi relativi alla natura prevalentemente sincrona dell’ IPC, si ricorre a soluzioni basate sulla comunicazione basata sullo scambio di messaggi (conservati o meno in code).

Problemi relativi alla persistenza ed alla sincronizzazione nella comunicazione

23

Architettura di un Message-Queuing System (1)

Relazione tra l’indirizzamento a livello di code e di rete




Ad es. l’organizzazione generale di un sistema message-queuing mediante router.

2-29



24


4 combinazioni per comunicazioni loosely coupled con l’uso delle code

2-26



Message Brokers L’organizzazione generale di un sistema message-queuing

mediante message broker.



Documents

4. IPC (Inter Process Communication) (parte 1): le forme ...disys/sidys4_IPC1.pdf · Comunicazione (3 ) e) Comunicazione transiente sincrona basata sulla spedizione f) Comunicazione