CdL MAGISTRALE in INFORMATICA A.A corso di Sistemi Distribuiti. Le Socket

Transcript

1 CdL MAGISTRALE in INFORMATICA A.A corso di Sistemi Distribuiti 6. Strumenti per l IPC : dalle socket a RPC/RMI Prof. S.Pizzutilo Le Socket Una socket è una astrazione software rappresentante un punto terminale di interfacciamento per la comunicazione in rete. 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. Esempio di comunicazione connection-oriented usando le socket CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti - 1

2 Relazione tra protocolli, applicazioni e API socket 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. Applicazione Socket API Implementazione dei protocolli (S.O.) Applicazione Socket API TCP TCP IP HOST canale IP canale Es: ethernet Router IP HOST 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) kernel Gestore di data link (ethernet) CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti 2

3 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 CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti - Le famiglie di Socket Esistono varie famiglie di socket. Ogni famiglia : riunisce le 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 CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti - 3

4 I tipi di Socket Il tipo di una socket definisce una modalità di comunicazione che una socket usa per inviare dati: q Streaming Socket (SOCK_STREAM): Fornisce una connessione sequenziale, affidabile e full-duplex. Il protocollo TCP supporta questo tipo di socket. q 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 CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti - 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 Applicazioni Socket TCP Applicazioni Socket UDP Porte TCP TCP UDP Porte UDP IP Sockets bound to ports Host Descriptor reference CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti - 4

5 Programmazione socket Il client deve contattare il server Il programma server deve essere in esecuzione come processo di background. Il programma server deve avere una porta (socket) che dia il benvenuto al contatto iniziale stabilito da un processo client in esecuzione. Durante l handshake a tre vie il TCP server crea un nuova socket (di connessione) dedicata a quel particolare client 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. CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti - Esempio 1: Primitive BSD UNIX per gestire la comunicazione mediante socket s = socket (domain, type, protocol) 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) write(s, message, msg_lenght) (C/S) (C/S) (C/S) Stream type amount =recvfrom(s, buffer, sender_addr)(c/s) sendto (s, msg, receiver_addr) (C/S) datagram type CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti - 5

6 Esempio2 : Interazione TCP Client/Server con WSA Le Windows Sockets API (WSA) sono una specifica estensione delle socket BSD UNIX elaborata per l'ambiente operativo Microsoft Windows. STREAM SOCKET 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. Client 1. (Inizializzare una WSA) 2. Creare una Socket 3. Connettersi al server 4. Inviare e ricevere dati 5. Chiudere la connessione BSD Sockets used for datagrams Sending a message Receiving a message s = socket(af_inet, SOCK_DGRAM, 0) s = socket(af_inet, SOCK_DGRAM, 0) bind(s, ClientAddress) sendto(s, "message", ServerAddress) bind(s, ServerAddress) amount = recvfrom(s, buffer, from) ServerAddress and ClientAddress are socket addresses Tratto da: Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 Addison-Wesley Publishers

7 Esempio2 : Interazione UDP Client/Server con WSA DATAGRAM SOCKET 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 Client 1. (Inizializzare una WSA) 2. Creare una Socket 3. Inviare e ricevere dati 4. Chiudere la connessione CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti - BSD Sockets used for streams Requesting a connection Listening and accepting a connection s = socket(af_inet, SOCK_STREAM,0) connect(s, ServerAddress) write(s, "message", length) s = socket(af_inet, SOCK_STREAM,0) bind(s, ServerAddress); listen(s,5); snew = accept(s, ClientAddress); n = read(snew, buffer, amount) ServerAddress and ClientAddress are socket addresses Tratto da : Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 Addison-Wesley Publishers

8 Da message passing a procedure call ü L IPC basato sui messaggi consente due operazioni: Ø Send (messaggio) la dimensione del messaggio può essere fissa o variabile Ø Receive (messaggio) ü Se P e Q vogliono comunicare, hanno bisogno di: q stabilire un canale di comunicazione fra di loro, fisicamente (es. memoria condivisa, bus hardware) logicamente (es. proprietà logiche) q scambiare messaggi per mezzo di send e receive Encoding e decoding dei messaggi Conservazione della semantica dei messaggi tra sistemi disomogenei Nodo A Nodo B buffer messaggio encoding Messaggio codificato I valori dei puntatori perdono il loro significato quando sono trasferiti da uno spazio degli indirizzi di un processo ad un altro. Oggetti diversi di un programma occupano spazio di memoria diverso a seconda delle architetture messaggio decoding Messaggio codificato buffer Tagged representation : nel messaggio vengono codificati il tipo ed il valore degli oggetti Untagged representation : il messaggio contiene solo il valore dell oggetto senza alcuna specifica del tipo. Presuppone che il programma ricevente sappia decodificare i dati ricevuti. 8

9 Istruzioni di chiamata a procedura locale ü ü L istruzione di chiamata ( Call ) è un istruzione di salto, il cui operando è l indirizzo della prima istruzione della procedura, detto entry-point address L istruzione di ritorno ( Return ), al termine della esecuzione della procedura chiamata, è una istruzione di salto alla procedura chiamante, alla istruzione che segue immediatamente la istruzione di call: Necessità di conservare l indirizzo di tale istruzione, detto return address main. call A.. call A Proc A call B... return Proc B... return Il return address può essere conservato in: Registri o locazioni di memoria Difficoltà nel chiamare un altra procedura all interno di quella chiamata (procedure nidificate) Locazione di memoria associata alla procedura L istruzione di return è una istruzione di salto alla locazione di memoria che conserva l indirizzo della istruzione della procedura chiamante È possibile la nidificazione delle procedure Stack È possibile sia la nidificazione delle procedure che la ricorsività (abilità di una procedura a chiamare se stessa) Passaggio dei parametri tra procedure Ø La procedura chiamante può passare alla procedura chiamata dei valori detti parametri (o argomenti o dati ). Ø La procedura chiamata fornisce dei parametri ( o risultati) alla procedura chiamante. La procedura chiamante pone i parametri nello stack, prima di effettuare la chiamata (trasmissione per valore), da dove vengono letti dalla procedura chiamata. La procedura chiamante pone gli indirizzi dei parametri nello stack (trasmissione per indirizzo o referenza), la procedura chiamata legge gli indirizzi per accedere ai valori e modificarli o calcolarne di nuovi. Trasmissione per copia/ripristino : il client pone i parametri nello stack,, il server li legge dallo stack e, dopo il calcolo, pone i risultati nuovamente nello stack, il client legge dallo stack i dati inviati dal server e ricopia i dati in memoria sovrascrivendo i parametri precedentemente trasmessi. 9

10 I protocolli per la comunicazione tra processi remoti Le caratteristiche principali di un DCE (Distributed Computing Environment) sono: p. Un tool di rappresentazione dei dati indipendente dalla macchina (per permettere a macchine diverse di scambiarsi i dati), p. un protocollo per specificare responsabilità a basso livello del client e del server durante la comunicazione, p. un compilatore di protocollo che generi le componenti necessarie alla comunicazione, p. servizi di autenticazione per migliorare la sicurezza, p. servizi di naming di rete, p. servizio di DFS (Distributed File System) per eliminare ridondanza di files. Client Risposta Richiesta Client Richiesta Risposta Richiesta Server Client Risposta RPC (Remote Procedure Call) L'RPC permette la chiamata di procedure esterne che risiedono su diversi spazi di indirizzi in modo simile ad una chiamata locale. u Gli argomenti e i valori di ritorno sono automaticamente impacchettati e inviati dalle procedure locali a quelle esterne, in modo da mantenere la semantica delle chiamate delle procedure remote simile a quella delle chiamate locali. u L'RPC è stato progettato per la creazione di applicazioni distribuite su ambienti eterogenei, quindi l attività di marshalling dei dati è fondamentale : i parametri trasmessi tra le procedure in RPC devono essere impacchettati in un formato canonico indipendente dall'architettura prima di essere passati alle procedure remote. u Una tipica applicazione RPC è costituita da un client ed un server che comunicano tra loro per mezzo dei rispettivi stub che si occupano di convertire i dati dal formato della macchina a quello generale e viceversa. 10

11 RPC (Remote Procedure Call) L RPC opera a livello di sessione del modello ISO-OSI, utilizzando l XDR a livello di presentazione come modo di rappresentazione dei dati. In una chiamata a procedura remota il chiamante (client) e il chiamato (server) interagiscono nel seguente modo: Il client esegue una chiamata ad una funzione disponibile server e si blocca sino a che non ottiene il risultato. Un processo di gestione delle RPC raccoglie i valori dei parametri, forma un messaggio (stub) e lo invia al server remoto. Il kernel del server riceve la richiesta, spacchetta i parametri, invoca la procedura e invia indietro la risposta al client. Procedura Chiamante Procedure call e RPC Chiamata a procedura locale argomenti Procedura Chiamata risultato La differenza fra una call locale ed una remota consiste nello spazio di indirizzi su cui le procedure operano. argomenti messaggio Chiamata a procedura remota risultati risultati argomenti Il processo client effettua una call richiesta messaggio messaggio locale allo stub del client ; lo stub la risposta messaggio risposta richiesta intercetta insieme ai suoi argomenti, RETE lo impacchetta e genera un trap al kernel del client con il messaggio di richiesta. Questo viene inviato sulla rete dal kernel della macchina client utilizzando un protocollo di trasmissione (TCP,UDP,...), raggiungendo così lo stub del server. Il kernel della macchina server lo riceve, lo spacchetta e lo trasforma in una call locale al processo server. I risultati vengono inseriti nel messaggio di risposta, che lo stub del server invia sulla rete allo stub del client con lo stesso meccanismo. Client Processo Chiamante Client Stub Server Processo Chiamato Server Stub 11

12 Marshalling dei dati Lo stub contiene l interfaccia di comunicazione e i dati. Gli stub possono essere generati automaticamente da un compilatore di protocollo e sono trasparenti all utente. Il client stub ed il server stub si occuperanno di: Ø Risolvere problemi riguardanti la diversa rappresentazione dei dati (big endian, little endian), implementando meccanismi di marshalling in un formato canonico (XDR). Ø Il passaggio dei parametri puntatore: al server viene passato il dato e non il puntatore, questo sarà memorizzato in una locazione del server e creato un puntatore alla locazione (tecnica del copia / ripristino). Standard di Network Computing OpenNetworkComputing RPC (Sun, AT&T, Novell, Netwise) Application Programs NFS NIS REX NLM RPC Transport Level Interface XDR Socket Low level network protocols (TCP, UDP, OSI, SPX/IPX) OpenSoftwareFoundation NCS/NCA RPC (HP, Apollo, IBM, DEC, Microsoft) Application Programs Location Broker Global Local RPC NDR Low level network protocols (TCP, UDP, OSI, SPX/IPX) 12

13 ONC-RPC binding ü Tutto il meccanismo avviene dopo che fra il client ed il server è stata creata una connessione (binding), che viene realizzata, durante l esecuzione del client, da un istruzione della RPC che crea un handle (un puntatore al CLIENT). ü La clnt_create() restituisce un puntatore ad un indirizzo che contiene la posizione del server. Questa viene individuata da un servizio del sistema server (il portmapper) che conserva il numero di porta di connessione su cui il processo server si è registrato ed è in ascolto (1). ü Una volta che il client ottiene il numero di porta del server (2) inviando anche l indirizzo dove ricevere le risposte, apre una connessione, che resta aperta (3) fino a quando non viene invocata la funzione clnt_destroy() che la chiude. Client Programma client Server Portmapper porte di com. Programma Server Il binding (cont.) RETE ü Fino a quando la connessione resta aperta, il client può invocare tutti i servizi del server (send). ü Durante una richiesta il client resta in attesa della risposta (blocked). ü Il processo server invece è sempre in attesa (in receive) e si attiva solo quando riceve una richiesta di servizio (messaggio) sulla porta di ascolto. Allora invoca la procedura richiesta e, dopo averla eseguita, assembla la risposta. Quindi la invia (send) al client, che a questo punto può riprendere la sua esecuzione, e si rimette in receive. Macchina client programma client attesa... Call rpc() con richiesta return() con risposta Macchina server demone del servizio in ascolto invoca il servizio chiamata alla procedura Return() risultato esecuzione della proc. richiesta esaurita costruzione della risposta demone del servizio in ascolto 13

14 Higher level RPC Esistono due modi per utilizzare il meccanismo RPC: ad alto livello (Higher level RPC) ed a basso livello (Lower level RPC). Nell' Higher level RPC la specifica dei tipi di dati che si passano e l identificazione della procedura server remota è a carico del programmatore che genera manualmente gli stub (per il server e per il client). Ø Per la specifica dei tipi di dati si definisce un file header che verrà incluso sia nel codice client che nel codice server. Ø Per comunicare al portmapper la registrazione del programma server si usa l'istruzione Register_rpc( ) in cui sono specificate le procedure contenute e le versioni corrispondenti; sono anche specificati i filtri di codifica e decodifica (XDR). In questo modo il portmapper assegna una porta al programma server e invia informazioni ai client circa gli indirizzi assegnati al programma server. Ø Dopo il Register_rpc( ), il server, con il comando Svc_run( ), si mette in ascolto sulla socket e aspetta le richieste del client. Con questa procedura il server verifica l'indirizzo e la versione del client, una volta accettata la sua richiesta. Ø Il client deve solo richiamare una RPC con il comando Callrpc( ). Questo comando contiene il numero di porta dell'host remoto, il numero di programma e di versione settando il canale di comunicazione I/O per l'esecuzione in remoto della procedura richiesta. Lower level RPC Nel Lower level RPC non è invece necessario inserire nel codice server e client i protocolli di trasmissione perché le relative funzioni sono implementate negli stub del server e del client. Ø Gli stub vengono generati automaticamente dal compilatore di protocollo con il comando RPCGEN nomefile.x. Ø Il file nomefile.x si scrive in un linguaggio simile al C, l RPCL (RPC Language) che fornisce le primitive per la definizione dei dati e delle procedure delle RPC. Ø Si definiscono i tipi di dati utilizzati ( se non predefiniti), ed alcune informazioni proprie delle RPC quali il nome del programma, un numero e una versione di programma per i prototipi delle funzioni remote. 14

15 Lower level ONC-RPC Specifiche RPC nomefile.x RPCGEN supporta entrambi i protocolli di trasmissione (TCP e UDP), permette più flessibilità nella stesura del codice client con un piccolo aumento di tempo di esecuzione dovuto ad una maggiore complessità dei programmi generati. Oltre agli stub (nomefile_clnt.c e nomefile_svc.c) viene generato anche un file header (nomefile.h) da far condividere al client e al server e un file contenente i filtri (contenuti in una libreria RPC) per la comunicazione tra i due processi (nomefile_xdr.c). Client stub nomefile_clnt.c Header nomefile.h RPCGEN Filtri XDR nomefile_xdr.c Server stub nomefile_svc.c Compilatore C Compilatore C Compilatore C Nel file nomefile_xdr.c sono specificate le procedure di conversione del formato dei dati, affinchè i processi client e server possano comunicare ( Marshalling dei dati). Questo perché client e server devono comunicare usando una rappresentazione di dati indipendente dalla macchina. Ø La compilazione del client avviene linkando il codice sorgente della procedura client (nomefile_client.c) con lo stub del client ed il filtro XDR e generando così l eseguibile client. Client stub nomefile_clnt.o Linker Programma client nome_client.o Compilatore C Client eseguibile nome_client Filtri XDR nomefile_xdr.o Server stub nomefile_server.o Linker Programma server nome_server.o Compilatore C Ø La compilazione del server avviene linkando il codice sorgente della procedura server (nomefile_server.c) con lo stub del server ed il filtro XDR, generando così l eseguibile server. Programma client nome_client.c Server eseguibile Nome_server Programma server nome_server.c Il marshalling dei dati Il trasferimento dei dati tra i due processi (client e server) richiede la codifica e la decodifica del messaggio stesso. E questa l operazione che viene conosciuta come marshalling dei dati nei sistemi RPC. Nello standard ONC-RPC la codifica e la decodifica sono eseguite tramite dei filtri XDR (External Data Representation), i quali operano delle conversioni di tipo sugli argomenti delle procedure. Nel file nomefile_xdr.c sono contenute le definizioni dei tipi e delle costanti che vengono utilizzati. Tale file è generato sulla base di ciò che è specificato nel file nomefile.x. Tipicamente le operazioni di marshalling sono: 1. acquisizione degli argomenti dal processo client, o dei risultati dal processo server, che formeranno i dati del messaggio da inviare al processo remoto, 2. codifica dei dati del messaggio passati dal mittente, 3. decodifica dei dati del messaggio sulla macchina ricevente. L'ordine e il metodo di rappresentazione usati per i risultati e gli argomenti devono essere conosciuti sia dal client che dal server. Il processo di marshalling deve riflettere le strutture di tutti i tipi di dati usati nel programma oggetto, includere i tipi di primitive, i tipi strutturati ed i tipi definiti dall'utente. Un buon sistema RPC può generare codice marshalling in linea per ogni chiamata remota, in tal modo l'utente è sollevato dallo scrivere le proprie procedure di marshalling. Ma in pratica è difficile realizzare questo metodo di RPC perché così si dovrebbe generare una grande quantità di codice per manipolare tutti i tipi possibili di dati. 15

16 Esempio di applicazione ONC-RPC (realizzato da :Cozzolongo Giovanni e Spina Maria Antonietta) I due processi possono risiedere su macchine separate o essere situate sulla stessa postazione. Questo comunque non inficia sul buon funzionamento del sistema perché all avvio del processo client sarà necessario specificare il nome dell Host su cui è attivo il processo server, e le RPC trattano i due casi allo stesso modo. Al processo server sono affidati tutti i compiti relativi alla elaborazione dei dati; al processo client sono invece affidati i compiti relativi alla interfaccia con l utente. Ricerca.x rpcgen %#define DATABASE "archivio.txt" %#define HELP "help.txt" %#define MAXSTR 130 struct LINEA { string CORRENTE<MAXSTR>; int TROVATO; }; program ANALIZZA{ version ANALIZZAV{ LINEA ANALIZZA_GH (LINEA) =1; int APRIARCHIVIO (LINEA) =2; LINEA LEGGITESTO (LINEA) =3; }=1; }=0x ; Ricerca.h Ricerca_svc.c Ricerca_clnt.c Ricerca_xdr.c Server.c #include <rpc/rpc.h> #include <stdio.h> Client.c #include <stdlib.h> #include <stdio.h> #include <string.h> #include <stdlib.h> #include "ricerca.h" #include <string.h> /* dichiarazioni delle funzioni RPC */ #include <rpc/rpc.h> LINEA *analizza_gh_1(linea *gh); #include "ricerca.h" int *apriarchivio_1(linea *testo); void menu(char *); /* interfaccia utente*/ LINEA *leggitesto_1(linea *testo); void analisi(char *); /* ricerca nell'archivio */ /* procedura locale */ void elenca (char *,char *); /* visualizza l'archivio int */ ricerca(linea *gh); void chiamata (char *); /* crea l'handle e verifica FILE la presenza *fp=null; del server */ void stampa(char *,char); /* stampa i messaggi di FILE output *hp=null; */ static LINEA *result=null; CLIENT *cl=null; /* variabile che contiene l'handle per la comunicazione RPC */ /* MAIN *****/ main (argc,argv) int argc; char *argv[]; { char *server; server = (char *)malloc (sizeof (char *)); if (argc!=2) LINEA *tempgh=null; /* definizione di analizza_gh_1 */ LINEA *analizza_gh_1(gh) LINEA *gh; { if (!tempgh) {.. { fprintf(stderr,"sintassi: %s server \ninserire nome del server:\t", argv[0]); scanf("%s",server); } else (strcpy(server,argv[1]));... RPC sincrono ed asincrono 2-12 a) Interconnessione tra client e server nell RPC tradizionale b) L interazione mediante un RPC asincrono 16

17 Dalla chiamata a procedura alla invocazione di metodi (O-O) Ad esempio RMI RMI è il meccanismo fornito da Java per invocare metodi di oggetti distribuiti su macchine virtuali diverse sparse sulla rete. Con l'rmi è possibile passare e ritornare oggetti in modo trasparente durante una chiamata a un metodo oltre che tipi di dati predefiniti.. RMI consente al programmatore di scrivere solo una volta il codice per implementare un oggetto che sarà immediatamente visibile sia al client (tramite la sua interfaccia) che al server (sul quale è implementato).. RMI permette sulle applicazioni distribuite l uso di thread da parte di un server RMI per garantire la gestione ottimale della concorrenza tra oggetti distribuiti. Java Remote Object Invocation (RMI) Java RMI permette di eseguire classi di funzioni remote usando la stessa semantica delle function call locali Local Machine (Client) Remote Machine (Server) SampleServer remoteobject; int s; s = remoteobject.sum(1,2); 1,2 3 public int sum(int a,int b) { return a + b; } System.out.println(s); 17

18 Remote Method Invocation RMI richiede l utilizzo esclusivo di Java come linguaggio di sviluppo e consiste in: un operazione di LOCALIZZAZIONE DI OGGETTI REMOTI mediante meccanismi di REGITRY degli oggetti, Un operazione di COMUNICAZIONE con gli oggetti remoti mediante funzioni di INVOCAZIONE dei metodi appartenenti ad oggetti remoti da parte dei client, Un operazione di CARICAMENTO delle definizioni delle CLASSI degli oggetti remoti: (Dynamic Code Loading) possibilità di scaricare il bytecode di una classe se la classe non è definita nella virtual machine del ricevente, mantenendo la definizione dei tipi e il loro comportamento Perche RMI? L obiettivo è di permettere ad una applicazione in esecuzione su una macchina locale di invocare i metodi di un oggetto in esecuzione su un altro computer. Si definisce client il programma chiamante che ottiene riferimento all oggetto remoto, server il programma che crea gli oggetti remoti. Tali applicazioni sono anche denominate distributed object application. Quali vantaggi? miglioramento delle prestazione complessive semplicità nella gestione delle risorse distribuite incremento della potenza operativa Ad es: suddivisione di una computazione pesante in procedure più piccole, eseguite tutte su macchine diverse diminuendo in tal modo il tempo complessivo di esecuzione Componenti base dell RMI Client (Interfaccia) Server (Implementazione) Stub Skeleton Remote Reference Layer Remote Reference Layer Transport Layer (Connessione TCP/IP) Un client è dotato dell'interfaccia dei metodi disponibili sul server remoto, ma tutta l'implementazione è lasciata sul lato server. Nel programma client i dettagli dell'implementazione dei metodi remoti sono quindi invisibili. Ciò che realmente collega il client e il server in un sistema RMI è una connessione stratificata, trasparente agli sviluppatori, effettuata dal sottosistema RMI delle due macchine virtuali coinvolte. 18

19 Lo Stub e lo Skeleton RMI Client Stub call skeleton RMI Server return Il client invoca un metodo remoto sul proprio stub. Lo stub è responsabile della spedizione del call remoto allo skeleton del server. Lo stub apre una socket con il server, facendo il marshalling (serializzazione) dei parametri ed inviando allo skeleton del server un data stream. Lo skeleton del server contiene un metodo per ricevere i remote call dai client, per deserializzare (unmarshalling) i parametri ed invocare l implementazione dell oggetto remoto (a lui locale). Architettura generale di RMI Remote Machine Il server deve innanzitutto registrarsi (bind ad un registry) Il client cerca il nome del server nel registry per stabilire i riferimenti remoti. Lo Stub serializza i parametri verso lo skeleton sul server localizzato. Lo Skeleton invoca il metodo remoto (locale al server) e serializza il risultato verso il client stub. RMI Server skeleton return call stub RMI Client bind Registry lookup Local Machine 19

20 Architettura di RMI La struttura di un applicazione RMI è organizzata in strati orizzontali sovrapposti Simulazione locale sul client RMI Client Stubs Java Virtual Machine RMI Server Skeleton Oggetto reale eseguito sul server Il primo livello di questa connessione stratificata è rappresentato dagli stub (lato client) e gli skeleton (loto server) ai quali si riferiscono rispettivamente il client e il server senza occuparsi di ulteriori dettagli di più basso livello. Remote Reference Layer Transport Layer Connessione virtuale Connessione fisica Remote Reference Layer Transport Layer A loro volta gli stub e gli skeleton d e m a n d a n o l'esecuzione di ciascuna a t t i v i t à a l l o s t r a t o immediatamente sottostante: il remote reference layer (RRL) che gestisce i riferimenti delle variabili agli oggetti remoti, usando la connessione TCP/IP del Transport layer sottostante. Architettura di RMI Ø Lo strato più alto è costituito da applicazioni (client e server) eseguite dalla Java Virtual Machine. Ø Lo stub e lo skeleton forniscono la rappresentazione dell oggetto remoto: lo stub gestisce la simulazione locale sul client e, agendo come proxy, consente la comunicazione con l oggetto remoto; lo skeleton invece consente l esecuzione dell oggetto remoto sul server. Ø Il client esegue i metodi dell oggetto remoto in modo del tutto analogo alla chiamata locale: ris = OggettoRemoto. nomemetodo (par1, par2,..) senza preoccuparsi dei dettagli della comunicazione. 20