IPC in ambiente distribuito  Caratteristiche dei sistemi distribuiti : concorrenteesecuzione concorrente tempo globalemancanza di nozione di tempo globale ritardoritardo nella comunicazione stato consistentedifficolta’ di avere una nozione di stato consistente failure di un componentepossibilita’ di failure di un componente

IPC in ambiente distribuito  Problemi di base nei sistemi distribuiti: locating  dove localizzare gli oggetti: locating naming  come gestire lo spazio dei nomi: naming  Due modelli per IPC distribuito: oggetti  modello a oggetti (Accent, Mach) client/server  modello client/server (Amoeba)  Due approcci per sistemi di architetture a rete: di rete: la rete non e’ trasparente alle applicazioni  sistemi di rete: la rete non e’ trasparente alle applicazioni distribuiti: la rete 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’: comunicazione di reteil livello IPC e’ costruito sul livello inferiore della comunicazione di rete. naminglocationil 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: Comunicazione di rete Funzione di naming e di location WAITSEND Livello IPC Process A SEND (pid, mess) Comunicazione di rete WAITSEND Funzione di naming e di location Livello IPC Process B WAIT (send, add)

IPC in ambiente distribuito: scambio 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: scambio di messaggi trasparente Per realizzare lo scambio di messaggi in modo trasparente ci sono due approcci: remoto location function  il kernel determina se il processo e’ o meno locale e nel caso sia remoto fornisce il suo indirizzo (location function ) NetServer  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) 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: scambio di messaggi Come nel caso centralizzato, lo scambio di messaggi puo’ essere: bloccante  Sincrono (bloccante) non bloccante  Asincrono (non bloccante): piu’ difficile da programmare a causa della lentezza delle comunicazioni; spesso per superare questi problemi si riscorre ad una FORK Process FORK child PadreFiglio call remote op. JOIN Comunicazione virtuale

IPC in ambiente distribuito: RPC paradigma RPC  Un’ alternativa ai messaggi sincroni e asincroni e’ il paradigma RPC, ampiamente usato nelle architetture di rete.  Un sistema RPC consiste di: protocollo di comunicazioneun protocollo di comunicazione costruito sul livello di trasporto (ARPA UDP/IP) routine per assemblare i datiroutine per assemblare i dati da passare al protocollo meccanismo per legare i nomiun meccanismo per legare i nomi delle procedure remote agli indirizzi di rete

IPC in ambiente distribuito: RPC Un sistema RPC Calling System (client)Called System (server) Caller call RPC service return Lower level protocol Lower level protocol RPC service return Network A E B C D call Called procedure A

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  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 Un sistema RPC con failure del nodo cliente Calling System (client)Called System (server) Caller call RPC service return Lower level protocol Lower level protocol RPC service return Network A E B C D call Called procedure

IPC in ambiente distribuito: RPC Un sistema RPC con failure del nodo server Calling System (client)Called System (server) Caller call RPC service return Lower level protocol Lower level protocol RPC service * return Network A E B C D call Called procedure * *

IPC in ambiente distribuito: RPC con malfunzionamento malfunzionamenticongestione nella rete  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. ritentare piu’ volte EXACTLY ONCE RPC Semantics.  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. orfana)  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 checkpointrollback facilities  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: un esempio: CCLU RPC zIl sistema CCLU RPC offre una scelta per le chiamate remote; per default si sceglie l’alternativa MAYBE: t: a_type := call a_remote_proc ( ) zelously  Volendo scegliere l’alternativa EXACTLY ONCE si usa la parola chiave zelously : call logger (‘kernel running low on heap’)zelously timeout  La parola chiave timeout rappresenta una durata in millisecondi, applicata ad una chiamata MAYBE, indica quanto si puo’ aspettare, applicata ad una chiamata EXACTLY ONCE indica l’intervallo tra due tentativi successivi: begin : t: a_type := call a_remote_proc ( ) c 2000 end except when problem (p:problem)..% exception signalled by the remote procedure when hard_error (why:int).. % not worth retrying when soft_error (why:int)  end

IPC in ambiente distribuito: RPC e i livelli ISO RPC 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 linguaggio Protocollo RPC

IPC in ambiente distribuito: integrazione di RPC con i linguaggi  Trasparenza della distribuzione  Approccio non trasparenteapplicazione  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 trasparentecompilatore naming stub  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) Process level Client STUB for A RPC implementation level Lower level of communication software RPROC A Process level Server STUB for A RPC implementation level Lower leve of communication softwarel network Client SystemServer System

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!!  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: integrazione di RPC con i linguaggi Approccio Trasparente: gestione degli argomenti Stack x y Data Object in Heap Local call a-obj:a-type:= local(arg) Remote call a-obj:a-type:=call rem-proc(arg) Argomenti per la chiamata di procedura header x y Argomenti preparati da una procedura di STUB

IPC in ambiente distribuito: integrazione di RPC con i linguaggi Passaggio Passaggio degli argomenti in una RPC by copy  In una comunicazione RPC il passaggio degli argomenti (data object) avviene “by copy”: se la procedura remota cambia l’oggetto, tale cambbio non e’ visto dal processo locale e viceversa. grande oggetto  Se l’argomento di una procedura remota fosse solo una parte di un grande oggetto, come si puo’ risparmiare sulla copia? diverse rappresentazioni interne  Possono esserci diverse rappresentazioni interne di dati tra il nodo server e il nodo client

IPC in ambiente distribuito: Client/Server vs Oggetti client/server  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. oggetto contesto globale eseguite dagli utenti  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. oggetto per riferimento  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  numero massimo di RPC aperte in un certo istante da parte di threads di uno stesso processo.  Scelta a livello di progetto di sistema: RPC e’ sufficiente  il paradigma RPC e’ sufficiente a rispondere a tutte le necessita’ del sistema? Si potrebbero affiancare possibilita’ diverse: SEND  primitive di SEND senza necessita’ di acknowledgment  RPC asincrono  RPC asincrono (versione di RPC in cui il cliente puo’ continuare la sua attivita’ e prelevare la risposta piu’ tardi  stream protocol  stream protocol (connessione source-destination) per grandi quantita’ di dati (video e voce)

IPC in ambiente distribuito: naming conosce nomespazio degli indirizzi porte  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:   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 capability  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 capability  Se si usa un sistema a capability, come e’ possibile impedire al possessore di cambiare i suoi diritti? crittografia  Con tecniche di crittografia, ad esempio (Accent e Mach kernel): crittografiaF  Il servizio di gestione degli oggetti dispone di una funzione di crittografia F tale che : F(secret, object name, access rights) = check digits secret  Il valore secret viene generato all’atto della creazione dell’oggetto e viene memorizzato con l’oggettto stesso. check digits  La capability per l’oggetto e’ dato dal valore dei check digits F 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 conosce spazio degli indirizziporte 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: tutti gli oggetti locali  le informazioni di tutti gli oggetti locali che possono essere richiesti da altri nodi;  una tabella di tutte le chiamate remote  una tabella di tutte le chiamate remote che possono essere invocate da processi locali; troppo grande  la tabella potrebbe essere troppo grande inconsistente  il naming degli oggetti potrebbe essere inconsistente non piu’ validi  gli indirizzi potrebbero essere non piu’ validi

IPC in ambiente distribuito: locating  2. Ogni kernel mantiene: tutti gli oggetti locali  le informazioni di tutti gli oggetti locali che possono essere richiesti da altri nodi; interagendo con gli altri kernel cache  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) non piu’ validi hints  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: tutti gli oggetti locali  le informazioni di tutti gli oggetti locali che possono essere richiesti da altri nodi; anello logico;  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 processo user  4. Su ogni nodo un processo user mantiene: tutti gli oggetti locali  le informazioni di tutti gli oggetti locali che possono essere richiesti da altri nodi; server  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 name service  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 Server Client