Les RPC

Master RSSI/Réseaux et Systèmes Répartis

1ème année (Semestre 2)
UDL-SBA

Dr BOUAMAMA Samah

2016/2017
introduction

• La communication par sockets consiste souvent à invoquer des

commandes à distance
• Difficultés :
• Lourdeur de programmation
• Encodage des données (paramètres, résultats)
• Identification du serveur, du protocole, …
• Non naturel
 RPC : Remote Procedure Call,
- Est un concept introduit par Birrel et Nelson en 1984.

- Protocole défini par les :

- RFC 1050 (version 1) : avril 1988
- RFC 1057 (version 2) : juin 1988
- RFC 1831 (mise à jour version 2) : août 1995

- Modèle de réalisation d’une interaction client-serveur, où l’opération à réaliser est présentée sous la
forme d’une procédure, que le client peut faire exécuter à distance par le serveur.
- RPC est un cas particulier du modèle de passage de messages.

- Le client: invoque, génère l’appel distant et récupère le résultat :

Invoque ( id_client, id_serveur, nom_procedure, paramètres);

- Le serveur: reçoit, traite un appel et répond:

Traite (id_client, id_serveur, nom_procedure, paramètres);
 Objectifs du RPC
• Retrouver la sémantique “classique” de l’appel de procédures local (LPC) qui est une structure
familière aux programmeurs;
• S’affranchir du côté basique des communication en mode message, exp: MOM;
• Garder la démarche de conception des applications centralisées;
• Fonctionnement synchrone;
• Communication transparente entre le client et le serveur.

Rappels:
- MOM “Message-Oriented Middleware”: Famille de logiciels permettant l'échange de messages
entre les applications présentes sur un réseau informatique.
- Synchrone : Qui se passe en même temps, à la même vitesse.
- Asynchrone : Opposition à synchrone.
Le modèle LPC

 Notion de contexte et de pile d’exécution

 Déroulement
 Empilement des paramètres
 Copie dans la pile des paramètres passés par valeur.
 Empilement des références des paramètres passés par adresse.
 Empilement de l’adresse de retour
 Empilement des variables locales
 Exécution du code de la procédure
Passage de paramètres dans LPC

 Appel par valeur

 Copie de la valeur du paramètre dans la pile d’exécution
 Appel par référence
 Copie de l’adresse de la variable paramètre dans la pile
 Tout changement sur la variable est directement visible

 Appel par copie/restauration

 Copie de la valeur de la variable dans la pile
 Copie dans la variable après exécution de la procédure
 Utilisé dans certains langages (inout en Ada) (n’existe pas en C)
Caractéristiques et comparisons
 RPC : principe
Programme Procédure A Procédure B
principal (serveur) (serveur)

procA() procB()

return return return

réseau réseau
Machine 1 Machine 2 Machine 3
 Le modèle RPC
 Même sémantique que le modèle LPC
 Position par rapport à OSI
 Couche session
 Communication synchrone et transparente
 Utilisation transparente de sockets en mode connecté
 Différentes implémentations
 DCE-RPC de l’Open Software Foundation (OSF)
 ONC-RPC de Sun (NFS, NIS, etc.)
 Fonctionnement
Machine A Stub client Stub serveur Machine B

Assemblage Désassemblage
Appel des paramètres des paramètres Appel

Client Serveur
Retour Désassemblage Assemblage
Retour
des résultats des résultats

Noyau OS Déroutement Déroutement Noyau OS

Réseau
Mise en œuvre de l’appel de procédure
distante

1) Par migration.
2) Par mémoire partagée.
3) Par messages.
4) Par appel léger.
1- Réalisation de l’appel de procédure distante 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 (fermeture d’objets, …).
 2- Réalisation de l’appel de procédure
distante 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 partagée répartie.
• Elle est en fait dans l’espace réel 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 de l’appel de procédure
distante en mémoire partagée répartie

Avantages
Efficace en cas de nombreux appels.
Efficace si tout le code et les données ne sont pas visités.
Résout le problème de l’utilisation des pointeurs (références d’adresses en mémoire).

Inconvénients
Univers de systèmes homogènes.
Volume de codes et de données à échanger pages par pages.
Problèmes de partage selon cohérence de la mémoire répartie.
3- Réalisation de l’appel de procédure distante par messages
asynchrone
Deux messages (au moins) échangés: requête et réponse.
 Notion de souches

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 intercepteur coté client et intercepteur coté serveur.
Décomposition en traitements avant et après le traitement serveur.

Souches: transformation d’un appel local en appel distant.

Objectif de génération automatique des souches connaissant le profil

d’appel de la procédure distante.

Très nombreuse terminologie dans ce cas : Souches ("Stubs"), Talons,

Squelettes ("Skeletons")...
Les souches: diagramme global d’interaction
 Souches client et serveur

La souche client (“Client stub”)

Procédure coté client qui reçoit l’appel en mode local
Le transforme en appel distant
En envoyant un message
Reçoit le message contenant les résultats après l'exécution
Retourne les résultats comme dans un retour de procédure.

La souche serveur (“Server stub”)

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.
Les étapes d’un appel de procédure distante par
messages
Les étapes d’un appel de procédure distante par messages
Etape 1: le client réalise un appel procédural vers la procédure souche client. La
souche client collecte les paramètres, les alignes dans le message d’appel
« Parameter Marshaling ». On parle d’assemblage, encodage de paramètres. La
souche détermine l’adresse du serveur.

Etape 2: la souche client demande à une entité de transport local la transmission du

message d’appel.

Etape 3: le message d’appel est transmis sur un réseau au site serveur.

Etape 4: le message d’appel est délivré à la souche serveur. La souche serveur

désassemble les paramètres. On parle de désassemblage ou de décodage des
paramètres

Etape 5: la souche serveur réalise l’appel effectif de la procédure serveur

 Les étapes d’un appel de procédure distante par messages

Etape 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 de retour, les assemble dans un message « Parameter Marshalling ».

Etape 7: la procédure souche serveur demande à l’entité de transport serveur la

transmission du message de réponse

Etape 8: Le message de réponse est transmis sur un réseau du site client

Etape 9: Le message de réponse est délivré à la souche client puis elle désassemble les
paramètres résultats

Etape 10: la procédure souche client transmet les résultats au client en effectuant un
retour habituel de procédure en mode Local
Avantages/inconvénients de l’appel distant réalisé par messages

Avantages
Volume de code ou de données serveur quelconque.
Applicable en univers hétérogènes moyennant des conversions.
Partage d’accès sur le site serveur analogue au transactionnel.

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.
 4- Réalisation de l’appel de procédure distante léger
(lightweight RPC)

Problème de performances : quand on invoque un serveur qui se

trouve sur la même machine la traversée des couches réseaux est inutile
et coûteuse.

Si le serveur se trouve dans le même processus (même domaine de

protection) pas de problème (appel local).

Si le serveur se trouve dans un autre processus (autre domaine de

protection)
Solution proposée : la communication réseau est réalisée par un segment de
mémoire partagée entre le client et le serveur qui contient un tas pour les paramètres
d'appel et de réponse.
4- Schéma général de l’appel de procédure distante léger
 Avantages Inconvénients: RPC léger

Avantages
Transmission d’appel très performant comme mode de RPC local.

Inconvénients
Uniquement applicable aux RPC du même site.
 Gestion du contrôle

1) Parallélisme chez le client

2) Parallélisme chez le serveur
 1-Parallélisme chez le client : Appel de
procédure distante 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.

 Une solution au problème de l’inactivité du client:
utilisation des activités

Création de (au moins) deux activités (‘ 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.
 1-Parallélisme chez le client : Appel de procédure
distante 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 (primitive spéciale).

 Récupération des résultats en mode asynchrone:
notion de futurs explicites

Un futur : une structure de donnée (un objet) permettant de récupérer des

résultats.

Notion de futur explicite

Les structures de données sont définies par le client avant l’appel (le serveur
les connaît et y dépose les résultats).

Exemple: En ACT++ une boite à lettre définie par le client sert de moyen de
communication pour les paramètres résultats.

BAL := [Link](n)
resultat := [Link]élever()
 Récupération des résultats en mode asynchrone:
notion de futurs implicites
Invocation asynchrone à futur implicite
Les structures de données de communication pour les réponses (ex boite à
lettre) sont implicitement créés par le prestataire du service d'APD
asynchrone.

Approche générale: défaut d'information (analogie défaut de page en

mémoire virtuelle).

La lecture de la structure de donnée résultat bloque le client, s'il accède à la

réponse et que celle-ci n'est pas parvenue.

L’usager ne s’aperçoit de rien (si le résultat est parvenu ou s ’il n’est pas
parvenu).
 Cas particulier du mode asynchrone:
invocation asynchrone à sens unique

Invocation asynchrone sans réponse « oneway » , « maybe »

Invocation asynchrone utilisé pour déclencher une procédure qui ne retourne pas de
résultats. Pour obtenir un dialogue il faut prévoir d’autres procédures en sens inverse.

Avantage: Utilisation d'un mode appel de procédure pour des communications sont en
fait de mode message.

Inconvénients : Uniquement possible en l'absence de retour de résultat, pas

d'informations sur la terminaison du travail demandé.

Exemples: CORBA oneway.

2- Parallélisme chez 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 premier arrivé
premier servi, on a un traitement ordonné des suites d’appels.

Exemple RPC SUN : traitement séquentiel des requêtes mais utilisation de UDP => requêtes non ordonnées
(mais mode synchrone le client attend la fin du traitement).

Autres exemples: les RPC ont un mode séquentiel (ex CORBA)

 2- Parallélisme chez le serveur: Exécution parallèle des appels

Dans ce mode le serveur créé un processus ou une activité (un processus léger ou “thread”)
par appel (gestion possible de pool de processus ou d ’activités).

Les appels sont exécutés concurremment.

Si les procédures manipulent des données globales rémanentes sur le site serveur, le contrôle
de concurrence doit être géré.

Exemple : Corba Notion d’adaptateur d’objets.

 Propriétés d’ordre dans les communications par RPC

L'appel de procédure distante peut comporter des spécifications de propriétés d'ordre.

Le respect d'une propriété d'ordre peut porter:

sur le lancement de la procédure (peut utilisable)
sur la totalité de son exécution.

Ordre local: Les exécutions pour un client sont réalisées dans l'ordre d'émission.

Ordre global: Les exécutions pour un client sont réalisées dans le même ordre sur tous les destinataires
(cas des communications de groupe).

Ordre causal: Les exécutions sont effectuées en respectant la relation de causalité qui existe entre les
requêtes.
 Problèmes posés par les RPC

1. Passage de paramètres;
2. Hétérogénéité des machines;
3. Désignation de liaison (identification et nommage);
4. Tolérance aux pannes
 1- Passage de paramètres

1- Par valeur copie de la valeur du paramètre dans la pile.

2- Par adresse (référence)copie de l’adresse de la variable paramètre dans la pile

tout changement sur la variable est directement visible.

3- Par copie/restauration: utilisé dans certains langages (inout en ada).

A l’appel, copie des valeurs des paramètres dans la pile (de l’appelant vers l’appelé).
Au retour, copie des nouvelles valeurs, après exécution de la procédure vers la variable (de
l’appellé vers l’appelant).
 Exemple 1 de passage de paramètres

Procédure double_incr (x,y:entier)

Début
x:=x+1;
y:=y+1; Résultat obtenu: a=?, b=? Avec un passage par valeur
fin; Résultat obtenu: a=?, b=? Avec passage par référence
Résultat obtenu: a=?, b=? Avec un passage par copie restauration
Programme principal
a:=0;b:=0;
double_incr (a,b);
Afficher (a,b);

Le passage par copie/restauration, peut il remplacer le passage par référence (adresse)?

 Exemple 1 de passage paramètres

Procédure double_incr(x,y: entier);

Début
x:=x+1; Résultat obtenu: a=0, b=0 Avec un passage par valeur
y:=y+1; Résultat obtenu: a=1, b=1 Avec passage par référence
fin; Résultat obtenu: a=1, b=1 Avec un passage par copie restauration

Programme principal
a:=0;b:=0;
double_incr (a,b);
Afficher (a,b);

Le passage par copie/restauration, peut être utilisé pour remplacer le passage par référence
(adresse).
 Exemple 2 de passage de paramètres

Procédure double_incr(x,y: entier);

Début
x:=x+1; Résultat obtenu: a=? Avec un passage par valeur
y:=y+1; Résultat obtenu: a=? Avec passage par référence
fin; Résultat obtenu: a=? Avec un passage par copie restauration
Programme principal
a:=0;
double_incr (a,a);
Afficher (a);
 Exemple 2 de passage de paramètres

Le passage par copie/restauration, ne donne pas le même résultat que le passage par référence
 Passage de paramètres dans les RPC

- Passage par valeur peut être utilisé;

- Passage de paramètre par référence (adresse, pointeur) est impossible;
- Passage par copie restauration, peut être utilisé pour remplacer le
passage par adresse, mais faire attention à certains cas particulier;
- Passage de structure dynamiques (tableau de taille variables, listes,
arbres, graphes, etc..)est difficile.
 2- Hétérogénéité des machines

• Convention différentes sur client et serveur

Exemple:
- Ordre de stockage des octets diffèrents (Little endian (intel), Big endian (droit à
gauche ou de gauche à droite (Sun-SPARC));

- Représentation des arguments: codes des caractères, C1 et C2, virgule flottante,

structures complexes, etc…

• Limitation de taille
Exemple: entiers sur 64 bits vs 32 bits
 2- Hétérogénéité des machines (solution)

• Codage/découpage de chaque type de données de toute

architecture à toute autre architecture.

• Format universel intermédiaire (XDR, CDR,…etc)

 3- Désignation et liaison
Désignation (Identification):
Comment sont structurés les noms et références permettant de désigner les
services distants?

- Nom symbolique: utilisable au moyen d’un serveur d’annuaire.

- Référence: une structure de données permettant de réaliser l’invocation;

Peut concernée la désignation:
Du protocole permettant l’accès distant (TCP);
De l’hôte ou se trouve le serveur (adresse IP);
Du point d’accès de service transport (numéro de port);
De l’objet ou se trouve la procédure;
De la procédure.
 3- Désignation et liaison
Liaison (Nommage):
Comment et quand le client localise t-il une procédure distante?

- Solution statique: il écrit l’adresse du serveur dans son code.

 Solution rigide (et si le serveur change d’adresse??!!)

- Nommage dynamique (Dynamic binding): solution tardive avec

utilisation d’un:
Gestionnaire de noms (annuaire): intermédiaire entre le client et
le serveur;
Portmapper: un processus Daemon s’exécutant sur le serveur.
Utilisé lorsque le serveur est connu (accès fréquents).
 3- Désignation et liaison
Utilisation d’un annuaire pour une liaison physique

- 1, 2 : le serveur s’enregistre auprès de l’annuaire avec <nom,[Link], n° port>

- 3, 4, 5 : le client consulte l’annuaire pour trouver <[Link], n° port> à partir de <nom>
- L’appel peut alors avoir lieu
- Schémas plus élaborés : attributs (critères de choix)
 3- Désignation et liaison
Utilisation d’un « Portmapper » pour une liaison dynamique
Machine tata
Client sur machine toto Programme serveur

... ...
cl=clnt_create(‘‘tata’’,... ); svc_register(adr,... );
... (6) ...

(1)
(2)
(3) (5) ... adr

adr
Port 111

Portmapper (4)
 3- Désignation et liaison
Utilisation d’un « Portmapper » pour une liaison dynamique

Le serveur s’enregistre auprès du portmapper (annuaire)

Son nom (ou numéro) de son programme
Sa version (celle du programme, il peut en avoir plusieurs)
Son adresse (adresse mémoire, IP, Numéro de port).

Le portmapper (annuaire) enregistre ces informations dans sa table de

liaisons;

Le client demande l’adresse du serveur au portmapper en lui passant le

nom, la version du serveur et le protocole de communication à utiliser
 4- Tolérance aux pannes

[Link] pertes de messages;

[Link] pannes du serveur;
[Link] pannes du client.
 4- Tolérance aux pannes: Les pertes de messages

- Cas facile: pertes traitées par une couche transport fiable.

- Cas difficile: il existe des RPC implantés pour des raisons

d’efficacité au dessus d’une communication non fiable (couche
réseau sans connexion type UDP)

Mécanisme de traitement des pertes de messages à prévoir

dans la conception du RPC.

Exemple: La réponse acquitte la demande.

La prochaine requête acquitte la réponse.
 4- Tolérance aux pannes: Les pertes de messages

Pour tolérer les pertes de messages on peut lancer plusieurs exécution

de la même requête.

A condition que :
Les exécutions répétées du code du serveur produisent des résultats
identiques, c-à-d si l’opération à réaliser est idempotente.

F est idempotente si F(F(x))= F(X)

F est idempotente si l’exécution de la procédure ne modifie pas l’état

du serveur.
 Exemple relatifs à l’idempotence

Les opérations suivantes sont elles idempotente?

• La lecture du Nième article d’un fichier. Oui
• L’écriture du Nième article dans un fichier. Oui
• L’écriture en fin de fichier. Non
• L‘incrémentation d’une variable. Non
• La mise à jour d’un compte bancaire. Non
4- Tolérance aux pannes: Les pannes du serveur

Attente indéfinie par le client.

Utilisation d’un délai de garde par le site appelant.

L’absence de réponse  client décide de la stratégie de reprise:

- Abandon du programme sur temps limite;
- Reprise arrière automatique (si possible) avec tentative d’exécution
sur un autre site ou reprise sur le même site (si relance)

A quel moment le serveur est-il tombé en panne?

 4- Tolérance aux pannes: Sémantique des RPC en
présence d’échecs du point de vue des pannes serveur

Le serveur tombe en panne après réception d’une requête:

i- Après exécution de la requête et envoi de réponse;
ii- Après exécution de la requête, avant l’envoi de la réponse;
iii- Pendant l’exécution de la requête ;

i et ii posent problème (le client comment peut il distinguer

entre les deux  3 sémantiques:
 Sémantique du RPC du point de vue des pannes serveur

Trois écoles de pensée (sémantiques):

-Sémantique une fois au moins: RPC exécuté au moins une fois. Le client réémet jusqu’à
avoir une réponse (cas des procédures idempotentes).

-Sémantique une fois au plus: RPC exécuté au plus une fois. Le client abandonne et
renvoie un message d’erreur (cas des procédures non idempotentes).

-Sémantique exactement une fois: définition théorique, une seule exécution est
effectuée et celle-ci réussit toujours. Impossible si une hypothèse de panne est formulée.
 4- Tolérance aux pannes: Les pannes du client

 Le serveur est dit orphelin: Réalisation de travaux inutiles, utilisation

de ressources qui ne sont plus accessibles.

Confusion après relance du client entre les nouvelles réponses

attendues et les réponses à l’anciennes requêtes.

Nécessité de détruire les tâches serveurs orphelines et distinguer les

requêtes utiles des vielles requêtes.
Sémantique du RPC du point de vue des pannes client

Solutions de Nelson:

1- Extermination: le client utilise un journal de trace. Lorsqu’un client est relancé, il

demande la destruction des orphelins: Solution coûteuse en espace et complexe.

2- Réincarnation: pour éviter les écritures disque, des périodes d’activité incrémentale
du client doivent être définies. Après une panne, il diffuse un message indiquant une
nouvelle période. Ses orphelins sont détruits.

3- Expiration: chaque RPC dispose d’un quantum q de temps pour s’exécuter. Il est
détruit au bout de ce quantum.
Sémantique du RPC du point de vue des pannes client

Expiration
• Surveillance périodique du client: le serveur arme des délais de
garde.
• Si le quantum s’achève, le serveur demande à son client s’il est
encore opérationnel.
• Si le client répond: armement d’un nouveau délai et poursuite.
• Si le client est en panne: abandon cohérent d’exécution.
• Prb: valeur du q?

Problème de toutes ces solutions: si l’orphelin détruit a verrouillé des

ressources??!! Orphelins d’orphelins!!!
 Conclusion
Avantages des RPC:
• S’affranchir du coté basique des communications en mode message.
• Utiliser une structure familière: l’appel de procédure.
• Dispose d’une vision modulaire des applications réparties.

Inconvénients des RPC:

• Pas d’usage des pointeurs dans les paramètres.
• Echange de données complexes/ de grande taille délicat.
• Peu efficace pour de très nombreux appels.