IPC in ambiente distribuito Caratteristiche dei sistemi distribuiti : concorrenteesecuzione...
-
Upload
fiorella-bellucci -
Category
Documents
-
view
228 -
download
0
Transcript of IPC in ambiente distribuito Caratteristiche dei sistemi distribuiti : concorrenteesecuzione...
IPC in ambiente distribuitoIPC in ambiente distribuito
Caratteristiche dei sistemi distribuiti:
• esecuzione concorrenteconcorrente • mancanza di nozione di tempo globaletempo globale• ritardoritardo nella comunicazione• difficolta’ di avere una nozione di stato stato
consistenteconsistente• possibilita’ di failure di un componentefailure di un componente
IPC in ambiente distribuitoIPC in ambiente distribuito
Problemi di base nei sistemi distribuiti: dove localizzare gli oggetti: locatinglocating come gestire lo spazio dei nomi: namingnaming
Due modelli per IPC distribuito: modello a oggetti oggetti (Accent, Mach) modello client/serverclient/server (Amoeba)
Due approcci per sistemi di architetture a rete: sistemi di rete: la rete non e’ trasparente alle di rete: la rete non e’ trasparente alle
applicazioniapplicazioni sistemi distribuiti: la rete e’ trasparente alle distribuiti: la rete e’ trasparente alle
applicazioniapplicazioni
IPC in ambiente distribuito: IPC in ambiente distribuito: scambio di messaggiscambio 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 retecomunicazione di rete.• il livello IPC deve fornire anche la funzione di
namingnaming e di locationlocation:• 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: IPC in ambiente distribuito: scambio di messaggiscambio di messaggi
Scambio di messaggi asincrono:
Comunicazione di reteComunicazione di rete
Funzione di naming e di location
WAIT SEND
Livello IPC
Process A
SEND (pid, mess)
Comunicazione di reteComunicazione di rete
WAIT SEND
Funzione di naming e di location
Livello IPC
Process B
WAIT (send, add)
IPC in ambiente distribuito: IPC in ambiente distribuito: scambio di messaggiscambio di messaggi
Cammini reali e virtuali di scambio di messaggio
Process A (Nodo 1)
SEND
IPC Level
Network communication
Process B (Nodo 2)
WAIT
IPC Level
Network Communication
IPC in ambiente distribuito: IPC in ambiente distribuito: scambio di messaggiscambio di messaggi
Per realizzare lo scambio di messaggi in modo trasparentetrasparente ci sono due approcci: il kernel determina se il processo e’ o meno
locale e nel caso sia remotoremoto fornisce il suo indirizzo (location functionlocation 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 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: IPC in ambiente distribuito: scambio di messaggiscambio di messaggi
NetServer Process
Process A (Nodo 1)
SEND (B, mess)
IPC Level
scopre che B non e’ locale
Network Communication Software
NetServer process
WAIT (any)
Call Network Communication
IPC in ambiente distribuito: RPCIPC in ambiente distribuito: RPC
Un’ alternativa ai messaggi sincroni e asincroni e’ il paradigma RPCparadigma RPC, ampiamente usato nelle architetture di rete.
Un sistema RPC consiste di:• un protocollo di comunicazioneprotocollo di comunicazione costruito
sul livello di trasporto (ARPA UDP/IP)• routine per assemblare i datiroutine per assemblare i dati da passare al
protocollo• un meccanismo per legare i nomimeccanismo per legare i nomi delle
procedure remote agli indirizzi di rete
IPC in ambiente distribuito: RPCIPC in ambiente distribuito: RPCUn sistema RPC
Calling System (client) Called System (server)
Caller
call
RPC service
return
Lower level
protocol
Lower level
protocol
RPCservice
return
Network
A
E
B
C
D
call
Called
procedureA
IPC in ambiente distribuito: RPCIPC 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
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
A
B
E
D
IPC in ambiente distribuito: RPC IPC in ambiente distribuito: RPC con malfunzionamentocon malfunzionamento
A causa di malfunzionamentimalfunzionamenti o congestione nella retecongestione 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’ volteritentare 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.EXACTLY ONCE RPC Semantics.
Alcuni sistemi RPC danno all’utente la scelta tra la semantica Alcuni sistemi RPC danno all’utente la scelta tra la semantica EXACTLY ONCEEXACTLY ONCE e la e la AT MOST ONCE RPC SemanticsAT MOST ONCE RPC Semantics che che significa che quando scade il timer, il controllo torna significa che quando scade il timer, il controllo torna all’applicativo, che decide se vuole o meno ritentare la all’applicativo, che decide se vuole o meno ritentare la comunicazione.comunicazione.
IPC in ambiente distribuito: RPC IPC in ambiente distribuito: RPC con crash e restartcon crash e restartFailure dalla parte del cliente
Il cliente fallisce dopo aver inviato una richiesta. La chiamata remota prosegue (orfana)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 (checkpointcheckpoint e rollback facilitiesrollback facilities)
IPC in ambiente distribuito: RPC IPC in ambiente distribuito: RPC con crash e restartcon 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 IPC in ambiente distribuito: RPC e i livelli ISOe i livelli ISO
RPC in relazione al modello ISO/OSIRPC in relazione al modello ISO/OSI
Livello Applicazione
Livello Presentazione
Livello Sessione
Livello Trasporto
Livello Rete
Livello Datalink
Livello Applicazione
Livello Presentazione
Livello Sessione
Livello Trasporto
Livello Rete
Livello Datalink Es.. Ethernet protocol
Es. IP
Es. UDP
Gestione timer e primitive sincronizzazione
Rapprresentazione dati
Invocazione dal linguaggioProtocollo RPC
IPC in ambiente distribuito: IPC in ambiente distribuito: integrazione di RPC con i linguaggiintegrazione di RPC con i linguaggi
Trasparenza della distribuzione Approccio non trasparenteApproccio non trasparente: l’applicazioneapplicazione 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 trasparenteApproccio trasparente: e’ il compilatorecompilatore (o un preprocessore) che deve scoprire quali procedure sono locali e quali non locali. E’ necessario avere un servizio di namingnaming che elenca le procedure non locali. Ad ogni chiamata di procedura remota viene creata una stubstub, cui viene indirizzata localmente la chiamata.
IPC in ambiente distribuito: IPC in ambiente distribuito: integrazione di RPC con i linguaggiintegrazione di RPC con i linguaggi
Implementazione di RPC trasparente
Call RPROC A (arg)
Process level
ClientSTUB for A
RPC implementation level
Lower level ofcommunicationsoftware
RPROC A
Process level
ServerSTUB for A
RPC implementation level
Lower leve of communication softwarel
network
Client System Server System
IPC in ambiente distribuito: IPC in ambiente distribuito: integrazione di RPC con i linguaggiintegrazione di RPC con i linguaggi
Approccio trasparente. Lo STUB si occupa di:
controllare l’ assemblaggio degli argomenti invocare il protocollo di comunicazione
Att!!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: IPC in ambiente distribuito: Client/Server vs OggettiClient/Server vs Oggetti
Il modello client/serverclient/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 oggetto gli oggetti hanno un nome e una locazione in un contesto globalecontesto globale e le operazioni su di essi sono eseguite dagli eseguite dagli utentiutenti direttamente piuttosto che tramite il server.
Nell’ approccio a oggetto oggetto i nomi degli oggetti hanno un significato globale e quindi possono essere passati per riferimentoper riferimento.
IPC in ambiente distribuito: IPC in ambiente distribuito: critica di RPCcritica di RPC
Scelta implementativa: numero massimo di RPC apertenumero 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’ sufficienteRPC e’ sufficiente a rispondere a tutte le necessita’ del sistema? Si potrebbero affiancare possibilita’ diverse: primitive di SENDSEND senza necessita’ di acknowledgment RPC asincronoRPC asincrono (versione di RPC in cui il cliente puo’
continuare la sua attivita’ e prelevare la risposta piu’ tardi
stream protocolstream protocol (connessione source-destination) per grandi quantita’ di dati (video e voce)
IPC in ambiente distribuito: IPC in ambiente distribuito: namingnaming
In un sistema fortemente connesso il SO (kernel) conosceconosce il nomenome di tutti i processi, il loro spazio degli indirizzispazio degli indirizzi e gli indirizzi delle loro eventuali porteporte.
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: IPC in ambiente distribuito: namingnaming
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 locazioneI nomi devono essere indipendenti dalla locazione
IPC in ambiente distribuito: IPC in ambiente distribuito: namingnaming
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 capabilitycapability, 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: IPC in ambiente distribuito: namingnaming
Se si usa un sistema a capabilitycapability, come e’ possibile impedire al possessore di cambiare i suoi diritti?
Con tecniche di crittografiacrittografia, ad esempio (Accent e Mach kernel): Il servizio di gestione degli oggetti dispone di una funzione di
crittografiacrittografia FF tale che:
F(F(secretsecret, object name, access rights) = check digits, object name, access rights) = check digits
Il valore secretsecret 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 digitscheck digits Quando l’utente presenta la capability, si ricalcola il valore della
funzione FF ; se i check digitscheck digits non corrispondono si nega l’accesso
IPC in ambiente distribuito: IPC in ambiente distribuito: locatinglocating
In un sistema fortemente connesso il SO (kernel) conosceconosce lo spazio degli indirizzispazio degli indirizzi e gli indirizzi delle porteporte dei processi. In un sistema distribuito ci sono varie possibilita’:
1. Ogni kernel mantiene: le informazioni di tutti gli oggetti localitutti gli oggetti locali che possono
essere richiesti da altri nodi; una tabella di tutte le chiamate remoteuna tabella di tutte le chiamate remote che
possono essere invocate da processi locali;
la tabella potrebbe essere troppo grandetroppo grande il naming degli oggetti potrebbe essere inconsistenteinconsistente gli indirizzi potrebbero essere non piu’ validinon piu’ validi
IPC in ambiente distribuito: IPC in ambiente distribuito: locatinglocating
2. Ogni kernel mantiene: le informazioni di tutti gli oggetti localitutti 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 kernelinteragendo con gli altri kernel chiedendo chi e’ il kernel proprietario, mantiene in cachecache alcune di queste informazioni. (Questo approccio e’ usato da Amoeba e SUN RPC)
i valori in cache potrebbero diventare non piu’ validinon piu’ validi, per cui sono usati solo come hintshints
IPC in ambiente distribuito: IPC in ambiente distribuito: locatinglocating
3. Ogni kernel mantiene: le informazioni di tutti gli oggetti localitutti 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; 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: IPC in ambiente distribuito: locatinglocating
4. Su ogni nodo un processo userprocesso user mantiene: le informazioni di tutti gli oggetti localitutti 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 server per i processi del nodo che desiderano effettuare comunicazioni remote. (Accent e Mach usano questo approccio).
IPC in ambiente distribuito: IPC in ambiente distribuito: locatinglocating
5. Il sistema dispone di un name servicename 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 ServerName Server
ServerServerClientClient