L’appel de procédure éloignée

Remote Procedure Call

RPC
 Introduction
Conception d’une application distribuée:
Conception orientée communication
• Définition d’un Protocol d’application inter-opérant entre
C/S
• Conception du comportement des processus C et S en
spécifiant comment ils réagissent aux messages
Conception orientée traitement
• Construction d’une application conventionnelle
(environnement mono- machine)
• Subdivision de l’application en plusieurs modules
s’exécutant en parallèles
 Introduction

Souvent, Quand un client envoie une requête ,

le client est suspendu (bloqué) jusqu’à la
réception de la réponse (Opération bloquante)

Analogie avec un appel de fonction :

La fonction ne rend la main au programme
appelant qu’une fois le traitement terminé
 RPC
Définition :
Remote procedure call <RPC> est un Protocol de
demande de service à partir d’un programme situé sur
un ordinateur distant via le réseau. Il suppose
l’existence d’un protocole de transport de bas niveau
facilitant le transport de messages entre les
programmes communicants.
• L’ RPC est un paradigme de communication permettant
d’appeler une procédure à distance
• C’est un outil élémentaire pour réaliser le mode C/S
• Le service demandé est présenté sous forme de
procédure que le client peut faire exécuter à distance
par le serveur.
 RPC
Objectifs:
 Faire exécuter un service par un processus distant
 Faire en sorte que l’appel distant ressemble le plus à
un appel local. pourquoi?
 L’RPC doit conserver la même sémantique qu’un
appel de procédure local.
• L’Appel  envoi d’un message contenant le nom de la
fonction et les paramètres
• Le Retour  un message retourne le résultat à
l’appelant , une fois le traitement terminé.
 RPC
Avantages:
 Mise au point local avant répartition.
 Application (traitement) non modifiable lors du passage
à l’appel distant.
• Transparence réseau: l’appel distant se programme de la même
manière qu’un appel local
 Indépendance par rapport aux protocoles de
communication.
 Réutilisation y compris en environnements hétérogènes.
 Simplicité de la mise en œuvre
• L’application n’a pas à manipuler directement les sockets
• Masque l’interface Socket
• Paradigme de l’appel au lieu des opérations send et receive
 RPC
Entités impliquées:
1. Le client : programme demandeur du service
2. Le serveur : programme exécutant le service
3. Les primitives de communication : envoi() reçoit()
4. Le bout client : programme représentant le serveur dans
l’espace adressable du client.
5. Le bout serveur: programme qui appelle la procédure du
serveur en local. Il représente l’exécution du client.
NB: les termes suivant ont la même signification et sont
utilisées de manière interchangeable.
Bout = Talon = Souche = Stub

Question: où siègent les entités citées ci-dessus ?

 Transparence du modèle RPC
Transparence réseau assurée par les souches
• Interception locale de l’appel de la procédure par la souche
• Empaquetage/dépaquetage des arguments par les souches
Le modèle RPC
 Le modèle RPC
Description du schéma:
• L’appel de la procédure correspond à un appel
local du client vers une procédure contenue dans
le bout client
Etapes 1,2,3:
1. Le bout client collecte les arguments , les formate selon
un format prédéfini  msg de marshalling
2. *Génération d’un ID pour RPC
3. *Mise en place d’un délai de garde
4. Détermination de l’@ du serveur (portmap)
5. Transmission du msg au logiciel de communication 
6. Transmission du msg via le réseau à l’appelé.
 Le modèle RPC
Description du schéma (suite):
• Le protocole de transport délivre le msg RPC coté
serveur (Etapes 4,5)
Etapes 6,7,8:
1. Le bout serveur réceptionne le msg et désassemble les
arguments (dépaquetage)  msg de unmarshalling
2. *Enregistrement de ID RPC
3. Transmission de l’appel à la procédure pour exécution
 appel local
4. Traitement selon politique implémenté (sélection d’un
thread ou création de processus)
5. Transmission du résultat au bout serveur
 Le modèle RPC
Description du schéma (suite):
• Envoi des résultats à l’appelant
Etapes 9,10,11:
1. Le bout serveur effectue l’assemblage des
arguments du résultat dans un msg de retour
2. Transmission du msg de résultat au Protocol pour
émission sur le réseau .
3. *Mise en place d’un délai de garde
4. Transmission des données (mgs de retour )sur le
réseau
 Le modèle RPC
Description du schéma (suite et fin):
• Réception des résultats par l’appelant:
Etapes 12,13,14:
1. Transmission de l’appel au service RPC coté Client
2. Dépaquetage des arguments de retour par le bout
client
3. *Le délai de garde armé à l’envoi est désarmé
4. *Emission d’un ACK au serveur
5. Transmission des résultats de l’appel au client
 Rôles des talons
Les souches ouvrent une socket BSD et encodent / décodent les
paramètres.
L’interface RPC
 Problèmes liés aux RPCs

Le client et le serveur ont chacun un

espace adressable propre

La procédure éloignée n’a pas accès aux variables et

aux données définies dans l’espace adressable de
l’appelant.
 Problèmes liés aux RPCs
1) Passage de paramètres
 Passage par valeurs  pas de pb
 Passage par @ (référence)  aucun sens (non
permis)
 Variables globales  pas possible
 Envoi de types de données complexes difficile.
Solutions:
• Mécanisme de copie restauration (pb du double
référencement)
• Reconstitution de l’état de la mémoire du client sur le
serveur (sol couteuse) Transmission de toute la zone
pointée
 Problèmes liés aux RPCs
2) Représentation des données
Pb: les machines C et S peuvent échanger des données
ayant des représentations internes différentes : Elles
n’ utilisent pas le même codage.

 Caractères (ASCII,EBCDIC,UNICODE)
 Taille de l’objet typé : taille des mots mémoires,
nombre d’octets ((16,32,64 bits)
 Représentation flottante des nombres réels
 Représentation des entiers (complement à 1 ou 2)
 Le modèle mémoire : codage de données ( big endian /
little endian)
 Problèmes liés aux RPCs

Solutions:
• Négociation entre C et S

• Utiliser une représentations externe commune

 Prévoir un format pivot (ex: XDR ou CDR)

• Utiliser un convertisseur
 Prévoir tous les cas possibles (n2 convertisseurs)
 Problèmes liés aux RPCs
Le modèle mémoire "big endian" ou "little
endian"
Le modèle mémoire définit la manière dont les
données sont représentées en mémoire.
Deux modèles s'affrontent depuis des années :
le "big-endian" Motorola : signifie "big end" ( most
significant byte ), indiquant que l'octet de poids fort est
en premier.
le "little endian" Intel. signifie "little end" ( least
significant byte ), indiquant que l'octet de poids faible
est en premier.
 Problèmes liés aux RPCs
Exemple1 un mot long ( 32 bits ) 0x0AC0FF00
Bigendian 0x0A 0xC0 0xFF 0x00
Littleendian 0x00 0xFF 0xC0 0x0A
Exemple2:
deux machines reliées en réseau via le protocole TCP/IP : ce dernier
étant sur le modèle "big endian".
une adresse IP par exemple sera envoyée et reçue avec son octet le
plus significatif en premier.
Sans traitement particulier, si une des machine envoi une adresse IP
192.0.1.2, qui en "little endian" fait 0x020100C0 ( représentation
hexadécimale 32 bits ), à une machine de type SPARC, celle-ci
reconstruit une fausse adresse ( 2.1.0.192 ) à partir des octets reçus
0x02,0x01,0x00 et 0xC0. D'où la nécessité d'identifier le type de
modèle mémoire et de réaliser ou non les traitements particuliers
pour stocker correctement les données en mémoire.
 Problèmes liés aux RPCs
3) Gestion des exceptions
Pas de mécanisme spécifique de gestion des exceptions
comme en java. 
 Crash du client
 Crash du serveur
Solutions:
• Retransmission des appels et résultats
• Serveur avec ou sans état??
• Destruction des duplicatas côté serveur
 Sémantique de l’appel nécessaire.
 Problèmes liés aux RPCs
4) Dépendance à la localisation du serveur
Difficulté de réaliser la transparence à la localisation du
serveur
 Désignation et liaison utilisant le portmap
 Eléments à désigner : site d’execution et la
procedure à executer
 Types de désignation:
 Statique
 dynamique
 Problèmes liés aux RPCs

4) sécurité: prévoir des mécanismes pour

 Authentification du client
 Confidentialité des échanges
• Quelles machines distantes sont autorisées à exécuter la
procédure ?
• Quels utilisateurs sont autorisés à exécuter la procédure ?

5) Efficacité :Peu efficace pour de nombreux appels

 Les RPCs:
Exemples
 ONC RPC (SUN) : Open Network Computing RPC: (02) deux
versions existantes:
 Version batie sur l’API socket : fonctionnement en
tcp/udp
 Version batie dur l’API TLI (transport layer interface)
appelée TI RPC (transport independant rpc)
 DCE RPC (OPEN GROUP): Distributed Computing
Environnement RPC
 MS RPC (MICROSOFT)
Aplications réparties utilisant les rpcs:
 NFS (Network file system)
 NIS (Network Information Service)
 Implémentation des RPCs : RPC sun
 ONC RPC (SUN) : Open Network Computing RPC
• V1: RFC 1057 en 1989
• V2 :RFC 1831 en 1995
• Conversion des données via XDR
XDR: external data représentation RFC 1832
• Transport via TCP ou UDP
• Déploiement : accès aux services RPC via le
portmapper écoutant sur le port 111
• Outils : rpcgen (précompilateur)
rpcinfo (gestion des infos service RPC),
portmap(annuaire)
 Implémentation de SUN RPC

Que définit le sun RPC?

Le format des messages (call et reply)
Le format des arguments (ex: un seul
paramètre en E/S)
Possibilité d’utiliser TCP ou UDP (voir la
primitive clnt-create() )
Utilisation de XDR
 Implémentation de SUN RPC
Identification des procédures distantes
Un pgm distant correspond à un service avec
des procédures et des données propres
Le pgm est écrit en utilisant un IDL(interface
définition langage) proche du C : c’est le
contrat
Chaque pgm est identifié par un entier unique
UUID (Universal Unique Identifer) codé sur 32
bits à choisir entre
0x 2000 0000 et 0x 3FFF FFFF
 Implémentation de SUN RPC
Identification des procédures distantes (suite)

 Un programme peut avoir plusieurs procédures

– Chaque procédure a un nom , un numéro
– Un pgm peut avoir plusieurs versions
 Une procédure est identifiée par un triplet
– Numéro du programme
– Numéro de la version
– Numéro de la procédure au sein de la version

NB: Une procédure ne possède qu’un seul argument en

entrée et en retour
Utiliser des structures pour passer ou retourner de multiples
arguments
 Implémentation de SUN RPC
Exemple
Interface « CALCULATION. X »
struct two_int {
Int a;
Int b; }

Program CALCULATION -PROG {

Version VERSION-VERS {
Int SUM (two_int) = 1;  numéro de procédure
Int MUL (two_int) = 2;  numéro de procédure
}= 1 numéro de version
}=0x 20000000;  numéro de programme
 Implémentation de SUN RPC
Programmation
Etape1:
Le programmeur fournit un fichier d’interface <nom- fichier.x>
contenant:
1. La description des structures de données
2. Les entêtes des fonctions réalisant le service
Etape2:
Utiliser l’utilitaire rpcgen (RPC program générator) pour générer
du code C pour 04 fichiers
Rpcgen <nom-fichier>.x
Résultat: production de 04 fichiers dont les nom sont dérivés du
nom de fichier d’interface
 Implémentation de SUN RPC
Fichiers générés:
1. <nom-fichier> .h : fichier de déclaration (entête)
Déclaration de toutes les structures et signatures
2. <nom-fichier>_xdr .c : procédures XDR utilisées
Fonctions de codage XDR
2. <nom-fichier>_clnt.c: stub client
3. <nom-fichier>_svc.c : stub serveur

NB: rpcgen –a <nom-fichier>.x

l’option –a permet de produire un squelette pour le
programme client et un squelette pour le programme
serveur distant
 Implémentation de SUN RPC
Pour l’exemple
 Fonction de traduction XDR dans « calculation_xdr.c
(généré)
 Projection du contrat dans calculation.h (généré)
 Coté client
Calculation_client.c: fonction main(), utilisation du service
Calculation_clnt.c (généré): souche cliente
 Coté serveur
Calculation_serveur.c : implémentation du service
Calculation_svc.c (généré) fonction main + souche
serveur
Implémentation de SUN RPC
 Implémentation de SUN RPC

• Remarque 1 : toute procédure distante

accepte en entrée un pointeur sur les
arguments qu’elle aurait eu en local ⇒
indirection lors de l’appel
• Remarque 2 : toute procédure distante
retourne un pointeur sur les résultats qu’elle
aurait retourné en local
• Remarque 3 : _numéro_de_version est rajouté
au nom local de la procédure
 Implémentation de SUN RPC

Le résultat (result) doit exister après l'exécution de la fonction car on

retourne son adresse.
En static, il est défini dans la zone de donnée et on peut y faire référence
après le traitement de la fonction
Implémentation de SUN RPC
RPC: implémentation
 Déploiement
Portmap ou port mapper (Linux)
rpcbind (solaris):

processus particulier chargé d’ enregister les

services RPC tournant sur une machine
 reçoit les demandes d’identification de
service de la part des clients sur le port 111
Joue le rôle d’un service de nom.
Déploiement
 Implémentation de SUN RPC

Exemple:$ rpc info -p localhost