Chiamate a Procedure Remote - Dipartimento di Informaticadisys/RPCAndreaPazienza.pdf · Andrea...

FACOLTA’ DI SCIENZE MATEMATICHE, FISICHE E NATURALI

Corso di Laurea Magistrale in Informatica

Corso di Sistemi Distribuiti Anno Accademico 2012/2013

Relazione sullo sviluppo di

Chiamate a Procedure Remote

a cura di

Andrea Pazienza

1

Andrea Pazienza – RPC [Sistemi Distribuiti]

Indice

1. Le Remote Procedure Calls 2

2. Funzionamento di una invocazione remota 3

2.1 Requisiti per l’implementazione di RPC 3

2.2 Implementazione del supporto 4

3. L’applicazione realizzata 4

3.1 Definizione del servizio remoto e compilazione con RPCGEN 4

3.2 Routine di conversione XDR 6

3.3 Stub del Server 6

3.4 Stub del Client 8

3.5 Sviluppo del programma CLIENT 8

3.6 Sviluppo delle procedure di servizio 10

4. Istruzioni di compilazione 11

2


1. Le Remote Procedure Calls (RPC)

Le RPC sono un paradigma di comunicazione di alto livello utilizzate in un sistema operativo. RPC presuppone l’esistenza di meccanismi di rete di basso livello (ad esempio TCP/IP e UDP/IP), e su di loro si implementa un client logico al sistema server di comunicazione progettato specificatamente per il supporto di applicazioni di rete. Con RPC, il client effettua una chiamata di procedura per inviare un pacchetto dati al server. Quando il pacchetto arriva, il server chiama una routine di invio, esegue qualsiasi servizio richiesto, restituisce la risposta, e la chiamata di procedura ritorna al client. L’RPC permette la chiamata di procedure esterne che risiedono su diversi spazi di indirizzi in modo simile ad una chiamata locale. 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. 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. 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. L’ RPC opera a livello di sessione del modello ISO-OSI, utilizzando l’XDR a livello di presentazione come modo di rappresentazione dei dati.

3


2. Funzionamento di una invocazione remota

Il processo client effettua una call locale allo stub del client; lo stub la intercetta insieme ai suoi argomenti, 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.

2.1 Requisiti per l’implementazione di RPC

Il supporto scambia messaggi per consentire:

identificazione dei messaggi di chiamata e risposta

identificazione unica della procedura remota Il supporto gestisce l’eterogeneità dei dati scambiati:

marshalling/unmarshalling argomenti;

serializzazione argomenti; Il supporto gestisce alcuni errori dovuti alla distribuzione:

implementazione errata;

errori dell'utente;

roll-over (ritorno indietro).

4


Due parti descrittive in linguaggio RPC: 1. definizioni di programmi RPC: specifiche del protocollo RPC per i

servizi offerti, cioè l’identificazione dei servizi ed il tipo dei parametri; 2. definizioni XDR: definizioni dei tipi di dati dei parametri. Presenti solo

se il tipo di dato non è un tipo noto in RPC. Raggruppate in un unico file con estensione .x cioè XDR, che deve solo descrivere il contratto di interazione. 2.2 Implementazione del supporto

Noi vediamo l’implementazione e il supporto RPC di Sun Microsystems: Open Network Computing (ONC). ONC è una suite di prodotti che include: – eXternal Data Representation (XDR): rappresentazione e conversione dati; – Remote Procedure Call GENerator (RPCGEN): generazione del client e server stub; – Portmapper: risoluzione indirizzo del server; – Network File System (NFS): file system distribuito di Sun.

3. L’applicazione realizzata

Si è sviluppato un programma in linguaggio C che calcola delle funzioni di Statistica Descrittiva su un vettore di numeri naturali:

Media;

Varianza;

Deviazione Standard. 3.1 Definizione del servizio remoto e compilazione con RPCGEN

Innanzitutto bisogna dare la definizione del servizio remoto esplicitando le procedure remote, date nel file stat.x: typedef int iarray<>;

program STAT_PROG {

version STAT_VERS {

double CALCOLAMEDIA(iarray) = 1;

double CALCOLAVARIANZA(iarray) = 2;

double CALCOLADEVSTANDARD(double) = 3;

} = 1;

} = 0x20000013;

5


Il Messaggio RPC deve contenere per la identificazione globale:

numero di programma: dove STAT_PROG è il nome che verrà utilizzato per istanziare il codice del client e del server, l’identificatore 0x20000013 è l’identificatore unico del programma usato nella rete. L’utente può utilizzare identificatori che hanno valori compresi da 0x20000000 a 0x3fffffff. Gli identificatori che vanno da 0x0 a 0x1fffffff sono utilizzati da Sun, invece quelli maggiori di 0x3fffffff sono riservati per altri servizi non utente. L’identificatore di programma usato nella rete non identifica univocamente il programma all’interno del portmap, per questo e necessario anche il numero di versione;

numero di versione, con il seguente formato: STAT_VERSION {…} = 1 questo permette la coesistenza di più versioni dello stesso programma. Ad esempio aggiungendo una procedura in un determinato host, basta inserirla nel programma contenuto nel stat.x e aggiornare il numero di versione di tale programma, non occorre fare alcuna modifica sul resto degli host;

numero di procedura nella forma double CALCOLAMEDIA

(iarray) = 1, che descrive in dettaglio quali tipi di dati sono coinvolti e il nome stesso della procedura.

Si noti inoltre che:

ogni definizione di procedura ha un solo parametro di ingresso e un solo parametro d’uscita;

gli identificatori (nomi) usano lettere maiuscole;

ogni procedura è associata ad un numero di procedura unico all’interno di un programma.

La compilazione di stat.x genera per generare il file header, il file per le conversioni XDR e gli stub client e server. La compilazione avviene tramite il compilatore RPCGEN che produce, nel nostro caso, i seguenti file:

stat.h, l’header file

stat_xdr.c, che contiene le routine di conversione XDR;

stat_svc.c, stub del server.

stat_clnt.c, stub del client;

6


3.2 Routine di conversione XDR

Il file stat_xdr.c contiene funzioni di marshalling svolte dal protocollo XDR. Si tratta di procedure built-in di conversione, relative a:

tipi atomici predefiniti;

tipi standard (costruttori riconosciuti). Per ogni informazione da trasmettere si hanno due trasformazioni, una al mittente e una al destinatario, mentre sulla rete viaggia solo il formato XDR. Ogni nodo deve provvedere solamente le proprie funzionalità di trasformazione:

dal formato locale a quello standard;

dal formato standard a quello locale. Le funzioni XDR sono usate anche per la sola trasformazione dei dati (e non associate alla comunicazione). Le funzioni XDR restituiscono valore vero se la conversione ha successo. Possono funzionare anche con tipi definiti dall’utente 3.3 Stub del Server

Il server deve registrare la procedura nella tabella dinamica dei servizi del nodo. Un servizio registrato può essere invocato: al servizio viene associato un identificatore strutturato secondo il protocollo RPC. La registerrpc() viene eseguita dal server che la vuole rendere nota ed invocabile da clienti remoti, questo vuol dire una entry per ogni registrazione. Il processo del programma corrente si mette in attesa indefinita di una richiesta per fornire i servizi. Dopo la registrazione della procedura, il processo che ha eseguito la primitiva registerrpc() deve rimanere in attesa di chiamate. Il server si comporta come un demone mettendosi in attesa di tutte le possibili richieste attraverso la svc_run() che esprime la attesa infinita del server e che non termina. Le procedure registrate con registerrpc() sono compatibili con chiamate realizzate da primitive basate su meccanismi di trasporto UDP senza connessione, ma incompatibili con TCP a stream. La registerrpc() utilizza:

svcudp_create() per ottenere un gestore UDP (default per Sun). Se sock vale RPC_ANYSOCK si crea un datagram socket per i risultati, altrimenti, il parametro è un socket descriptor (collegato ad

7


uno specifico numero di porta o meno). Se la socket associata al gestore non ha un numero di porta e non si tratti di RPC_ANYSOCK, si genera un numero di porta in modo automatico

svctcp_create() per ottenere un gestore TCP, che funziona in modo analogo: si devono definire le dimensioni dei buffer tramite cui si scambiano i dati.

Il gestore di trasporto è definito dal tipo SVCXPRT, una struttura astratta che:

contiene puntatori alle operazioni sui dati;

riferisce due socket e una porta (locale): o una per il protocollo di trasporto del server (xp_sock); o una (se richiesta in atto) a cui inviare i risultati della esecuzione

remota (xp_raddr). In caso di insuccesso, non si crea il gestore. La procedura di dispatching contiene i riferimenti alle implementazioni dei servizi di un programma RPC, lo stesso gestore e lo stesso protocollo di trasporto La procedura di dispatching seleziona il servizio da eseguire interpretando il messaggio RPC consegnato dal gestore (svc_req):

rq_proc identifica la procedura da svolgere;

rq_xprt identifica la struttura dati del gestore di trasporto, dalla quale è possibile (si veda struttura SVCXPTR): o ricavare i parametri per l'esecuzione tramite svc_getargs(); o spedire la risposta tramite la svc_sendreply().

La funzione di registrazione inserisce i servizi nel dispatching, inoltre:

la NULLPROC (numero di procedura 0) verifica se il server è attivo;

controllo della correttezza del numero di procedura, in caso contrario svcerr_noproc() gestisce l'errore

Una procedura di dispatching è associata ad una tripla {n_prog, n_vers, protocollo} mediante la primitiva svc_register().

8


3.4 Stub del Client

Il client necessita di un gestore di trasporto per RPC. L’applicazione chiamante utilizza clntudp_create() per ottenere un gestore UDP, o anche clnttcp_create() per protocollo affidabile. La callrpc() ottiene un gestore di trasporto con clntudp_create() A livello intermedio l'interfaccia RPC si basa su UDP. Non ci sono riferimenti espliciti alla socket di trasporto ed al socket address per la richiesta di esecuzione remota. Tra i parametri della clntudp_create() il valore del timeout fra le eventuali ritrasmissioni; se il numero di porta all'interno del socket address remoto vale 0, si lancia un'interrogazione al port mapper per ottenerlo. clnttcp_create() non prevede timeout e definisce dimensione buffer di input e di output. L'interrogazione iniziale causa una connessione L’accettazione della connessione, consente la RPC. Creato il gestore di trasporto si raggiunge un’entità {n_prog, n_vers, protocollo} tramite il numero di porta relativo la procedura di dispatching è già selezionata. La clnt_call() specifica solo gestore di trasporto e numero della procedura:

se UDP, il numero di ritrasmissioni è dato dal rapporto fra tout ed il timeout indicato nella clntudp_create();

se TCP, tout indica il timeout oltre il quale il server è considerato irraggiungibile.

Più gestori possono condividere una stessa socket. 3.5 Sviluppo del programma CLIENT

Successivamente vengono implementati il programma client e il programma server. Il client chiede al server il servizio di calcolo della media, della varianza e della deviazione standard, mentre il server restituisce i risultati ottenuti al client. Tutto il meccanismo avviene dopo che fra il client ed il server è stata creata una connessione, 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.

9


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. Una volta che il client ottiene il numero di porta del server inviando anche l’indirizzo dove ricevere le risposte, apre una connessione, che resta aperta fino a quando non viene invocata la funzione clnt_destroy() che la chiude. Nel nostro caso abbiamo: cl = clnt_create (host, STAT_PROG, STAT_VERS, "udp");

Si noti la creazione del gestore di trasporto client: il gestore di trasporto (cl) gestisce la comunicazione col server, in questo caso utilizzando un trasporto senza connessione (“udp”). Il client deve conoscere:

l’host remoto dove è in esecuzione il servizio;

alcune informazioni per invocare il servizio stesso (programma, versione e nome della procedura).

Per l’invocazione della procedura remota, abbiamo le seguenti stringhe: media = calcolamedia_1(&vettore, cl);

varianza = calcolavarianza_1(&vettore, cl);

devstandard = calcoladevstandard_1(varianza, cl);

Si noti che il nome della procedura cambia: si aggiunge il carattere underscore seguito dal numero di versione (in caratteri minuscoli). Gli argomenti della procedura server sono due:

l’argomento di ingresso vero e proprio;

il gestore di trasporto del client. Il client gestisce gli errori che si possono presentare durante l’invocazione remota usando le funzionalità di stampa degli errori: clnt_pcreateerror e clnt_perror.

10


3.6 Sviluppo delle procedure di servizio

Il codice del servizio contiene il codice eseguito sul server. La sua struttura deve includere l’header file stat.h. L’intestazione delle procedure scritte all’interno del programma devono avere la forma nomeProcedura_numeroVersione_svc() dove:

nomeProcedura è lo stesso utilizzato sia dal client che quello dichiarato nel stat.x;

numeroVersione deve essere lo stesso di quello utilizzato nel client altrimenti sono viste come due procedure diverse.

Nel nostro caso abbiamo: double *calcolamedia_1_svc (iarray *vettore, struct

svc_req *rqstp)

double *calcolavarianza_1_svc (iarray *vettore, struct

svc_req *rqstp)

double *calcoladevstandard_1_svc (double *varianza,

struct svc_req *rqstp)

Si noti che:

sia l’argomento di ingresso che l’uscita vengono passati per riferimento;

il risultato punta ad una variabile statica, per essere presente anche oltre la chiamata della procedura.

Gli argomenti della procedura server sono due:

l’argomento di ingresso vero e proprio;

il gestore di trasporto del server.

11


4. Istruzioni di compilazione Compilazione per generare il file header, il file per le conversioni xdr e gli stub: rpcgen stat.x

che produce i file:

stat.h

da includere in stat_server.c (implementazione della procedura) e in stat_client.c (client che chiama la procedura);

stat_xdr.c che contiene le routine di conversione xdr;

stat_clnt.c stub del client;

stat_svc.c stub del server. Compilazione per generare l’eseguibile del client: gcc stat_client.c stat_clnt.c stat_xdr.c –o stat2

produce il comando stat Compilazione per generare l’eseguibile del server: gcc stat_server.c stat_svc.c stat_xdr.c –o stat_server2

-lm

produce il comando stat_server Si noti che per specificare il collegamento alla libreria matematica bisogna aggiungere il comando –lm nella compilazione gcc. Per l’esecuzione:

lanciare il server con: stat_server&

lanciare il client con: stat ‘nome_server’ (o indirizzo IP del server)

Chiamate a Procedure Remote - Dipartimento di Informaticadisys/RPCAndreaPazienza.pdf · Andrea...

Documents

Transcript of Chiamate a Procedure Remote - Dipartimento di Informaticadisys/RPCAndreaPazienza.pdf · Andrea...