Les appels de

procdures distantes
L.FETJAH
Approches de conception des
applications rparties
Deux approches :
Conception oriente communication :
dfinition du protocole dapplication (format et syntaxe des
messages) inter-oprant entre le client et le serveur;
conception du serveur et du client, en spcifiant comment
ils ragissent aux messages changs;
Conception oriente application :
construction dune application conventionnelle, dans un
environnement mono-machine
subdivision de lapplication en plusieurs modules qui
pourront sexcuter sur diffrentes machines

Approche oriente
communication
Inconvnients
Gestion des formats de messages et donnes par
lutilisateur (htrognit)
Empaquettage/dsempaquettage des messages
Le modle est souvent asynchrone, ce qui rend la
gestion des erreurs plus complexe
Le modle nest pas naturel pour la plupart des
Programmeurs
Communication explicite et non transparente

Conception oriente
application
Objectif :
Garder la dmarche de conception des applications
centralises
Appel de procdure distance ou Remote
Procedure Call (RPC)
Introduit par Birrell & Nelson (1984)
Garder la smantique de lappel de procdure local ou
Local Procedure Call (LPC)
Fonctionnement synchrone
Communication transparente entre le client et le
serveur

Principe gnral
Souvent, quand un client envoie une requte , il est
bloqu jusqu' la rception d'une rponse
Analogie avec un appel de fonction
la procdure ou fonction ne rend la main au programme
appelant qu'une fois le calcul termin
RPC - Remote Procedure Call
permettre un processus de faire excuter une fonction
par un autre processus se trouvant sur une machine
distante
se traduit par l'envoi d'un message contenant
l'identification de la fonction et les paramtres
une fois le traitement termin, un message retourne le
rsultat de la fonction l'appelant

Principe gnral
Objectif des RPC
faire en sorte qu'un appel distant ressemble le plus
possible un appel local
Le processus client
li une petite procdure de bibliothque, appele stub
client, qui reprsente la procdure du serveur dans
l'espace d'adressage du client
Le processus serveur
li un stub serveur qui reprsente l'excution du client
Dissimule le fait que l'appel de la procdure n'est
pas local
le programmeur de l'application utilise un appel de
procdure normal
Modle RPC

Modle RPC

Interface RPC

Modle RPC
Intrts :
l'application n'a pas manipuler
directement les sockets
l'implmentation est indpendante
de l'OS
Inconvnient :
l'utilisation des RPC est moins performante que
l'utilisation directe des sockets (couches
supplmentaires)

Restrictions lies aux RPC
Pas de passage de paramtres par adresse :
impossible de passer des pointeurs (ou rfrences)
en effet, les espaces d'adressage du client et du serveur
sont diffrents
La procdure distante n'a pas accs aux variables
globales du client, aux priphriques d'E/S
(affichage d'un message d'erreur !)
Un appel de procdure obit un fonctionnement
synchrone : une instruction suivant un appel de
procdure ne peut pas sexcuter tant que la
procdure appele nest pas termine

Le protocole RPC
Il doit dfinir :
le format du call (message du client vers le serveur),
le format des arguments de la procdure, le format du
reply (rsultats)
Il doit permettre d'identifier la procdure
excuter par le serveur quand un call arrive
Il doit permettre d'authentifier la demande
(problmes de scurit)
Quelles machines distantes sont autorises
excuter la procdure ?
Quels utilisateurs sont autoriss excuter la
procdure ?

Problme dhtrognit
Deux solutions possibles
Codage/dcodage de chaque type de donne de
toute architecture toute autre architecture
Format universel intermdiaire (XDR, CDR, etc.)
Solution de Sun Microsystems
Format eXternal Data Representation ou XDR
Librairie XDR (types de donnes XDR + primitives
de codage/dcodage pour chaque type)
rpc/xdr.h

Implmentation de SUN
Sun Microsystems a dvelopp une technologie RPC dite
Sun RPC devenue aujourdhui un standard important
NFS (Network File Sytem) repose sur les Sun RPC
Les Sun RPC dfinissent :
le format des messages que lappelant (stub client) met pour
dclencher la procdure distante sur un serveur
le format des arguments de la procdure
le format des rsultats de la procdure
Possibilit d'utiliser UDP ou TCP pour les communications
XDR assiste les RPC pour assurer le fonctionnement dans
un environnement htrogne (reprsentation standard des
arguments et rsultats)

Identification des procdures
distantes
Un programme distant correspond un serveur
avec ses procdures et ses donnes propres
Chaque programme distant est identifi par un
entier unique cod sur 32 bits utilis par lappelant
Les procdures dun programme distant sont
identifies squentiellement par les entiers 0, 1, ...,
N
Une procdure distante est identifie par le triplet
(program, version, procedure)
program identifie le programme distant
version identifie la version du programme
procedure identifie la procdure

Identification des procdures
distantes
La procdure de numro 0 permet de tester
la disponibilit du service
Un identifiant de programme peut
correspondre plusieurs processus de
service (mount/showmount)

La smantique "au moins une
fois"
Les RPC sur un protocole de transport non fiable
(UDP)
si un appel de procdure distante sexcutant sur UDP ne
retourne pas, lappelant ne peut pas savoir si la procdure
a t excute ou si la rponse a t perdue
du ct de l'appelant :
la rception d'un reply signifie uniquement que la procdure
distante a t excute au moins une fois
du ct de serveur :
un serveur recevant plusieurs fois la mme requte ne peut
pas savoir si le client s'attend une unique excution de la
procdure ou bien s'il s'agit effectivement de N excutions
distinctes de la mme proc.

La smantique "au moins une
fois"
Le concepteur d'une application RPC utilisant UDP doit
prendre en compte le fait que la non rception d'un reply ne
signifie pas que la procdure distante n'a pas t
excute...
Exemple :
lecture dans un fichier distant :
pas grave si une demande de lecture a gnr deux excutions de la
procdure
criture dans un fichier distant :
grave s'il s'agit d'un ajout en fin de fichier ; la chane peut tre ajoute
deux fois au lieu d'une seule
Les procdures doivent tre idempotentes :
pas de procdure d'ajout en fin de fichier mais une procdure
d'criture telle position (ajout d'un paramtre prcisant o
crire dans le fichier)
Communications
client/serveur
Les sockets utilisent un port connu pour
contacter un serveur distant (ex: http=80)
Les clients RPC ne connaissent que
l'identifiant du programme RPC distant et le
numro de procdure (ex: 100003 pour NFS)
Pourtant, les communications sous-jacentes
se font en mode client/serveur : lappelant
doit connatre ladresse (IP, port) utilise par
le programme RPC distant (ex: nfsd)

Communications
client/serveur
Le numro de port du processus serveur est
attribu dynamiquement quand il dmarre
--> car le nombre de programmes RPC (identifiant
sur 32 bits) est potentiellement suprieur au
nombre de ports connus (numro de port sur 16
bits, ports rservs entre 0 et 1023)
Un processus spcial, le dmon portmap
maintient une base de donnes renseignant
les associations locales entre numro de port
et programme RPC

Le processus portmap
lorsquun programme RPC (serveur) dmarre, il
alloue dynamiquement un numro de port local,
contacte le port mapper de la machine sur laquelle il
sexcute, puis informe ce dernier de lassociation
lorsquun client dsire contacter un programme RPC
sur une machine distante, il interroge d'abord le port
mapper de cette machine pour connatre le port de
communication associ au service RPC
le port mapper est lui mme un programme RPC
(100000) mais il est le seul utiliser un port allou
statiquement : le port 111/UDP et le port 111/TCP

Le processus portmap
Les procdures du port mapper
0 : fonction vide (teste la prsence de portmap)
1 : enregistrement d'un service (local)
2 : annulation d'un service (local)
3 : demande du numro de port d'un service
enregistr localement
4 : liste tous les services enregistrs localement
5 : appel d'une procdure distante via le port
mapper
--> permet de "pinger" une procdure distante

Utilisation du port Mapper

Format des messages RPC
Rponses possibles
Plusieurs types de rponses possibles :
SUCCESS : les rsultats de la procdure sont
renvoys au client
RPC_MISMATCH : les versions RPC du client et
du serveur ne sont pas compatibles
AUTH_ERROR : problme d'authentification
PROG_MISMATCH : la procdure demande
n'est pas disponible (problme de version du
programme, )
Plus de dtails : RFC 1057

Reprsentation XDR
Les champs des messages RPC sont
spcifis dans le format XDR (eXternal Data
Representation)
XDR : reprsentation des donnes dfinie
par SUN Microsystems
dfinit le type et le format des donnes
changes sur le rseau (paramtres de la
procdure distante)
permet dchanger des donnes entre machines
ayant des reprsentations internes diffrentes


Types de donnes XDR
XDR
Lencodage XDR des donnes contient
uniquement les donnes reprsentes mais
aucune information sur leur type
Si une application utilise un entier de 32 bits le
rsultat de lencodage occupera exactement 32
bits et rien nindiquera quil sagit dun type entier
Le client et le serveur doivent alors sentendre sur
le format exact des donnes quils changent

Conception d'un programme
RPC
Ct client, entre
lappel de procdure et
la procdure distante, il
faut:
encoder les arguments
crer un message RPC
CALL
mettre ce message vers
le programme distant
attendre les rsultats et
dcoder ces rsultats
selon la reprsentation
interne de la machine
locale
Ct serveur, il faut :
accepter une demande
d'excution RPC
dcoder les arguments
selon la reprsentation
de la machine locale
dispatcher le message
vers la procdure
adquate
construire la rponse
puis encoder celle-ci
mettre le message
correspondant vers le
client


Conception d'un programme
RPC
Les procdures stubs remplacent les
procdures conventionnelles (appel de
procdure ct client, procdure appele
ct serveur)

Gnration de programme
RPC
Gnration de programme
RPC
rpcgen est un outil de gnration de programme
RPC produisant automatiquement le code pour :
les procdures stub client et serveur
un squelette de serveur
les procdures XDR d'encodage/dcodage des paramtres
et des rsultats
l'envoi et la rception des messages RPC
Le concepteur du programme RPC doit fournir un
fichier spcifiant
la description des structures de donnes des paramtres
et des rsultats
les fonctions ralisant le service dsir

Besoins
Le client a besoin de connatre le nom symbolique du
serveur (numprog,numver) et ses procdures
Publication dans un contrat (fichier .x)
Langage RPCL
Le serveur a besoin des implmentations des procdures
pour pouvoir les appeler
Fichier contenant les implmentations des procdures
Serveur et client ont besoin des stubs de communication
Communication transparente ==> gnration automatique des
stubs et des fonctions XDR de conversion de paramtres
RPCGEN (compilateur de contrat) + Runtime RPC

Le langage RPCL
Constantes
Const nom=valeur;
Enumrations et structures
Idem C
Unions
Idem structures avec variantes en Pascal
Tableaux
<type_de_base> <nom_tab> <TAILLE> (ex : int
toto<MAXSIZE>)
Dfinition de types
typedef

Forme gnrale du contrat
/* Dfinitions de types utilisateur */
...
program nomprog {
version nomversion1 {
typeres1 PROC1(param1) = 1;
...
typeresn PROCn(paramn) = n;
} = 1;
...
version nomversionm {
...
} = m;
} = numro_du_programme;

Mthodologie de
dveloppement
Ecrire le contrat toto.x dans le langage RPCL
Compiler le contrat avec RPCGEN
toto.h : dclarations des constantes et types utiliss
dans le code gnr pour le client et le serveur
toto_xdr.c : procdures XDR utiliss par le client et le
serveur pour encoder/dcoder les arguments,
toto_clnt.c : procdure stub ct client
toto_svc.c : procdure stub ct serveur
Ecrire le client (client.c) et le serveur (serveur.c)
Serveur.c : implmentation de lensemble des
procdures

Compilation et excution
Compilation
(g)cc serveur.c toto_svc.c toto_xdr.c -o Serveur
(g)cc client.c toto_clnt.c toto_xdr.c -o Client
Excution
rsh host Serveur
Client host liste darguments


Exemple
struct sum_request {
int x; int y;
};
program SUMPROG {
version SUMVERS {
int SUM(sum_request) = 1;
} = 1; /* numro de version du programme */
} = 0x2000009a; /* numro du programme */

Fichiers gnrs avec
RPCGEN
sum.h, sum_xdr.c, les stubs sum_clnt.c et
sum_svc.c
sum.h
#include <rpc/types.h>
struct sum_request {
int x; int y;
};
typedef struct sum_request sum_request;
bool_t xdr_sum_request ();
#define SUMPROG ((u_long)0x2000009a)
#define SUMVERS ((u_long)1)
#define SUM ((u_long)1)
extern int *sum_1();