D. Rosaci
Comunicazione
Comunicazione fra processi
• E’ il cuore dei sistemi distribuiti
• Esamineremo i modi in cui processi su macchine
diverse possono scambiarsi informazione
• La comunicazione si basa sempre sullo scambio di
messaggi a basso livello come fornito dalla rete
sottostante
• Nelle piattaforme non distribuite si usano invece
primitive basate sull’uso della memoria condivisa:
più semplice
• I sistemi distribuiti consistono spesso di migliaia o
milioni di processi sparsi su macchine diverse,
collegati da una rete inaffidabile come Internet:
occorre sostituire le funzionalità di comunicazione a
basso livello con qualcos’altro
D. Rosaci
Sistemi Distribuiti - Comunicazione
2
I protocolli
• Ad ogni livello, su una macchina, esistono delle
entità software (processi) che intendono
comunicare con entità software di pari livello su
un’altra macchina
• Entità di pari livello si chiamano peer
• La comunicazione fra due peer ad un certo livello
avviene per mezzo di un insieme di regole e
convenzioni chiamate protocollo del livello
D. Rosaci
Sistemi Distribuiti - Comunicazione
3
Meccanismo di
comunicazione
• In realtà, nessun dato viene trasferito dal livello n di
una macchina al livello n di un’altra macchina
• I dati vengono inviati, insieme ad opportune
informazioni di controllo, dal livello n al livello n-1, e
così via scendendo nella gerarchia dei livelli fino al
livello 0 (livello fisico)
• A livello 0 i dati e le informazioni vengono
effetivamente trasferite alla macchina destinatario,
dove risalgono attraverso la gerarchia di protocolli
fino al livello n
D. Rosaci
Sistemi Distribuiti - Comunicazione
4
Le interfacce
• Fra ogni coppia di livelli adiacenti c’è un’interfaccia
• L’interfaccia definisce quali operazioni, primitive e
servizi il livello sottostante offre al livello superiore
• Le interfacce devono essere chiare: ogni livello deve
eseguire una collezione di funzioni specifica. Ciò
semplifica l’eventuale sostituzione
dell’implementazione di un livello
D. Rosaci
Sistemi Distribuiti - Comunicazione
5
Architettura di Rete
• Un insieme di livelli e protocolli è chiamata
Architettura di Rete
• Né i dettagli implementativi né le specifiche delle
interfacce appartengono all’architettura
• Le macchine della rete non devono
necessariamente usare le stesse interfacce, purchè
usino la stessa gerarchia di protocolli
D. Rosaci
Sistemi Distribuiti - Comunicazione
6
Livelli, Protocolli ed Interfacce:
una visione d’insieme
D. Rosaci
Sistemi Distribuiti - Comunicazione
7
Un esempio: L’architettura
filosofo-interprete-segretaria
l’indiano e il cinese
suppongono di parlare
tra loro (protocollo 3)
In realtà,
l’indiano si
serve di un
interprete che
capisce
l’inglese
L’interprete
traduce il
messaggio in
olandese e lo
passa alla
segretaria
D. Rosaci
I due traduttori parlano tra
loro in olandese
(protocollo 2)
La segretaria invia il
messaggio all’altra
segretaria per fax
Sistemi (protocollo
Distribuiti -1)Comunicazione
L’interprete
traduce il
messaggio dall’
olandese al
francese e lo
passa al
filosofo
La segretaria
passa il fax
all’interprete
8
Esempio di comunicazione su
rete a 5 livelli - 1
D. Rosaci
Sistemi Distribuiti - Comunicazione
9
Esempio di comunicazione su
rete a 5 livelli - 2
• Un messaggio M viene prodotto da un processo a livello 5 e
passato al livello 4 per essere trasmesso
• Il livello 4 inserisce un’intestazione H4 e passa il messaggio al
livello 3
• Il livello 3 spezza il messaggio in due pacchetti M1 e M2,
aggiungendo ad ognuno un’ntestazione H3, e li passa al livello
2
• Il livello 2 inserisce in ogni pacchetto un’intestazione H2 ed un
cammino T2 e passa i pacchetti al livello 1 (fisico) per
l’effettiva trasmissione
• Sulla macchina destinatario, i pacchetti passano attraverso i
livelli in senso ascendente, fino a ricostruire il messaggio M
D. Rosaci
Sistemi Distribuiti - Comunicazione
10
Considerazioni sulla pila dei
protocolli
• L’astrazione dei processi pari è
cruciale a tutti i livelli
• Essa permette di spezzare la
progettazione dell’intera rete in progetti
più semplici: la progettazione dei
singoli livelli
• Usualmente, i livelli più bassi sono
progettati in hardware o in firmware
D. Rosaci
Sistemi Distribuiti - Comunicazione
11
I Servizi
• La funzione di ogni livello è di offrire servizi al livello superiore.
Il livello inferiore è il service provider, quello superiore è il
service user.
• Un livello n che usufruisce dei servizi di livello (n-1) può, per
mezzo di questi, a sua volta offrire al livello (n+1) i propri
servizi.
• I servizi sono disponibili ai SAP (Service Access Point). I
SAP del livello n, o n-SAP, sono i punti di accesso nei quali il
livello (n+1) può accedere ai servizi del livello n. Ogni n-SAP
ha un indirizzo che lo identifica univocamente.
• Analogia col telefono:
• SAP: presa a muro del telefono;
• SAP address: numero telefonico che identifica quella presa.
D. Rosaci
Sistemi Distribuiti - Comunicazione
12
Livelli adiacenti e SAP
Entità di liv. n
(n -1) - SAP
Interfaccia
fra i liv. n e (n - 1)
Entità di liv. n - 1
D. Rosaci
Sistemi Distribuiti - Comunicazione
13
PDU, SDU, PCI
• L'informazione passata dal livello n al livello (n-1),
attraverso il (n-1)-SAP, si dice PDU (Protocol Data
Unit) di livello n, o n-PDU.
• Essa, entrando nel livello (n-1), diventa una SDU
(Service Data Unit) di livello (n-1), o (n-1)-SDU.
• Entro il livello (n-1) viene aggiunta alla (n-1)-SDU
una PCI (Protocol Control Information) di livello
(n-1).
• Il tutto diventa una (n-1)-PDU, che verrà passata al
livello (n-2) attraverso un (n-2)-SAP.
D. Rosaci
Sistemi Distribuiti - Comunicazione
14
Passaggio dell’informazione fra
livelli
n - PDU
Interfaccia
fra i liv. n e (n - 1)
(n-1) - SAP
(n - 1) - PCI
(n - 1) - SDU
(n - 1) - PDU
Interfaccia
fra i liv. (n - 1) e (n - 2)
D. Rosaci
(n - 2) - SAP
Nomi spesso usati per i
PDU:
segmento (oTPDU,
Transport PDU) a
livello transport
pacchetto (packet) a
livello network
trama (frame) a livello
data link
Nome per il PCI:
busta
Sistemi Distribuiti - Comunicazione
15
Servizi connection-oriented e
connectionless
• Ci sono due principali classi di servizi
offerti da un livello a quello superiore:
• servizi connection-oriented;
• servizi connectionless.
D. Rosaci
Sistemi Distribuiti - Comunicazione
16
Servizi connection-oriented
•
•
•
•
•
•
•
•
I servizi connection-oriented sono modellati secondo il sistema
telefonico, dove per parlare con qualcuno si alza il telefono, si
chiama, si parla e poi si riattacca. Ovvero:
si stabilisce una connessione;
si scambiano informazioni;
si rilascia la connessione.
Analogamente, un servizio connection-oriented si sviluppa in 3 fasi:
si stabilisce una connessione, cioé si crea con opportuni mezzi un
"canale di comunicazione" fra la sorgente e la destinazione. La
relativa attività tipicamente coinvolge un certo numero di elaboratori
nel cammino fra sorgente e destinazione;
la connessione, una volta stabilita, agisce come un tubo digitale
lungo il quale scorrono tutti i dati trasmessi, che arrivano nello steso
ordine in cui sono partiti;
si rilascia la connessione (attività che coinvolge di nuovo tutti gli
elaboratori sul cammino).
D. Rosaci
Sistemi Distribuiti - Comunicazione
17
Servizi connectionless
• I servizi connectionless sono modellati secondo il sistema
postale: ogni lettera viaggia indipendentemente dalle altre;
arriva quando arriva, e forse non arriva. Inoltre, due lettere con
uguale mittente e destinatario possono viaggiare per strade
diverse.
• Analogamente, in un servizio connectionless, i pacchetti
(PDU) viaggiano indipendentemente gli uni dagli altri, possono
prendere strade diverse ed arrivare in ordine diverso da quello
di partenza o non arrivare affatto.
• La fase è una sola:
• invio del pacchetto (corrisponde all'immissione della lettera
nella buca).
D. Rosaci
Sistemi Distribuiti - Comunicazione
18
Servizi affidabili e non
affidabili
• Un servizio è generalmente caratterizzato dall'essere o no
affidabile (reliable).
• Un servizio affidabile non perde mai dati, cioé assicura che
tutti i dati spediti verranno consegnati al destinatario. Ciò
generalmente richiede che il ricevente invii un
acknowledgement (conferma) alla sorgente per ogni
pacchetto ricevuto. Si introduce ovviamente overhead, che in
certe situazioni può non essere desiderabile.
• Viceversa, un servizio non affidabile non offre la certezza
che i dati spediti arrivino effettivamente a destinazione.
• Si noti che se un certo livello non offre nessun servizio
affidabile, qualora tale funzionalità sia desiderata dovrà essere
fornita da almeno uno dei livelli superiori (vedremo che ciò
accade spesso).
D. Rosaci
Sistemi Distribuiti - Comunicazione
19
Esempi di servizi
•
•
•
•
reliable connection oriented: trasferimento di file (non
devono mancare pezzi e il file non deve essere
"rimescolato");
non reliable connection oriented: nelle trasmissioni
isocrone (quali voce e video) le relazioni temporali fra i bit
del flusso devono essere mantenute. E' meglio qualche
disturbo ogni tanto, piuttosto che interruzioni momentanee,
ma avvertibili, del flusso di dati;
non reliable connectionless (detto anche datagram
service, da telegram): distribuzione di posta elettronica
pubblicitaria, non importa se qualche messaggio si perde.
reliable connectionless (detto anche acknowledged
datagram service): si invia un breve messaggio e si vuole
essere assolutamente sicuri che è arrivato.
D. Rosaci
Sistemi Distribuiti - Comunicazione
20
Primitive di definizione del
servizio
• Un servizio di livello n è formalmente specificato da
un insieme di primitive (cioé operazioni) che
un'entità di livello (n+1) può adoperare per
accedere al servizio. Esse possono indicare al
servizio:
• l'azione da compiere (l'informazione viagga da
livello n al livello (n-1));
• cosa riportare in merito ad una azione effettuata
dalla peer entity di livello n (l'informazione viagga
dal livello (n-1) al livello n).
D. Rosaci
Sistemi Distribuiti - Comunicazione
21
Esempi di primitive
D. Rosaci
Primitiva
Significato
request()
si chiede al servizio di fare qualcosa
indication()
si viene avvertiti, dal servizio, di qualche evento
response()
si vuole rispondere ad un evento
confirm()
la risposta che si attendeva è arrivata
Sistemi Distribuiti - Comunicazione
22
Connessione tra peer
• Per stabilire una connessione fra le peer entity A a B si avrà
che:
Entity
Azione
Flusso informazione
Significato
A
invia una
da livello n
a livello (n-1)
A desidera connettersi
da livello (n-1)
a livello n
qualcuno vuole
connettersi
da livello n
a livello (n-1)
B accetta (oppure no)
da livello (n-1)
a livello n
B ha accettato (o no)
connect.request()
B
riceve una
connect.indication()
B
invia una
connect.response()
A
riceve una
connect.confirm()
D. Rosaci
Sistemi Distribuiti - Comunicazione
23
Servizi confermati e non
confermati
• Per il servizio confermato avremo:
–
–
–
–
request();
indication();
response();
confirm().
• Mentre per il servizio non confermato:
– request();
– indication().
• Connect è sempre confermato
(ovviamente), ma altri servizi no.
D. Rosaci
Sistemi Distribuiti - Comunicazione
24
Esempio di servizio connectoriented
1.
2.
3.
4.
5.
6.
7.
connect.request();
connect.indication();
connect.response();
connect.confirm();
data.request(): si cerca di inviare dati;
data.indication(): sono arrivati dei dati;
disconnect.request(): si vuole terminare la
connessione;
8. disconnect.indication(): l'altra entity vuole
terminare.
D. Rosaci
Sistemi Distribuiti - Comunicazione
25
La realtà nel mondo delle
Reti
Iniziamo ad esaminare due importanti realtà nel mondo delle reti:
1.OSI Reference Model;
2.Internet Protocol Suite (detta anche architettura TCP/IP o,
piuttosto impropriamente, TCP/IP reference model).
Un modello di riferimento è cosa diversa da un'architettura di rete:
Modello di
riferimento
definisce il numero, le relazioni e
le caratteristiche funzionali dei
livelli, ma non definisce i
protocolli effettivi
Architettura
di rete
definisce, livello per livello, i
protocolli effettivi
D. Rosaci
Sistemi Distribuiti - Comunicazione
26
Il modello ISO-OSI
• L'OSI (Open Systems Interconnection) Reference
Model è il frutto del lavoro della ISO (International
Standard Organization), ed ha lo scopo di:
• fornire uno standard per la connessione di sistemi
aperti, cioé in grado di colloquiare gli uni con gli
altri;
• fornire una base comune per lo sviluppo di standard
per l'interconnessione di sistemi;
• fornire un modello rispetto a cui confrontare le varie
architetture di rete.
D. Rosaci
Sistemi Distribuiti - Comunicazione
27
Principi di progetto del modello
OSI
• Esso non include di per se la definizione di protocolli specifici
(che sono stati definiti successivamente, in documenti
separati).
• Principi di progetto seguiti durante lo sviluppo del modello OSI:
– ogni livello deve avere un diverso livello di astrazione;
– ogni livello deve avere una funzione ben definita;
– la scelta dei livelli deve:
• minimizzare il passaggio delle informazioni fra livelli;
• evitare:
– troppe funzioni in un livello;
– troppi livelli.
D. Rosaci
Sistemi Distribuiti - Comunicazione
28
I livelli del modello OSI
• Il modello OSI
consiste di 7 livelli
(i maligni dicono
che ciò fu dettato
dal desiderio di
rendere il modello
compatibile con
l'architettura SNA
dell'IBM).
7
Application
6
Presentation
5
Session
4
Transport
Application protocol
Presentation protocol
Presentation
Session protocol
Session
Application protocol
Transport
Subnet di comunicazione
3
Network
Network
Network
Network
2
Data Link
Data Link
Data Link
Data Link
1
Fisico
Fisico
Fisico
Fisico
HOST 1
ROUTER
ROUTER
HOST 2
Protocolli host - router
D. Rosaci
Application
Protocolli router - router
Sistemi Distribuiti - Comunicazione
Protocolli host - router
29
OSI 1 – Il livello fisico
• Livello fisico
• Ha a che fare con la trasmissione di bit "grezzi" su un canale
di comunicazione.
• Gli aspetti di progetto sono:
– volti a garantire che se parte un 1, arrivi effettivamente un 1 e
non uno zero;
– largamente riguardanti le caratteristiche meccaniche, elettriche e
procedurali delle interfacce di rete (componenti che connettono
l'elaboratore al mezzo fisico) e le caratteristiche del mezzo fisico.
• Si caratterizzano, tra gli altri:
–
–
–
–
D. Rosaci
tensioni scelte per rappresentare 0 ed 1;
durata (in microsecondi) di un bit;
trasmissione simultanea in due direzioni oppure no;
forma dei connettori.
Sistemi Distribuiti - Comunicazione
30
OSI 2 – Il livello Data Link
•
•
•
•
Scopo: far si che un mezzo fisico trasmissivo appaia, al livello superiore, come
una linea di trasmissione esente da errori di trasmissione non rilevati.
Normalmente funziona così:
– spezzetta i dati provenienti dal livello superiore in frame (da qualche
centinaia a qualche migliaia di byte);
– invia i frame in sequenza;
– aspetta un acknowledgement frame (ack) per ogni frame inviato.
Incombenze:
– aggiunta di delimitatori (framing) all'inizio ed alla fine del frame
– gestione di errori di trasmissione causati da errori in ricezione, perdita di
frame, duplicazione di frame (da perdita di ack);
– regolazione del traffico (impedire che il ricevente sia "sommerso" di dati);
– meccanismi per l'invio degli ack
Le reti broadcast hanno un'ulteriore problema: il controllo dell'accesso al canale
trasmissivo, che è condiviso. Per questo hanno uno speciale sottolivello del
livello data link, il sottolivello MAC (Medium Access Control).
D. Rosaci
Sistemi Distribuiti - Comunicazione
31
OSI 3 – Il livello Network
•
•
•
Scopo: controllare il funzionamento della subnet di comunicazione.
Inizialmente tale livello offriva solamente servizi connection oriented;
successivamente fu aggiunta la modalità connectionless.
Incombenze:
– routing, cioé scelta del cammino da utilizzare. Può essere:
• statico (fissato ogni tanto e raramente variabile);
• dinamico (continuamente aggiornato, anche da un pacchetto
all'altro);
– gestione della congestione: a volte troppi pacchetti arrivano ad
un router (es.: da molte linee in ingresso ad un unica linea di
uscita);
– accounting: gli operatori della rete possono far pagare l'uso agli
utenti sulla base del traffico generato;
– conversione di dati nel passaggio fra una rete ed un'altra
(diversa):
• indirizzi da rimappare;
• pacchetti da frammentare;
• protocolli diversi da gestire.
D. Rosaci
Sistemi Distribuiti - Comunicazione
32
OSI 4 – Il livello Transport
• Scopo: accettare dati dal livello superiore, spezzettarli in
pacchetti, passarli al livello network ed assicurarsi che arrivino
alla peer entity che si trova all'altra estremità della
connessione. In più, fare ciò efficientemente, isolando i livelli
superiori dai cambiamenti della tecnologia di rete sottostante.
• Il livello transport è il primo livello realmente end-to-end, cioé
da host sorgente a host destinatario: le peer entity di questo
livello portano avanti una conversazione senza intermediari.
• Queste problematiche sono, in ambito end-to-end, le stesse
che il livello data link ha nell'ambito di una singola linea di
comunicazione; le soluzioni però sono alquanto diverse per la
presenza della subnet
D. Rosaci
Sistemi Distribuiti - Comunicazione
33
OSI 4 – Incombenze del livello
Transport
● creazione di connessioni di livello network per ogni
connessione di livello transport richiesta:
- normalmente, una connessione network per ciascuna
connessione transport;
- per ottenere un alto throughput: molte connessioni
network per una singola connessione transport;
- se è alto il costo di una connessione network: una
singola connessione network viene usata per molte
connessioni transport, con meccanismi di multiplexing;
• offerta di vari servizi al livello superiore:
– canale punto a punto affidabile, che consegna i dati in
ordine e senza errori (il servizio più diffuso, connection
oriented);
– invio di messaggi isolati, con o senza garanzia di
consegna (connectionless);
– broadcasting di messaggi a molti destinatari
(connectionless).
D. Rosaci
Sistemi Distribuiti - Comunicazione
34
OSI 5 – Il livello Session
• Ha a che fare con servizi più raffinati
che non quelli del transport layer,
come ad es.:
• token management: autorizza le due
parti, a turno, alla trasmissione.
• Come vedremo nel seguito, questo
livello non ha avuto un grande
successo.
D. Rosaci
Sistemi Distribuiti - Comunicazione
35
OSI 6 – Il livello Presentation
• E' interessato alla sintassi ed alla
semantica delle informazioni da
trasferire. Ad esempio, si occupa di
convertire tipi di dati standard
(caratteri, interi) da rappresentazioni
specifiche della piattaforma HW di
partenza in una rappresentazione "on
the wire" e poi in quella specifica dell'
HW di arrivo.
• Anche questo livello non ha avuto
D. Rosaci
Sistemi Distribuiti - Comunicazione
molto successo.
36
OSI 7 – Il livello Application
• Prevede che qui risieda tutta la varietà di protocolli
che sono necessari per offrire i vari servizi agli
utenti, quali ad esempio:
– terminale virtuale;
– transferimento file;
– posta elettronica.
• Attraverso l'uso di questi protocolli si possono
scrivere applicazioni che offrono i suddetti servizi
agli utenti finali.
D. Rosaci
Sistemi Distribuiti - Comunicazione
37
L’architettura TCP/IP
• La "madre di tutte le reti" fu Arpanet, originata da un progetto
di ricerca finanziato dal DoD (Department of Defense)
americano. Lo scopo era creare una rete estremamente
affidabile anche in caso di catastrofi (o eventi bellici) che ne
eliminassero una parte. Arpanet, attraverso varie evoluzioni,
ha dato origine alla attuale Internet.
• Nel corso dello sviluppo, per integrare via via tipi diversi di reti,
si vide la necessità di una nuova architettura, mirata fin
dall'inizio a consentire l'interconnessione di molteplici reti
(internetwork).
• L'architettura divenne, più tardi, nota coi nomi di Internet
Protocol Suite, architettura TCP/IP e TCP/IP reference
model, dal nome dei suoi due protocolli principali. Essa non è
un modello nel senso stretto del termine, in quanto include i
protocolli effettivi, che sono specificati per mezzo di documenti
detti RFC (Request For Comments).
D. Rosaci
Sistemi Distribuiti - Comunicazione
38
Relazione tra TCP/IP e OSI
OSI
Tcp/Ip
Application
Application
Presentation
Session
Tranport
Transport
Network
Internet
Data Link
Fisico
Host - to - Network
I requisiti di progetto stabiliti fin dall'inizio (estrema affidabilità e
tolleranza ai guasti, possibilità di interconnessione di più reti)
portarono alla scelta di una rete:
•packet-switched;
•basata su un livello connectionless di internetwork.
D. Rosaci
Sistemi Distribuiti - Comunicazione
39
TCP/IP: il livello Host-toNetwork
• Il livello più basso non è specificato
nell'architettura, che prevede di
utilizzare quelli disponibili per le varie
piattaforme HW e conformi agli
standard.
• Tutto ciò che si assume è la capacità
dell'host di inviare pacchetti IP sulla
rete.
D. Rosaci
Sistemi Distribuiti - Comunicazione
40
TCP/IP: il livello Internet
• E' il livello che tiene insieme l'intera architettura. Il suo ruolo è
permettere ad un host di iniettare pacchetti in una qualunque
rete e fare il possibile per farli viaggiare, indipendentemente gli
uni dagli altri e magari per strade diverse, fino alla
destinazione, che può essere situata anche in un'altra rete.
Dunque è connectionless. E' un servizio best-effort
datagram. E' definito un formato ufficiale dei pacchetti ed un
protocollo, IP (Internet Protocol).
• Incombenze:
– routing;
– controllo congestione.
D. Rosaci
Sistemi Distribuiti - Comunicazione
41
TCP/IP: il livello Transport
• E' progettato per consentire la conversazione delle
peer entity sugli host sorgente e destinazione (endto-end). Sono definiti due protocolli in questo livello:
• TCP (Transmission Control Protocol): è un
protocollo connesso ed affidabile (ossia tutti i
pacchetti arrivano, e nell'ordine giusto). Frammenta
il flusso in arrivo dal livello superiore in messaggi
separati che vengono passati al livello Internet. In
arrivo, i pacchetti vengono riassemblati in un flusso
di output per il livello superiore.
• UDP (User Datagram Protocol): è un protocollo
non connesso e non affidabile, i pacchetti possono
arrivare in ordine diverso o non arrivare affatto.
D. Rosaci
Sistemi Distribuiti - Comunicazione
42
TCP/IP: il livello Application
• Nell'architettura TCP/IP non ci sono i livelli session e
presentation (non furono ritenuti necessari; l'esperienza col
modello OSI ha mostrato che questa visione è condivisibile).
• Sopra il livello transport c'è direttamente il livello application, che
contiene tutti i protocolli di alto livello vengono usati dalle
applicazioni reali.
• I primi protocolli furono:
– Telnet: terminale virtuale;
– FTP (File Transfer Protocol): file transfer;
– SMTP (Simple Mail Transfer Protocol) e POP (Post Office
Protocol): posta elettronica.
• Successivamente se ne sono aggiunti altri, fra cui:
– DNS (Domain Name Service): mapping fra nomi di host e indirizzi
IP numerici;
– NNTP (Network News Transfer Protocol): trasferimento di articoli
per i newsgroup;
– HTTP (HyperText Transfer Protocol): alla base del Word Wide
Web.
D. Rosaci
Sistemi Distribuiti - Comunicazione
43
Confronto tra modello OSI e
architettura TCP/IP
• Somiglianze:
– basati entrambi sul concetto di pila di protocolli
indipendenti;
– funzionalità simili in entrambi per i vari livelli.
• Differenze di fondo:
– OSI nasce come modello di riferimento
(utilissimo per le discussioni generali), i protocolli
vengono solo successivamente;
– TCP/IP nasce coi protocolli, il modello di
riferimento viene a posteriori.
D. Rosaci
Sistemi Distribuiti - Comunicazione
44
Comunicazione attraverso
middleware
• Esempio: sistema di posta elettronica
• Può essere visto come un supporto
middleware per la comunicazione
• Ogni host esegue uno user agent che
consente all’utente di comporre, inviare e
ricevere messaggi di posta.
• Lo user agent passa la mail al sistema di
consegna delle mail
• Il sistema di consegna recapita l’email allo
user agent del destinatario
D. Rosaci
Sistemi Distribuiti - Comunicazione
45
Tipi di comunicazione:
Comunicazione Persistente
• Comunicazione persistente: come
nell’esempio precedente, il messaggio
immesso viene memorizzato dal middleware
per tutto il tempo necessario alla consegna.
• Non è necessario che l’applicazione
mittente continui l’applicazione dopo l’invio
del messaggio
• Non è necessario che l’applicazione
destinataria sia in esecuzione quando il
messaggio è inviato
D. Rosaci
Sistemi Distribuiti - Comunicazione
46
Tipi di comunicazione:
Comunicazione Transiente
• Il messaggio è memorizzato dal middleware
solo finchè le applicazioni mittente e
destinatario sono in esecuzione
• Se la consegna non è possibile, il
messaggio viene cancellato
• E’ il caso della comunicazione di rete a
livello di trasporto: i router memorizzano ed
inoltrano, e se non è possibile inoltrare,
cancellano
D. Rosaci
Sistemi Distribuiti - Comunicazione
47
Comunicazione
Sincrona/Asincrona
• Sincrona: Una volta sottomesso il messaggio,
l’applicazione mittente si blocca finchè l’operazione
non si è completata
• Asincrona: Una volta sottomesso il messaggio,
l’applicazione mittente può eseguire altri task: il
messaggio viene memorizzato temporaneamente
fino ad avvenuta trasmissione
D. Rosaci
Sistemi Distribuiti - Comunicazione
48
Comunicazione discreta ed a
streaming
• Discreta: ogni messaggio costituisce
un’unità di informazione completa,
come nel caso dell’e-mail
• Streaming: Comporta l’invio di molti
messaggi, in relazione temporale tra
loro, che servono a ricostruire
un’informazione completa
D. Rosaci
Sistemi Distribuiti - Comunicazione
49
Comunicazione discreta ed a
streaming
• Discreta: ogni messaggio costituisce
un’unità di informazione completa,
come nel caso dell’e-mail
• Streaming: Comporta l’invio di molti
messaggi, in relazione temporale tra
loro, che servono a ricostruire
un’informazione completa
D. Rosaci
Sistemi Distribuiti - Comunicazione
50
Chiamate a procedure remote
• Usare le primitive send() e reveive()
per far comunicare i processi non
realizza la trasparenza dei sistemi
distribuiti
• La soluzione a questo problema fu
proposta nel 1984 (Birrell e Nelson):
consentire ai processi di chiamare
procedure posizionate su altre
macchine
D. Rosaci
Sistemi Distribuiti - Comunicazione
51
Chiamate a procedure remote -1
• Quando un processo sulla macchina A
richiama una procedura sulla macchina B, il
processo su A viene sospeso e la procedura
chiamata viene eseguita su B
• Le informazioni possono passare dal
chiamante al chiamato attraverso dei
parametri, ed anche i risultati possono
essere veicolati da parametri
• Nessun passaggio di messaggi è visibile al
programmatore
• Remote Procedure Call (RPC)
D. Rosaci
Sistemi Distribuiti - Comunicazione
52
Chiamate a procedura locale
•
•
Esempio di chiamata convenzionale:
– Count=read(fd,buf,bytes)
Dove fd è un intero che indica un file, buf è un array di byte e nbytes indica
quanti byte dobbiamo leggere dall’array.
Il programma chiamante
inserisce sullo stack i
parametri e l’indirizzo di
ritorno
La procedura read mette
sullo stack il valore di ritorno
e restituisce il valore al
programma chiamante
D. Rosaci
Sistemi Distribuiti - Comunicazione
53
Chaimata a procedura locale - 1
•
passaggio dei parametri per valore
–
•
passaggio dei parametri per riferimento
–
•
Un parametro come fd o bytes viene semplicemente copiato sullo stack. La
procedura chiamata può modificarlo, ma ciò non ha ripercussioni sulla variabile
originale
Il parametro rappresenta un riferimento ad una variabile, come nel caso del
parametro buf che rappresenta l’indirizzo di un vettore. Ogni modifica fatta dal
programma chiamato è effettuata sulla variabile originale
passaggio dei parametri per copia-ripristino
–
D. Rosaci
Come nel passaggio per valore, la variabile originale è copiata sullo stack. Al
termine del programma chiamato, il valore modificato sullo stack è ricopiato sulla
variabile originale. Produce effetti simili al passaggio per riferimento, ma quando
nella lista dei parametri un parametro appare più volte, la semantica di questo
passaggio è diversa dal passaggio per riferimento
Sistemi Distribuiti - Comunicazione
54
Chiamate a procedura remota:
Client Stub
•
•
•
•
•
Idea di base: rendere le chiamate a procedure remote quanto più simili a
chiamate locali
Le RPC devono essere trasparenti: la procedura chiamante non deve sapere
che la procedura chiamata sta su una macchina remota
Caso della procedura read mostrata in esempio: in un sistema tradizionale, il
programmatore mette nel suo codice una chiamata a read per ottenere i dati. La
routine read è estratta dal linker dalla libreria ed inserita nel codice oggetto.
Quando è eseguita, la procedura read si comporta come descritto in
precedenza, esegue una chiamata al sistema operativo locale per ottenere i dati
e mette il risultato sullo stack. Quindi il suo operato è trasparente al programma
chiamante, che si è limitato ad invocare la procedura coi parametri corretti
Le RPC ottengono la trasparenza in modo analogo: quando la read è in realtà
una procedura remota, ne viene messa in libreria una copia, chiamata client
stub.
Anche il client stub esegue una chiamata al sistema operativo locale, ma non
per ottenere i dati come nel caso precedente. In realtà esso esegue una
chiamata alla primitiva send, impacchettando i parametri della read in un
messaggio per la macchina remota su cui sta la procedura chiamata. Poi
esegue una receive e si blocca aspettando i risultati.
D. Rosaci
Sistemi Distribuiti - Comunicazione
55
Chiamate a procedura remota:
Server Stub
•
•
•
•
Quando il messaggio raggiunge la macchina remota, il sistema operativo di
quest’ultima lo passa al server stub
Il server stub è un pezzo di codice che trasforma le richieste provenienti dalla
rete in chiamate a procedura locale
Il server stub spacchetta il messaggio, chiama la procedura read locale nel solito
modo (parametri sullo stack) e quando riprende il controllo a procedura
eseguita, impacchetta il risultato e lo invia al client stub chiamante. Quindi
esegue nuovamente una receive e si blocca in attesa della successiva chiamata
Quando il messaggio arriva al sistema operativo chiamante, esso viene passato
al processo che ha chiamato la send, ovvero al client stub. Quest’ultimo
spacchetta il messaggio, estrae il risultato e lo mette in cima allo stack della
procedura che ha chiamato la read. Quest’ultima è semplicemente informata
che il risultato è ora disponibile sullo stack, e non deve preoccuparsi di come ciò
sia stato possibile
D. Rosaci
Sistemi Distribuiti - Comunicazione
56
Passaggio dei parametri in RPC
•
La funzione del client stub è di prendere i parametri della procedura,
impacchettarli in un messaggio ed inviarli al server stub. L’operazione di
impacchettamento è denominata marshaling dei parametri.
D. Rosaci
Sistemi Distribuiti - Comunicazione
57
Passaggio dei parametri in RPC
•
•
•
•
La funzione del client stub è di prendere i parametri della procedura,
impacchettarli in un messaggio ed inviarli al server stub. L’operazione di
impacchettamento è denominata marshaling dei parametri.
Finchè le macchine mittente e destinataria sono identiche ed i parametri passati
sono di tipo scalare (int, char, ecc.) tutto funziona perfettamente
Ma se una macchina mainframe IBM, che per i caratteri usa la codifica EBCDIC,
comunica con un personal computer IBM che usa la codifica ASCII, lo schema
di cui sopra non funziona.
Un altro problema si verifica tra macchine che usano numerare i byte da destra
a sinistra (little endian), come le INTEL, quando comunicano con macchine che
usano numerare i byte da sinistra a destra (big endian), come le SPARC.
D. Rosaci
Sistemi Distribuiti - Comunicazione
58
Passaggio dei parametri in RPC
•
Se mandiamo un messaggio che contiene l’intero 5 e la stringa GIANNI da una
macchina INTEL ad una SPARC, ecco cosa succederà
Messaggio originale: 5 000 0 I N N A I G per l’INTEL significa intero 5 stringa
GIANNI, perché per INTEL 5 0 0 0 significa byte meno significativo 5, byte più
significativo zero, così come I N N A I G significa byte meno significativo (quindi
carattere di fine parola) I, byte più significativo (quindi carattere inizio di parola)
G
Messaggio ricevuto dalla SPARC: 5 0 0 0 I N N A I G per la SPARC significa intero
5*2^24, stringa GIANNI, perché per SPARC 5 0 0 0 significa byte meno
significativo 0, bit più significativo 5 (che quindi pesa 2^24 perché preceduto dai
24 bit 0…23.
Invertire il messaggio mandato da INTEL avrebbe effetto sull’intero 5, ma non sulla
stringa. Infatti per 0 0 0 5 G I A N N I significherebbe intero 5 stringa IANNIG!
D. Rosaci
Sistemi Distribuiti - Comunicazione
59
Passaggio dei parametri in RPC
•
Soluzione: richiedente e ricevente devono concordare il formato del messaggio
–
–
–
–
Stabilire se la codifica è little endian o big endian
Stabilire in che formato sono codificati i caratteri (es. ASCII)
0
Stabilire in che formato sono codificati gli interi (es. UNICOD) ed i float (es. IEEE 754)
Definire il servizio di connessione (es. TCP/IP)
Definito il protocollo RPC, gli stub devono essere implementati. Fortunatamente, gli stub
per lo stesso protocollo ma per procedure diverse differiscono solo per le loro
interfacce alle applicazioni
Per semplificare le cose, le interfacce sono realizzabili tramite un linguaggio per la
definizione delle interfacce IDL. Un’interfaccia realizzata in IDL può quindi essere
compilata in un client stub ed in un server stub
D. Rosaci
Sistemi Distribuiti - Comunicazione
60
Altro problema: passaggio per
riferimento
•
•
•
•
Un riferimento è un indirizzo in memoria, e quindi è valido solo nel contesto in
cui è usato. Se il client stub usa per il parametro buf (l’indirizzo del buffer) il
valore 100, non possiamo aspettarci che questo valore abbia senso per il server
stub, dove l’indirizzo 100 indicherà una qualche imprecisata area di memoria
La soluzione è semplice: il client stub sa che il parametro buf è l’indirizzo di un
vettore, quindi può copiare il vettore nel messaggio ed inviarlo al server stub.
Quest’ultimo effettuerà le operazioni col vettore copia, usando lo spazio di
indirizzi della macchina ricevente. Se eventualmente si dovesse effettuare una
modifica sul vettore copia, questa sarebbe poi riportata dal client stub sul vettore
originale
Si è usato un meccanismo di copia-ripristino
Ottimizzazione: 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
D. Rosaci
Sistemi Distribuiti - Comunicazione
61
RPC Asincrone
•
•
•
•
In modalità sincrona, una chiamata RPC provoca la messa in attesa del
processo chiamante, fintanto che la chiamata stessa non sia stata eseguita e il
risultato sia stato restituito
In diverse situazioni, in cui il processo chiamato non deve restituire nessun
risultato, non è necessario tale blocco del processo chiamante
Alcuni sistemi RPC forniscono quindi la possibilità di effettuare chiamate RPC
asincrone, permettendo al processo chiamante, una volta effettuata la chiamata
e ricevuto un acknowledge dallo stub server attestante che la chiamata è stata
ricevuta ed avviata, di dedicarsi ad altri task
Se il processo chiamante riprende la sua esecuzione senza aspettare
l’acknowledge, l’RPC asincrona si chiama “a senso unico”.
D. Rosaci
Sistemi Distribuiti - Comunicazione
62
Comunicazione orientata ai
messaggi
•
•
•
•
•
Non sempre le RPC sono adatte a supportare la comunicazione in un sistema
distribuito
Non lo sono soprattutto quando non si può essere certi che l’interlocutore sia
collegato in rete
In questi casi, la natura essenzialmente sincrona delle RPC comporta una
perdita di efficacia nella comunicazione
La comunicazione orientata ai messaggi sostituisce le chiamate a procedure
remote con messaggi
Può essere usata sia con interlocutori online sia con interlocutori offline
D. Rosaci
Sistemi Distribuiti - Comunicazione
63
Comunicazione transiente
orientata ai messaggi:SOCKET
• Molti sistemi distribuiti usano il semplice
modello di scambio di messaggi fornito dal
sistema di trasporto
• Intrefaccia standard del sistema di trasporto:
Socket del TCP
• Una socket è una porta di comunicazione
astratta su cui si possono scrivere e da cui
si possono leggere dati
D. Rosaci
Sistemi Distribuiti - Comunicazione
64
Socket: Primitive lato Server
• Socket: crea una nuova porta di
comunicazione
• Bind: associa un indirizzo locale alla porta
appena creata (es. un server associerà
l’indirizzo IP della macchina e il numero di
porta reale su cui vuole ricevere messaggi)
• Listen: usata solo in comunicazioni orientate
alla connessione. Chiamata non bloccante
che annuncia la disponibilità ad accettare
connessioni
• Accept: blocca il chiamante finchè non
arriva una richiesta di connessione.
D. Rosaci
Sistemi Distribuiti - Comunicazione
65
Socket: Primitive lato Client
• Socket: il binding all’indirizzo locale non è
necessario in quanto il sistema operativo
può allocare dinamicamente una porta
quando la connessione viene stabilita
• Connect: richiede che il chiamante specifichi
l’indirizzo a cui va inviata la richiesta di
connessione. Il client è bloccato finchè la
connessione non è stabilita
D. Rosaci
Sistemi Distribuiti - Comunicazione
66
Gestione della comunicazione
da entrambi i lati
• Send: invia dati sulla connessione
• Receive: riceve dati dalla connessione
• Close: rilascia la connessione (deve
essere eseguita da ambo le parti)
• Il modello a socket è molto utilizzato
per programmare in rete in ambiente
UNIX
D. Rosaci
Sistemi Distribuiti - Comunicazione
67
Comunicazione transiente
orientata ai messaggi:MPI
•
•
•
•
•
MPI sta per Message Passing Interface (interfaccia per lo scambio di
messaggi)
E’ un protocollo a livello di astrazione più alto rispetto alle socket
Le socket sono state progettate per lavorare in ambiente TCP/IP: non
sono adatte ad ambienti proprietari sviluppati per reti ad alta velocità,
dove sono richieste funzionalità più avanzate (es. cluster di server ad
alte prestazioni)
MPI suppone che la comunicazione abbia luogo tra gruppi di processi
conosciuti. Ogni processo è identificato da un ID di processo e da un
ID di gruppo, e una coppia (procID,groupID) è usata come
destinatario o sorgente della comunicazione al posto degli IP.
La comunicazione transiente è qui asincrona. Mediante la primitiva
MPI_bsend, il mittente invia anzitutto il messaggio al sistema runtime
di MPI, che lo bufferizza e lo recapita al destinatario quando
possibile, lasciando libero il mittente di fare altro. Quando il
destinatario chiamerà la primitiva receive il messaggio sarà inoltrato
D. Rosaci
Sistemi Distribuiti - Comunicazione
68
Comunicazione persistente:
Sistemi a code di messaggi
• Idea base: le applicazioni comunicano inserendo
messaggi in apposite code
• Di solito ogni applicazione ha la sua coda (a volte
esistono anche code condivise da più applicazioni)
• Un mittente ha solo la garanzia che il suo
messaggio venga inserito in coda del destinatario:
non c’è bisogno che il destinatario sia online al
momento della trasmissione, né che il mittente sia
online al momento della ricezione
• Primitive principali: put (per inserire un messaggio
nella coda del destinatario) e get (per prelevare un
messaggio dalla coda)
• Esempio: IBM WebSphere
D. Rosaci
Sistemi Distribuiti - Comunicazione
69