Chapitre 3:

LES APPELS DE
PROCÉDURE
DISTANTS
 Contexte

Les systèmes distribues modernes consistent souvent en des milliers voire des
millions de processus disperses sur des réseaux peu fiables.

→ Comment peuvent-ils communiquer ?

Une solution = Les RPCs (Remote Procedure Call)

– Un modele tres repondu de communication entre des processus d’un systeme

distribue

● Objectif : Un processus appel localement une procédure qui est réellement

implémentée sur une machine distante
 Rappel du schéma CS

Appel synchrone Requête-Réponse

! Mise en oeuvre
Bas niveau : utilisation directe du transport : sockets (construit sur
!

TCP ou UDP)
" Exemple : utilisation des sockets en C
!Haut niveau : intégration dans un langage de programmation : RPC
(construit sur sockets)
" Exemple : RPC en C
 Définition

Appel de procédure à distance (Remote Procedure Call, ou RPC) : un

outil pour construire des applications client-serveur dans un langage de
haut niveau
! L’appel et le retour ont lieu sur un site , l’exécution se déroule sur un site

distinct

L’effet de l’appel doit être identique dans les deux situations (local et
distant)
 Les RPCs

Objectif :
permettre aux programmes d’appeler des procedures situees sur d'autres machines.

● Lorsqu'un processus sur la machine A appelle une procedure sur le machine B,

le processus d'appel sur A est suspendu et l'execution de la procedure a lieu sur B.

● Les informations sont acheminees dans les parametres et les resultats de la procedure.
– Aucune transmission de message n’est visible au programmeur.
 Les approches à RPC

 SUN ONC/RPC
 Open Network Computing / Remote Procedure Call

 OSF DCE
 Open Software Foundation - Distributed Computing Environnment

 Systèmes de gestion de bases de données: procédures stockées.

 OMG CORBA
 Object Management Group - Common Object Request Broker Architecture

 SUN Java RMI ❙

 Remote Method Invocation
 MOM –Middleware Oriented Message
 Microsoft - DCOM
 Distributed Component Object Mod
Avantages attendus

!Facilité de programmation
! La complexité des protocoles de communication est cachée
! Ne pas avoir à programmer des échanges au niveau réseau

! Facilité de mise au point : une application peut être

mise au point sur un site unique, puis déployée sur
plusieurs sites
! Portabilité : résulte de l’usage d’un langage de haut
niveau
! Indépendance par rapport au système de communication
Problèmes de réalisation

! Transmission des paramètres

! conversion entre la forme interne, propre à un langage,
et une forme adaptée à la transmission

! Gestion des processus

! Séquentielle et parallèle

! Réaction aux défaillances

! Trois modes de défaillance indépendants : client, serveur, réseau
Mise en œuvre

1. Par migration
2. Par mémoire partagée
3. Par messages
4. Par appel léger (LRPC)
 Réalisation par migration

Stratégie de migration
! Le code et les données de la procédure distante sont amenés sur le
site appelant pour y être exécutés par un appel local habituel.
! Analogie
! Stratégie de pré-chargement en mémoire.
! Avantages
! Très efficace pour de nombreux appels
! Inconvénients
! Univers d’exécutions homogènes (ex machine virtuelle).
! Performances selon le volume de codes et de données.
! Problèmes de partage des objets.
 Réalisation en mémoire partagée répartie

 L’appel distant est réalisé en utilisant une mémoire virtuelle partagée

répartie
 La procédure est installée pour le client comme pour le serveur dans la
mémoire virtuelle partagée répartie.
Mais, réellement, elle est dans l’espace mémoire du serveur.
 L’appel du client se fait comme si la procédure était
locale, provoquant un premier défaut de page sur le début du code de la
procédure.
 Le code et les données de la procédure distante sont amenés page par
page sur le site appelant selon le parcours du code et des données.
! Analogie avec une stratégie page à la demande.
2
 Réalisation par messages

Deux messages (au moins) échangés : requête et réponse

 Le premier message correspondant à la requête est celui de l'appel de procédure,
porteur des paramètres d'appel.
 Le second message correspondant à la réponse est celui du retour de procédure
porteur des paramètres résultats.
 Notion des souches (1/2)

Un mode de réalisation par interception (wrapping)

! Une procédure intercepteur (wrapper) intercepte l’appel
d’un client vers un serveur et modifie le traitement serveur à
sa guise
! Décomposition en traitements avant et après le
traitement serveur
! Décomposition en intercepteur coté client, souche client,
et intercepteur coté serveur, souche serveur
! Souches (ou Stubs) =Talons = Squelettes (ou Skeletons)…
! Objectif: transformer l’appel local en un appel distant
 Notion des souches (2/2)

 La souche client ("client stub")

 Intercepteur (procédure) coté client qui reçoit l’appel en mode local,

Le transforme en appel distant,
 Envoie message d’appel de procédure,
 Reçoit le message contenant les résultats après l’exécution,
 Retourne les résultats comme dans un retour local de procédure.

 La souche serveur ("server stub")

 Intercepteur (procédure) coté serveur qui reçoit le message d’appel,

 Fait réaliser l’exécution sur le site serveur par la procédure serveur,
 Récupère les résultats et retransmet les résultats par message.
3
 Etapes de RPC par messages (1/2)

Étape 1 : Le client réalise un appel procédural vers la procédure souche client,

la souche client collecte les paramètres , les emballe dans le message d’appel
! Étape 2 : La souche client demande à une entité de transport locale la

transmission du message d'appel

! Étape 3 : Le message d’appel est transmis sur un réseau au site serveur

Étape 4 : Le message d’appel est

délivré à la souche serveur La souche
serveur déballe les paramètres
! Étape 5 : La souche serveur réalise
l’appel effectif de la procédure
serveur
 Etapes de RPC par messages (2/2)

Étape 6 La procédure serveur ayant terminé son exécution transmet à la souche serveur
dans son retour de procédure les paramètres résultats. La souche serveur collecte les
paramètres retour, les emballe dans un message.
! Étape 7 La procédure souche serveur demande à l ’entité de transport serveur la

transmission du message de réponse.

! Étape 8 : Le message de réponse

est transmis sur un réseau au site
client.
! Étape 9 : Le message de réponse

est délivré à la souche client. La

souche client déballe les
paramètres résultats.
! Étape 10 : La procédure souche

client transmet les résultats au client

en effectuant un retour habituel de
procédure en mode local.
 Diagramme de RPC par messages

Les talons (ou souches) client et serveur sont créés (générés automatiquement) à partir d’une
description d’interface
 Description d’interface

! Interface = “contrat” entre client et serveur

! Définition commune abstraite

! Indépendante d’un langage particulier (adaptée à des langages
multiples)
! Indépendante de la représentation des types
! Indépendante de la machine (hétérogénéité)
! Contenu minimal
! Identification des procédures (nom, version)
! Définition des types des paramètres, résultats
! Définition du mode de passage (IN, OUT, IN-OUT)
! Extensions possibles
! Procédures de conversion pour types complexes
RPC par message

! Avantages

! Applicable en univers hétérogènes moyennant des

conversions
! Partage d’accès sur le site serveur

! Inconvénients
! Pas d’usage des pointeurs dans les paramètres
! Échange de données complexes/de grande taille
délicat
! Peu efficace pour de très nombreux appels
 Lightweight RPC (LRPC)

Quand on appelle un serveur qui se trouve sur la même machine, la traversée des
couches réseaux est inutile et coûteuse
# Optimisation de la communication

! Problème: Client et Serveur (2 processus) qui se trouvent dans deux domaines de

protection différents !

! Solution: la communication réseau est réalisée par un segment de mémoire

partagée entre le client et le serveur qui contient une pile pour les paramètres d’appel
et de réponse.

! LRPC: principe de RPC mais entre processus locaux s'exécutant sur la même
machine
 Lightweight RPC (LRPC)

! Avantages
! Transmission d’appel très performant comme mode de RPC local.
! Limites
! Uniquement applicable dans une même machine.
 Synthèse sur les modes de réalisation

! RPC par messages :

! Le premier modèle implémenté
! Supporte l’hétérogénéité

! Le plus simple à réaliser

" RPC, RMI, DCE, CORBA, DCOM, SOAP
!Des optimisations peuvent être obtenues par
l’usage des autres solutions
! Exemple :
" Chorus
a développé les quatre solutions.
" DCOM a développé RPC par messages + LRPC
“ Transmission
des arguments
”
 Transmission par valeur

!Le seul mode de transmission des données dans les messages en réseau
! Si le client et le serveur utilisent des formats de de données
différents $ Conversion
! Définition du couple syntaxe abstraite/syntaxe de transfert des
données échangées:

! Syntaxe abstraite
! analogue à celles des langages évolués,
! facile à générer pour un développeur d’application
! À partir de la syntaxe abstraite : codage/décodage de la syntaxe de
Transfert

! Syntaxe de transfert : une représentation lexicale des données

simples et une convention d’alignement (emballage/déballage) des
données commune au client et au serveur
 Transmission par valeur
dans l’appel de procédure distante

!En appel de procédure distante :

! génération automatique du code des souches à partir de la
syntaxe abstraite
! les souches fabriquent la syntaxe de transfert en réalisant
l’alignement (emballage/déballage) des paramètres dans les
messages.

Définition des nouveaux langages de syntaxe abstraite

 adaptés aux appels de procédure distante :
Interface Definition Language (IDL)
 Pourquoi les langages IDL ?

! Être indépendant des langages évolués utilisant le RPC

! Permettre l’appel distant avec tout langage évolué

! Définition d’un langage pivot (intermédiaire) de description de

données ayant des fonctionnalités assez riches pour les langages les
plus récents.

! Notion de correspondance entre les types d’IDL et les

types des langages existants
Exemples d’IDL
et de format de présentation en RPC

! SUN RPC
! RPCL - XDR eXternal Data Representation
! OSF DCE
! IDL DCE - Format NDR Network Data Representation
! OMG CORBA
! IDL Corba - Format CDR Common Data Representation, Protocole IIOP
! SUN Java RMI
! Java - Protocole JRMP Java Remote Method Protocol
! Microsoft DCOM
! MIDL Microsoft IDL - DCOM Protocole ORPC Object RPC Format NDR
! Services Web
! Web Services Definition Language (WSDL) – SOAP
 Autres modes de transmission :
passage par adresse

Le passage par adresse utilise une adresse mémoire centrale du site de

l’appelant qui n’a aucun sens sur l’appelé (sauf cas particulier)

! 3 solutions :

! Interdiction totale des pointeurs "La solution la plus répandu

! Passage par adresse en mémoire virtuelle partagée répartie
! Simulation du passage par adresse en utilisant une copie
restauration
 Simulation par copie restauration

!A l’appel: copie des valeurs des paramètres de l’appelant vers l’appelé

! Au retour: copie de nouvelles valeurs pour les paramètres de l’appelé vers
l’appelant

Marche bien dans beaucoup de cas mais violation dans certains cas de la
sémantique du passage
 Simulation par copie restauration

!Exemple du problème de violation

procédure double_incr ( x , y ) ;
x , y : entier ;
début
x := x + 1 ;
y := y + 1 ;
fin ;
Séquence d’appel : passage par adresse
a := 0 ;
double_incr ( a , a ) ;
Résultat attendu : a = 2
Utilisation d’une copie restauration
Résultat obtenu : a = 1
“
Désignation et liaison

”
 Désignation

 La structuration des noms et références permet de désigner les services distants :

Nom symbolique : une chaîne de caractères désignant la procédure dans un
annuaire ou serveur de nom
Référence : une structure de données permettant de réaliser l’appel
 Référence : selon l’implantation considérée:
Désignation du protocole permettant l’accès distant (TCP ou UDP)
Désignation de l’hôte où se trouve le serveur (adresse IP)
Désignation du point d’accès de service transport (numéro de port)
 Désignation de la procédure
 Serveur de nom : une table qui assure la correspondance entre nom symbolique et
référence
 Liaison

 Moment de liaison : précoce (statique) ou tardive (dynamique)

 Statique :
 localisation du serveur connue à la compilation
 pas d’appel à un serveur de noms (ou appel à la compilation)
 Dynamique : localisation au moment de l’exécution, non connue à la
compilation
 Désignation symbolique des services (non liée à un site d’exécution)
 Liaison au premier appel : consultation du serveur de noms au premier
appel seulement
 Liaison à chaque appel : consultation du serveur de noms à chaque appel
 1, 2 : le serveur s’enregistre auprès de
l’annuaire avec nom,
@serveur, #port
 3, 4, 5 : le client consulte l’annuaire pour
trouver @serveur, #port à partir du nom
symbolique
 L’appel peut alors avoir lieu
 RPC : désignation et liaison utilisant
le portmapper

 Si le serveur est connu (cas fréquent): on peut utiliser un service de nommage local au
serveur, le portmapper
 Un service enregistre le n° de port de son veilleur auprès du portmapper et le veilleur se
met en attente sur ce port
 Le portmapper a un n° de port fixé par convention (111)
 Solution proposée par les RPC ONC, un programme de binding (RFC 1823) :
 le portmapper (version 2) : spécifique à TCP/UDP: le portmapper est lui-même un
serveur rpc.
 rpcbind (versions 3 et 4) : indépendant du transport
“
Gestion du contrôle

”
 Contrôle client : RPC en mode
synchrone

 L’exécution du client est suspendue tant que la réponse du serveur n’est pas revenue
ou qu’une condition d’exception n’a pas entraîné un traitement spécifique

 Avantage : le flot de contrôle est le même que dans l’appel en mode centralisé.
 Inconvénient : le client reste inactif.
 Solution au problème de l’inactivité du client : création des activités concurrentes
 Création de (au moins) deux activités (« processus léger » ou « threads ») sur le site
client:
 L’une occupe le site appelant par un travail à faire.
 L’autre gère l’appel en mode synchrone en restant bloquée :
Le fonctionnement est exactement celui d’un appel habituel.
Contrôle client : RPC en mode
asynchrone

 Le client poursuit son exécution immédiatement après l’émission du message

porteur de l’appel
 La procédure distante s’exécute en parallèle avec la poursuite du client
 Le client doit récupérer les résultats quand il en a besoin
 Contrôle serveur : exécution
séquentielle des appels

 Les requêtes d’exécution sont traitées l’une après l’autre par le serveur exclusion
mutuelle entre les traitements.
 Si la couche transport assure la livraison en séquence et que l’on gère une file
d’attente « FIFO : premier arrivé premier servi », on a un traitement ordonné des
suites d’appels.
Contrôle serveur: exécution parallèle
des appels

 le serveur créé un processus ou une activité (« processus léger » ou « thread »)

pour chaque appel
 Gestion possible de pool de processus ou d’activités
 Les appels sont exécutés en parallèle.
 Si les procédures manipulent des données globales persistantes sur le site
serveur, le contrôle de concurrence doit être géré.