6. Strumenti per l IPC : dalle socket a RPC/RMI

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

2 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. Esempio di comunicazione connection-oriented usando le socket CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti -

3 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: l 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

4 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

5 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 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 -

6 Le famiglie di Socket Le famiglie di SOCKET Ø 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 Ogni famiglia di socket: riunisce le socket che utilizzano gli stessi protocolli (Protocol Family) sottostanti, supporta un sottoinsieme di stili di comunicazione, possiede un proprio formato di indirizzamento (Address Family) CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti -

7 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 -

8 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 Applicazioni Socket TCP Socket UDP Porte TCP Porte UDP TCP UDP IP Sockets bound to ports Host Descriptor reference CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti -

9 Programmazione socket Per consentire al client di 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 dal 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. Durante l handshake a tre vie il TCP server crea un nuova socket (di connessione) dedicata a quel particolare client CdL in Informatica- Magistrale Università di Bari Sistemi Distribuiti -

10 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 2000

11 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

12 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 2000

13 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 -

14 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 Università di Bari Informatica magistrale Corso di sistemi distribuiti

15 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. Università di Bari Informatica magistrale Corso di sistemi distribuiti

16 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)

17 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.

18 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 Università di Bari Informatica magistrale Corso di sistemi distribuiti

19 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.

20 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. Università di Bari Informatica magistrale Corso di sistemi distribuiti

21 Procedura Chiamante Procedure call e RPC Chiamata a procedura locale argomenti risultato Procedura Chiamata La differenza fra una call locale ed una remota consiste nello spazio di indirizzi su cui le procedure operano. argomenti messaggio richiesta Chiamata a procedura remota Client Processo Chiamante risultati Client Stub risultati Server Processo Chiamato Server Stub argomenti Il processo client effettua una call locale messaggio messaggio risposta messaggio allo stub del client ; lo stub la intercetta risposta richiesta insieme ai suoi argomenti, lo impacchetta RETE e genera un trap al kernel del client con il messaggio di richiesta. Questo viene inviato sulla rete dal kernel del client utilizzando un protocollo di trasmissione (TCP, UDP) e raggiunge 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.

22 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 occupano di risolvere i 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). Università di Bari Informatica magistrale Corso di sistemi distribuiti

23 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)

24 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 Università di Bari Informatica magistrale Corso di sistemi distribuiti

25 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

26 Higher level RPC Higher level RPC <> Lower level RPC. In Higher level RPC la specifica dei tipi di dato trasmessi 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, le versioni corrispondenti ed i filtri di codifica e decodifica (XDR). Ø Il portmapper assegna una porta al programma server e invia informazioni ai client circa gli indirizzi assegnati al programma server. Ø Il server con il comando Svc_run( ), si mette in ascolto sulla socket e aspetta le richieste del client. Ø Il client richiama 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.

27 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. Ø Si edita un file nomefile.x in RPCL (RPC Language). L RPCL fornisce le primitive per la definizione dei dati e delle procedure delle RPC. Nel file nomefile.x 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. Ø Gli stub vengono generati automaticamente dal compilatore di protocollo con il comando RPCGEN nomefile.x. Università di Bari Informatica magistrale Corso di sistemi distribuiti

28 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

29 Il marshalling dei dati 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. 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.

30 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; */ CLIENT *cl=null; /* variabile che contiene static l'handle LINEA per la *result=null; 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]));...

31 RPC sincrono ed asincrono 2-12 a) Interconnessione tra client e server nell RPC tradizionale b) L interazione mediante un RPC asincrono Università di Bari Informatica magistrale Corso di sistemi distribuiti

32 Dalla chiamata a procedura alla Ad esempio RMI invocazione di metodi (O-O) 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.

33 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);

34 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

35 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.

36 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). Università di Bari Informatica magistrale Corso di sistemi distribuiti

37 Architettura generale di RMI 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. Remote Machine bind RMI Server Registry skeleton return call lookup stub RMI Client Local Machine Università di Bari Informatica magistrale Corso di sistemi distribuiti

38 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.

39 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. Università di Bari Informatica magistrale Corso di sistemi distribuiti

40 Passaggio di parametri ü Qualsiasi classe, i cui oggetti devono essere trasmessi con una connessione RMI, deve essere dichiarata come tale indicando che deve implementare l'interfaccia java.io.serializable. ü Ogni parametro passato o ritornato da un metodo remoto deve essere o un oggetto di una classe primitiva Java, o un tipo di dato primitivo oppure un oggetto che implementa l'interfaccia java.io.serializable. ü Un client richiede al server un riferimento ad un oggetto usando lo stub sul lato client. Il server ottiene la richiesta dallo skeleton sul lato server. ü Tra i due c'è il remote reference layer che negozia le richieste convertendo gli oggetti in un formato trasmissibile attraverso la rete. Questa conversione è chiamata marshalling. ü Se i dati da trasmettere non sono né primitivi né serializzabili, lo stub lancerà un'eccezione MarshalException. Percorso dei parametri: Serializzati dalla Virtual Machine Inviati sotto forma di stream al server Deserializzati del server che li utilizza all interno del corpo del metodo invocato Il risultato segue il percorso inverso fino ad arrivare al client

41 La serializzazione Il meccanismo alla base utilizzato da RMI per la trasmissione dei dati fra client e server è quello della serializzazione che permette il flusso di dati complessi all interno di stream (può venir usata indipendentemente da applicazioni RMI). La serializzazione consiste nella trasformazione automatica di oggetti e strutture in sequenze di byte manipolabili coi vari stream del package java.io Gli stream sono associabili sia a socket che a file ad es: Record record = new Record() ObjectOutputStream oos = new ObjectOutputStream(myos) oos.writeobject(record);

42 La serializzazione (2) Un oggetto è serializzabile se implementa l interfaccia Serializable Si possono serializzare oggetti con struttura e complessità arbitraria, senza particolari differenze, a patto che l oggetto sia serializzabile (implementi cioè l interfaccia Serializable) Ad es: public class Record implements Serializable{ private String Nome; public Record(String Nome){ this.nome = Nome } } La serializzazione è ricorsiva ( un oggetto serializzabile deve contenere oggetti serializzabili) La maggior parte delle classi del JDK è serializzabile (eccetto alcune che adottano strutture dati binarie dipendenti dalla piattaforma)

43 Gli strati RRL e TL Si occupano della gestione a basso livello ( all interno dell architettura RMI) della comunicazione. Il Remote Reference Layer (RRL) ha il compito di instaurare un connessione virtuale fra il client e il server ( esegue operazioni di codifica e decodifica dei dati). RRL adotta un protocollo generico e indipendente dal tipo di stub o skeleton utilizzato. Il Transport Layer esegue la connessione vera e propria tra le macchine utilizzando le specifiche standard di networking di Java, e quindi le socket con il protocollo TCP/IP. Il TL è quindi responsabile del controllo dello stato delle vari connessioni. Il TL si incarica di localizzare il server RMI relativo all oggetto remoto richiesto ed segue la connessione per mezzo di una socket. Università di Bari Informatica magistrale Corso di sistemi distribuiti

44 SVILUPPARE UN APPLICAZIONE RMI Così come altre applicazioni scritte in Java, un applicazione distribuita costruita con RMI è fatta sostanzialmente di interfacce e classi. Le interfacce dichiarano i metodi. Le classi implementano i metodi dichiarati nelle interfacce più altri metodi, se necessario. In una applicazione distribuita certe classi (implementazioni di metodi) possono non risiedere su una particolare macchina virtuale ma possono essere disponibili in remoto su altre macchine virtuali (oggetti remoti). Un oggetto diventa remoto implementando una interfaccia remota con le seguenti caratteristiche: Una interfaccia remota ESTENDE (extends) l interfaccia java.rmi.remote. Ciascun metodo dell interfaccia DICHIARA (declares) java.rmi.remoteexception nella sua clausola throws, oltre alle altre eccezioni specifiche della particolare applicazione.

45 SVILUPPARE UN APPLICAZIONE RMI Le classi e i metodi sono contenuti nei package java.rmi e java.rmi.server. Ø Disegnare ed implementare le componenti dell applicazione distribuita. Definire l interfaccia remota ( i metodi che possono essere invocati in remoto dai client ), con i tipi di oggetti che potranno essere usati (come i parametri e i valori di ritorno di questi metodi ) Implementare gli oggetti remoti che devono implementare una o più interfacce remote. Si definisce oggetto remoto un oggetto che implementi l interfaccia Remote i cui metodi possono essere eseguiti da un applicazione client posta su un altra macchina virtuale. Implementare il programma client. Ø Compilare i sorgenti con Javac (ed rmic con piattaforme Java antecedenti alla 5.0) e generare lo stub e lo skeleton. Ø Rendere accessibili in rete le classi (start dell RMI registry). Ø Start dell applicazione server e run del client. Università di Bari Informatica magistrale Corso di sistemi distribuiti