IPC in ambiente distribuito
 Caratteristiche dei sistemi distribuiti:
•
•
•
•
esecuzione concorrente
mancanza di nozione di tempo globale
ritardo nella comunicazione
difficolta’ di avere una nozione di stato
consistente
• possibilita’ di failure di un componente
IPC in ambiente distribuito
 Problemi di base nei sistemi distribuiti:
 dove localizzare gli oggetti: locating
 come gestire lo spazio dei nomi: naming
 Due modelli per IPC distribuito:
 modello a oggetti (Accent, Mach)
 modello client/server (Amoeba)
 Due approcci per sistemi di architetture a
rete:
 sistemi di rete: la rete non e’ trasparente alle
applicazioni
 sistemi distribuiti: la rete e’ trasparente alle
applicazioni
IPC in ambiente distribuito:
scambio di messaggi
 Un meccanismo di scambio di messaggi in ambiente
distribuito differisce dall’analogo in ambiente
fortemente connesso perche’:
• il livello IPC e’ costruito sul livello inferiore della
comunicazione di rete.
• il livello IPC deve fornire anche la funzione di
naming e di location:
• se il processo A, sul nodo 1 manda un messaggio al
processo B, l’ IPC deve riconoscere che B non e’ un
processo locale e deve trovare dove risiede.
IPC in ambiente distribuito:
scambio di messaggi
Scambio di messaggi asincrono:
Process A
Process B
SEND (pid, mess)
WAIT (send, add)
Livello IPC
WAIT
Livello IPC
SEND
Funzione di naming e di location
Comunicazione di rete
WAIT
SEND
Funzione di naming e di location
Comunicazione di rete
IPC in ambiente distribuito:
scambio di messaggi
Cammini reali e virtuali di scambio di messaggio
Process A (Nodo 1)
Process B (Nodo 2)
SEND
WAIT
IPC Level
IPC Level
Network
communication
Network
Communication
IPC in ambiente distribuito:
scambio di messaggi
Per realizzare lo scambio di messaggi in modo
trasparente ci sono due approcci:
 il kernel determina se il processo e’ o meno locale e
nel caso sia remoto fornisce il suo indirizzo
(location function)
 il kernel determina se il processo e’ o meno locale e
nel caso non lo sia, passa il messaggio ad un
processo locale, responsabile della comunicazione
NetServer process. Questo approccio e’ usato in
Accent e Mach. In questo modo il kernel e’ piu’
semplice, ma ci sono piu’ switch di processi
IPC in ambiente distribuito:
scambio di messaggi
NetServer Process
Process A (Nodo 1)
NetServer process
SEND (B, mess)
WAIT (any)
Call Network
Communication
IPC Level
scopre che B
non e’ locale
Network
Communication Software
IPC in ambiente distribuito:
RPC
 Un’ alternativa ai messaggi sincroni e asincroni e’ il
paradigma RPC, ampiamente usato nelle architetture
di rete.
 Un sistema RPC consiste di:
• un protocollo di comunicazione costruito sul livello
di trasporto (ARPA UDP/IP)
• routine per assemblare i dati da passare al
protocollo
• un meccanismo per legare i nomi delle procedure
remote agli indirizzi di rete
IPC in ambiente distribuito:
RPC
Un sistema RPC
Calling System (client)
Caller
RPC
service
Lower
level
protocol
Called System (server)
A
Lower
level
protocol
RPC
service
procedure
B
A
call
Network
E
return
Called
call
D
C
return
IPC in ambiente distribuito:
RPC
 gli argomenti sono impacchettati in una struttura dati adatta al
trasferimento attraverso alla rete
 a questa chiamata e’ assegnato un identificatore RPC
 viene settato un timer
A
B
D
E
 gli argomenti sono “spacchettati” dal buffer di rete e messi in
forma adatta per fare una chiamata di procedura locale
 si prende nota dell’ identificatore RPC
 gli argomenti di ritorno sono impacchettaati
 viene settato un altro timer
 gli argomenti di ritorno sono spacchettati
 il timer del punto A viene disabilitato
 un acknowledgment e’ inviato a D che puo’disabilitare il timer
IPC in ambiente distribuito:
RPC con malfunzionamento
 A causa di malfunzionamenti o congestione nella rete i due
timer al punto A e D possono scadere senza che la
comunicazione sia stata completata.
 Il servizio di RPC, al punto A puo’ ritentare piu’ volte la
comunicazione senza coinvolgere il livello d’applicazione. L’
identificativo RPC serve al sistema chiamato (server) per
scoprire una chiamata ripetuta. Se questa e’ gia’ in corso non e’
necessario fare nulla, se una risposta e’ gia’ stata inviata puo’
essere riinviata. Questo comportamento e’ detto: EXACTLY
ONCE RPC Semantics.
 Alcuni sistemi RPC danno all’utente la scelta tra la semantica
EXACTLY ONCE e la AT MOST ONCE RPC Semantics che
significa che quando scade il timer, il controllo torna
all’applicativo, che decide se vuole o meno ritentare la
comunicazione.
IPC in ambiente distribuito:
RPC con crash e restart
Failure dalla parte del cliente
 Il cliente fallisce dopo aver inviato una richiesta.
 La chiamata remota prosegue (orfana)
 Nessun acknowledgment sara’ da D, allo scadere del
timer
 Se il server ha servito la richiesta questo puo’ aver
causato cambi permenenti nel server
 Il nodo cliente, una volta ripartito puo’ far ripartire la
richiesta, ma questa avra’ un altro identificativo
(checkpoint e rollback facilities)
IPC in ambiente distribuito:
RPC con crash e restart
 Failure dalla parte del server
 Il server fallisce dopo che il cliente ha una richiesta.
 Il fallimento puo’ essere al punto B o C o D: in ogni
caso il timer al punto A scade senza che ci sia stata
risposta.
 Il cliente potrebbe rifare la richiesta
 Se il fallimento e’ stato al punto C o D, questo puo’
aver causato cambi permanenti prima del crash
 Il nodo cliente, una volta ripartito puo’ far ripartire la
richiesta, ma questa avra’ un altro identificativo
(checkpoint e rollback facilities)
IPC in ambiente distribuito:
RPC e i livelli ISO
RPC in relazione al modello ISO/OSI
Livello Applicazione
Invocazione dal linguaggio
Livello Presentazione
Rapprresentazione dati
Protocollo RPC
Livello Sessione
Gestione timer e
primitive sincronizzazione
Livello Trasporto
Es. UDP
Livello Rete
Livello Datalink
Es. IP
Es.. Ethernet protocol
IPC in ambiente distribuito:
integrazione di RPC con i linguaggi
 Trasparenza della distribuzione
 Approccio non trasparente: l’applicazione sa quali sono
procedure remote e quali locali.
 Vantaggi: il programmatore puo’ organizzarsi meglio sapendo
che le chiamate remote richiedono piu’ tempo e che
potrebbero fallire.
 Approccio trasparente: e’ il compilatore (o un preprocessore)
che deve scoprire quali procedure sono locali e quali non locali.
E’ necessario avere un servizio di naming che elenca le
procedure non locali. Ad ogni chiamata di procedura remota
viene creata una stub, cui viene indirizzata localmente la
chiamata.
IPC in ambiente distribuito:
integrazione di RPC con i linguaggi
Implementazione di RPC trasparente
Call RPROC A (arg)
RPROC A
Process
level
Process level
Client
STUB for A
Server
STUB for A
RPC implementation level
RPC implementation level
Lower leve of
communication
softwarel
Lower level of
communication
software
Client System
Server System
network
IPC in ambiente distribuito:
integrazione di RPC con i linguaggi
 Approccio trasparente.
 Lo STUB si occupa di:
 controllare l’ assemblaggio degli argomenti
 invocare il protocollo di comunicazione
 Att!! Le funzioni dello STUB sono necessarie anche
nell’ approccio non trasparente, l’unica differenza e’
che nell’approccio trasparente lo STUB viene
chiamato come una procedura locale.
IPC in ambiente distribuito:
Client/Server vs Oggetti
 Il modello client/server e’ un approccio piu’ semplice:
gli oggetti sono identificati (naming) e locati
(locating) dal server e le operazioni su di essi sono
eseguite dal server stesso.
 Nell’ approccio a oggetto gli oggetti hanno un nome e
una locazione in un contesto globale e le operazioni su
di essi sono eseguite dagli utenti direttamente
piuttosto che tramite il server.
 Nell’ approccio a oggetto i nomi degli oggetti hanno
un significato globale e quindi possono essere passati
per riferimento.
IPC in ambiente distribuito:
critica di RPC
 Scelta implementativa:
 numero massimo di RPC aperte in un certo istante da parte
di threads di uno stesso processo.
 Scelta a livello di progetto di sistema:
 il paradigma RPC e’ sufficiente a rispondere a tutte le
necessita’ del sistema? Si potrebbero affiancare possibilita’
diverse:
 primitive di SEND senza necessita’ di acknowledgment
 RPC asincrono (versione di RPC in cui il cliente puo’
continuare la sua attivita’ e prelevare la risposta piu’ tardi
 stream protocol (connessione source-destination) per
grandi quantita’ di dati (video e voce)
IPC in ambiente distribuito:
naming
 In un sistema fortemente connesso il SO (kernel) conosce il
nome di tutti i processi, il loro spazio degli indirizzi e gli
indirizzi delle loro eventuali porte.
 In un sistema distribuito l’IPC deve conoscere i nomi degli
oggetti coinvolti nella comunicazione; in particolare occorre
stabilire :
• Quali oggetti devono essere identificati con un nome
(processi, porte, mailbox, procedure remote,..)
• Come devono essere strutturati tali nomi
• Come un potenziale cliente trova il nome del server
• Quando viene fatto il legame tra nome e indirizzo di rete
• Chi controlla la comunicazione
IPC in ambiente distribuito:
naming
 Problema: assegnare un nome unico agli oggetti di un sistema
distribuito.
 Soluzione: nell’ ipotesi che ogni nodo abbia un identificatore
unico (indirizzo di rete) ogni oggetto potrebbe avere come nome
la coppia:
 <numero del nodo, numero dell’oggetto all’interno del nodo>
 Svantaggi: un oggetto e’ legato in modo permanente al nodo
I nomi devono essere indipendenti dalla locazione
IPC in ambiente distribuito:
naming
 Problema: assegnare agli oggetti di un sistema distribuito un
nome unico

indipendente dalla locazione
 Soluzione: si assegni agli oggetti un intero in modo univoco
all’interno del sistema
 Svantaggi: difficile gestire un controllo degli accessi: ad
esempio un utente puo’ cercare di ottenere dal processo 123 il
servizio 456
 Possibile soluzione: usare un sistema a capability, cioe’ il nome
dell’ oggetto contiene i diritti d’accesso all’oggetto stesso. Il
possesso del nome significa il possesso del diritto di accesso allo
stesso.
 Problema: come impedire al possessore di cambiare i suoi
diritti?
IPC in ambiente distribuito:
naming



Se si usa un sistema a capability, come e’ possibile impedire al
possessore di cambiare i suoi diritti?
Con tecniche di crittografia, ad esempio (Accent e Mach kernel):
Il servizio di gestione degli oggetti dispone di una funzione di
crittografia F tale che:
F(secret, object name, access rights) = check digits



Il valore secret viene generato all’atto della creazione dell’oggetto e
viene memorizzato con l’oggettto stesso.
La capability per l’oggetto e’ dato dal valore dei check digits
Quando l’utente presenta la capability, si ricalcola il valore della
funzione F ; se i check digits non corrispondono si nega l’accesso
IPC in ambiente distribuito:
locating
In un sistema fortemente connesso il SO (kernel) conosce lo
spazio degli indirizzi e gli indirizzi delle porte dei processi. In
un sistema distribuito ci sono varie possibilita’:
 1. Ogni kernel mantiene:
 le informazioni di tutti gli oggetti locali che possono essere
richiesti da altri nodi;
 una tabella di tutte le chiamate remote che possono essere
invocate da processi locali;
 la tabella potrebbe essere troppo grande
 il naming degli oggetti potrebbe essere inconsistente
 gli indirizzi potrebbero essere non piu’ validi
IPC in ambiente distribuito:
locating
 2. Ogni kernel mantiene:
 le informazioni di tutti gli oggetti locali che possono essere
richiesti da altri nodi;
 quando un processo locale richiede un oggetto remoto,
localizza l’oggetto interagendo con gli altri kernel
chiedendo chi e’ il kernel proprietario, mantiene in cache
alcune di queste informazioni. (Questo approccio e’ usato da
Amoeba e SUN RPC)
 i valori in cache potrebbero diventare non piu’ validi, per cui
sono usati solo come hints
IPC in ambiente distribuito:
locating
 3. Ogni kernel mantiene:
 le informazioni di tutti gli oggetti locali che possono essere
richiesti da altri nodi;
 quando un processo locale richiede un oggetto remoto, invia
un messaggio a tutti nodi che sono strutturati in una
configurazione ad anello logico; il kernel proprietario
cattura il messaggio e lo invvia a destinazione. (e’ un
approccio vecchio)
 non e’ adatto a reti di grandi dimensioni.
IPC in ambiente distribuito:
locating
 4. Su ogni nodo un processo user mantiene:
 le informazioni di tutti gli oggetti locali che possono essere
richiesti da altri nodi;
 questi processi user interagiscono tra loro per localizzare
gli oggetti richiesti; si configurano in situazione di server
per i processi del nodo che desiderano effettuare
comunicazioni
remote. (Accent e Mach usano questo
approccio).
IPC in ambiente distribuito:
locating
 5. Il sistema dispone di un name service:
 quando un servizio e’ creato invia il suo nome, il suo indirizzo
e ogni altra informazione necessaria al name service.
 Quando un cliente deve avere un servizio, richiede le
informazioni necessarie per la comunicazione al name server.
Name Server
Client
Server