Le document traite des appels de procédure à distance (RPC), une méthode permettant la communication entre applications client-serveur. Il aborde les différents modes d'implémentation du RPC, tels que par messages, en mémoire partagée ou via des protocols légers, ainsi que les défis associés tels que la gestion des paramètres et des défaillances. Le document décrit également les avantages et inconvénients de chaque approche, et souligne l'importance de la portabilité et de la gestion des données dans les architectures distribuées.

1. LES APPELS DE
PROCÉDURE
DISTANTS
heithem.abbes@gmail.com

2. Rappel du schéma client-
serveur2
 Appel synchrone Requête-Réponse
 Mise en œuvre
 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

3. Définition
3
 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)

4. Avantages attendus
4
 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

5. Problèmes de réalisation
5
 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

6. Mise en œuvre
6
 Par migration
 Par mémoire partagée
 Par messages
 Par appel léger (LRPC)
1
2
3
4

7. Réalisation par migration
7
 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.
1

8. Réalisation en mémoire partagée
répartie
8
 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

9. 9
 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 la cohérence de la
mémoire répartie
Réalisation en mémoire partagée
répartie
2

10. Réalisation par messages
10
 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.
3

11. Notion des souches (1/2)
11
 Un mode de réalisation par interception
 Une procédure intercepteur 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
3

12. Notion des souches (2/2)
12
 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

13. Etapes de RPC par messages
(1/2)14
 É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
3
 Étape 4 : Le message d’appel est
délivré à la souche qui déballe les
paramètres
 Étape 5 : La souche serveur
réalise l’appel effectif de la
procédure serveur

14. Etapes de RPC par messages
(2/2)15
 É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.
3
 É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.

15. Diagramme de RPC par
messages16
Talon
(stub)
client
Talon
(stub)
serveur
Les talons (ou souches) client et serveur sont créés
(générés automatiquement) à partir d’une description
d’interface
3

16. Description d’interface
17
 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
3

17. RPC par message
18
 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
3

18. Lightweight RPC (LRPC)
19
 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
4

19. Lightweight RPC (LRPC)
20
4
 Avantages
 Transmission d’appel très performant comme mode de RPC
local
 Limites
 Uniquement applicable dans une même machine.

20. Synthèse sur les modes de
réalisation21
 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

21. Transmission des
arguments
22

22. Transmission par valeur
23
 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

23. Transmission par valeur
dans l’appel de procédure distante
24
 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)

24. Pourquoi les langages IDL ?
25
 Ê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

25. Génération des souches
26
Source code
client
Source code
serveur
Définition de l’interface
en IDL
Compilateur IDL
Souche client Entête Souche serveur
Compilateur
(C, java, ..)
Compilateur
(C, java,..)
Binaire
client
Binaire
serveur
Compilateur
(C, java, ..)
Compilateur
(C, java,..)
Binaire souche
client
Binaire souche
serveur

26. Exemples d’IDL
et de format de présentation en RPC
27
 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

27. Autres modes de transmission :
passage par adresse
28
 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

28. Simulation par copie restauration
29
 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

29. Simulation par copie restauration
30
 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

30. Désignation et liaison31

31. Désignation
32
 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

32. Liaison
33
 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

33. Désignation & liaison
34

34. Désignation & liaison
35
 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

35. Gestion du contrôle36

36. Contrôle client : RPC en mode synchrone
37
 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.

37. Contrôle client : RPC en mode synchrone
38
 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.

38. Contrôle client : RPC en mode asynchrone
39
 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

39. Contrôle serveur : exécution séquentielle des
appels
40
 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.

40. Contrôle serveur: exécution parallèle des
appels
41
 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é.

41. Gestion des données42

42. Gestion des données applicatives
sans données partagées persistantes
43
 L’appel de procédure s’exécute en fonction des
paramètres d’entrée en produisant des
paramètres résultats
 Données locales à la procédure
 Pas de modification de données persistantes sur le
serveur
 Situation très favorable, on n’a pas à gérer:
 la tolérance aux pannes
 le contrôle de concurrence

43. Gestion des données applicatives
partagées persistantes
44
 Les exécutions successives manipulent des
données persistantes sur le serveur:
 Une exécution modifie le contexte sur le serveur
 Exemple: un serveur de fichier, de bases de données.
 Problème de contrôle de concurrence
 Problème des pannes en cours
d’exécution

44. Gestion des données protocolaires
mode avec ou sans état
45
 La terminologie avec ou sans état porte sur
l’existence ou non d’un descriptif pour chaque
relation client serveur au niveau du serveur.
 Notion d’état : un ensemble de données
persistantes au niveau du protocole pour
chaque relation client serveur :
 Permettrait de traiter les requêtes dans l’ordre
d’émission.
 Permettrait de traiter une requête en fonction des
caractéristiques de la relation client serveur
(qualité de service).

45. Mode sans état
46
 Les appels successifs d’une même procédure
s’exécutent sans liens entre eux
 Chaque opération du point de vue du
protocole s’effectue sans référence au passé
 Exemples
 NFS "Network File System" de SUN
 système de fichier réparti basé sur RPC sans état
 HTTP "HyperText Transfer Protocol"
 protocole d’exécution de méthodes distantes sans état

46. Mode avec état
47
 Les appels successifs s’exécutent en fonction
d’un état de la relation client serveur laissé par
les appels antérieurs
 La gestion de l'ordre des requêtes est
indispensable
 Exemple :
 Opérations d’achat des produits sur Internet
(payement électronique)

47. Tolérance aux pannes48

48. Appel local vs Appel distant
49
En appel local
 L’appelant et l’appelé s’exécutent sur la même machine : même
exécutant => mêmes performances et modes de pannes.
 L’appel et le retour de procédure sont des mécanismes internes
considérés comme fiables.
 Problème des erreurs abordé => exceptions chez l’appelant.
En appel distant
 Appelant et appelé peuvent tomber en panne indépendamment
 Le message d’appel ou celui de retour peuvent être perdus
 Le temps de réponse peut-être très long en raison de surcharges
diverses (réseau, site appelé)
 La prise en compte des défaillances nécessite de formuler des
hypothèses de défaillances, de détecter les défaillances, et
enfin de réagir à cette détection.

49. Hypothèses de défaillances
50
 Système de communication
 Congestion du réseau, messages retardés
 Perte de messages
 Altération de messages
 Serveur
 Défaillance avant l’exécution de la procédure
 Défaillance pendant l’exécution de la procédure
 Défaillance après l’exécution de la procédure
 Défaillance définitive ou reprise possible
 Client
 Défaillance pendant le traitement de la requête

50. Détection de pannes – Délai de
garde51
 Les mécanismes de détection de pannes reposent sur des
délais de garde.
 À l'envoi d'un message,
 une horloge de garde est armée, avec une valeur estimée de la
borne supérieure du délai de réception de la réponse.
 Le dépassement du délai de garde déclenche une action de
reprise
 Les horloges de garde sont placées côté client, à l'envoi du
message d'appel, et côté serveur, à l'envoi du message
de réponse.
 Dans les deux cas, l'action de reprise consiste à renvoyer le
message.
 Ilest difficile d'estimer les délais de garde : un message
d'appel peut être renvoyé alors que l'appel a déjà eu lieu, et
la procédure peut ainsi être exécutée plusieurs fois!

51. RPC : sémantique en cas de
panne52
 Détection de panne = expiration de délai de garde.
 On tente de ré-exécuter l’appel. Combien de fois la
procédure a-t-elle été exécutée!?
 Sémantique : nombre d’exécution de la
procédure
 dépend des hypothèses de pannes et du mécanisme de
reprise
 Indéfini (pas d’hypothèses)
 Au moins une fois (appel répété, plusieurs exécutions
possibles, au moins une réussit)
 acceptable si opération idempotente (2 appels successifs ont le
même effet que 1 appel)
 Au plus une fois (0 ou 1 fois)
 on évite les exécutions répétées, mais on ne garantit pas le
succès

52. Traitement des défaillances
53
Congestion du réseau ou du serveur
 Panne transitoire (ne nécessite pas d’action de reprise)
 Détection : expiration du délai de garde coté client ou coté
serveur
 Reprise (délai de garde du client)
 La souche client réémet l’appel (avec le même identificateur)
sans intervention de l’application
 Le service d’exécution détecte que c’est une réémission
 Exécution de l’appel en cours : le nouvel appel du client n’a aucun
effet
 Retour déjà effectué : réémission du résultat
 Reprise (délai de garde du serveur) : réémission du
résultat
 Sémantique
 Si défaillance transitoire : exactement une fois
 Si défaillance permanente : détection, exception vers application

53. Traitement des défaillances
54
Panne du serveur après émission de l’appel
 3 cas possibles sur l’exécution de l’appel
 Traitement : pas fait, partiel, total
 Détection : expiration du délai de garde du client
 Reprise
 Le client réémet l’appel dès que le serveur redémarre
 Sémantique : au moins une fois
 Le client ne connaît pas l’endroit de la panne
 Solution : le serveur mémorise l’identificateur de
requête et état avant exécution

54. Traitement des défaillances
55
Panne du client après émission de l’appel
 L’appel est correctement traité par le serveur
 Le processus exécutant courant est déclaré orphelin
 Détection : expiration du délai de garde du serveur,
après n réémissions infructueuses
 Action du serveur : élimination des orphelins pour libérer
ses ressources
 Reprise (après redémarrage du client)
 L’application cliente réémet l’appel (avec identifiant
différent)
 Sémantique : au moins une fois
 Le serveur ne peut pas détecter qu’il s’agit d’une répétition
 Pas d ’incidence si idempotent
 Sinon, le client doit informer le serveur pour qu’il revient à l’état
cohérent avant exécution de son nouvel appel

55. Conclusion56

56. Avantages des RPC
57
 De plus haut niveau
 Les détails de communication sont cachés.
 Une structure de contrôle bien connue, l’appel
de procédure
 Support naturel de l’approche client-serveur
 Qui s’intègre à l’univers réparti des concepts
modernes de génie logiciel: approche objets,
approches composants
 Modularité, encapsulation, réutilisation par délégation.

57. 67

58. 68

59. Sémantique des pannes
69
 La sémantique d’appel caractérise combien de fois
la procédure appelée à distance est exécutée suite
à un appel en l’absence ou en présence de
défaillances.
 La sémantique est variable selon la nature du
mécanisme mis en œuvre et la nature du serveur:
 Serveur avec état: le serveur conserve des informations
sur les appels des clients
 Serveur sans état: gestion des pannes à la charge du
client
 Remarque [Idempotence]: une procédure est
idempotente si quel que soit le nombre d’exécutions,
elle délivre le même résultat
 Lecture de fichiers et une opération idempotente
 L’incrémentation d’une variable est non idempotente

60. Sémantique exactement une fois
70
 Une seule exécution est effectuée et celle-ci réussit
toujours.
 Réémettre requêtes/réponses
 Client:
 Arme un délai. Après expiration du délai, le client réémet
sa requête jusqu’à réception d’une réponse
 Au bout d’un nombre de tentatives, le serveur est
considéré indisponible
 Serveur:
 Garde en mémoire id_req, résultat (pour la perte d’une
réponse)
 Pour chaque requête id_req, réémettre résultat
 Reprise du serveur: la requête ne doit pas être
réexécutée: conserver un journal des requêtes traitées.
 Difficile à implémenter en pratique!

61. Sémantique au plus une fois
71
 Cas d'une fonction non idempotente: on ne doit pas
l'exécuter deux fois.
 Solution très répandue: Identification des requêtes +
exécution effectuée une seule fois.
 Exécution effectuée une seule fois:
 Si tout va bien le résultat est retourné à l’utilisateur
 Si un problème est détecté il est signalé à l’utilisateur.
Laisser à la charge du client.
 Aucune tentative de reprise n’est effectuée. Elle est
laissée entièrement à la charge du client.

62. Sémantique au moins une fois
72
 Ne convient pas aux procédures non
idempotentes
 Client:
 Arme un délai. Après expiration du délai, le client
réémet sa requête jusqu’à réception d’une
réponse
 Au bout d’un nombre de tentatives, le serveur est
déclaré indisponible.