Applications Réparties

Remote Procedure Call

Atef Ben Ismail

INSAT 2009-2010
Appel de procédure à distance : 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

Processus P
Processus P

P (x,y, …)

Procedure P (x,y, …)
P (x,y, …)

L’effet de l’appel doit être identique dans les deux situations. Mais cet objectif ne peut
être atteint en toute rigueur en présence de défaillances.

2 Application Réparties INSAT 2010

RPC: avantages

Facilité de programmation
• La complexité des protocolesde communication est cachée

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’utilisation d’un langage de haut niveau
• Indépendance par rapport au système de communication

3 Application Réparties INSAT 2010

RPC: problèmes

Transmission des paramètres (conversion entre la forme interne, propre à un

langage, et une forme adaptée à la transmission)

Gestion des processus

Réaction aux défaillances

• Trois modes de défaillance indépendants : client, serveur, réseau

4 Application Réparties INSAT 2010

 RPC: mise en oeuvre

Talon/Souche Talon/Souche
(Stub) Client (Stub) Serveur

Les talons client et serveur sont créés à partir d’une description d’interface (IDL)

5 Application Réparties INSAT 2010

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")....

6 Application Réparties INSAT 2010

 RPC: rôles des talons

Talon client - stub Talon Serveur- skeleton

procédure d’interface sur le site client
procédure d’interface sur le site client
• reçoit l’appel en mode local, • reçoit l’appel sous forme de message,
• "emballe" les paramètres et le • " déballe" les paramètres d'appel,
transforme en appel distant en envoyant
• fait réaliser l’exécution sur le site
un message,
serveur par la procédure de service
• attend les résultats en provenance du invoquée,
serveur,
• "emballe" les paramètres résultats et les
• "déballe" les paramètres résultats, et les retransmet par message.
retourne au programme client "comme”
dans un retour de procédure local.

7 Application Réparties INSAT 2010

RPC: étape d’appel

8 Application Réparties INSAT 2010

Langages de description d'interfaces (IDL)

Motivations
• Spécification commune au client et au serveur
• contrat entre le client et le serveur
• Définition du type et de la nature des paramètres (IN, OUT, IN-OUT)
• Indépendance des langages de programmation

Principes directeurs
• Langage déclaratif
• Outils de génération des talons (stub et skeleton)

9 Application Réparties INSAT 2010

IDL: chaîne de compilation

10 Application Réparties INSAT 2010

Chaîne de production pour l’appel de procédure à distance

11 Application Réparties INSAT 2010

RPC: Quelques problèmes de mise en œuvre

La réalisation de l’appel de procédure à distance soulève divers problèmes

techniques:

Passage de paramètres

Désigantion

Gestion de l'Hétérogénéité

Traitement des défaillances

12 Application Réparties INSAT 2010

Passage de paramètres

Passage de paramètres par référence impossible

• Passage par valeur
• Passage par copie/restauration

Passage de structures dynamiques (tableaux de taille variable, listes, arbres,
graphes, etc.)

Hétérogénéité des machines

• Byte-ordering : ordre de stockage des octets différent (little endian (Intel), big endian
(Sun-SPARC))
• Représentation des arguments : codes des caractères, C1 et C2, virgule flottante, etc.

13 Application Réparties INSAT 2010

Désignation

Problèmes: Comment le client détermine l’adresse du serveur (et vice-versa)

Mise en œuvre : statique ou dynamique

• statique : localisation du serveur connue à la compilation
• dynamique : localisation déterminée à l'exécution (au premier appel)
– séparer connaissance du nom du service de la sélection de la procédure qui va
l ’exécuter
– permettre l’implémentation retardée

14 Application Réparties INSAT 2010

Gestion de l'Hétérogénéité

Problème : représentation des données

• Conversion nécessaire si le site client et le site serveur
– n ’utilisent pas le même système de codage (big endian versus little endian)
– utilisent des formats internes différents (pour les types de base :caractère,
entier, flottant, …)

Solutions
• Syntaxe abstraite de transfert ASN 1
• Représentation externe commune : XDR Sun (non optimal si même représentation)
• Représentation locale pour le client et conversion par le serveur
• Choix d'une représentation parmi n (standard), conversion par le serveur
• Négociation client serveur

15 Application Réparties INSAT 2010

Traitement des défaillances

Difficultés du traitement des défaillances
• Le client n’a pas reçu de réponse au bout d’un délai de garde fixé. 3 possibilités :
a) Le message d’appel s’est perdu sur le réseau
b) L’appel a été exécuté, mais le message de réponse s’est perdu
c) Le serveur a eu une défaillance
– c1: Avant d’avoir exécuté la procédure
– c2 : Après avoir exécuté la procédure mais avant d’avoir envoyé la réponse

• Si le client envoie de nouveau la requête

– Pas de problème dans le cas a)
– L’appel sera exécuté 2 fois dans le cas b)
– Remède : associer un numéro unique à chaque requête
– Divers résultats possibles dans le cas c) selon remise en route du serveur

Conséquences pratiques sur la conception des applications
• Construire des serveurs “sans état” (donc toute requête doit être self-contenue, sans
référence à un “état” mémorisé par le serveur)
• Prévoir des appels idempotents (2 appels successifs ont le même effet qu’un appel
unique). Exemple : déplacer un objet
– move(deplacement_relatif) : non idempotent
– move_to(position absolue) : idempotent
16 Application Réparties INSAT 2010
Méthodologie de développement

Ecrire le contrat toto.x dans le langage RPCL

Compiler le contrat avec RPCGEN

• toto.h : déclarations des constantes et types utilisés dans le code généré pour le client
et le serveur
• toto_xdr.c : procédures XDR utilisés par le client et le serveur pour encoder/décoder
les arguments,
• toto_clnt.c : procédure stub côté client
• toto_svc.c : procédure stub côté serveur

Ecrire le client (client.c) et le serveur (serveur.c)
• Serveur.c : implémentation de l’ensemble des procédures

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

Exécution
• rsh «host» Serveur
• Client «host» «liste d’arguments»
17 Application Réparties INSAT 2010
Méthodologie Synthèse

18 Application Réparties INSAT 2010

RPC traditionnelle: implémentation

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.

19 Application Réparties INSAT 2010

Conclusions sur l’appel de procédure à distance (RPC)

Avantages
• Abstraction (les détails de la communication sont cachés)
• Intégration dans un langage : facilite portabilité, mise au point
• Outils de génération, facilitent la mise en oeuvre

Limitations
• La structure de l’application est statique : pas de création dynamique de serveur, pas
de possibilité de redéploiement entre sites
• Pas de passage des paramètres par référence
• La communication est réduite à un schéma synchrone
• La persistance des données n’est pas assurée (il faut la réaliser explicitement par
sauvegarde des données dans des fichiers)
• Des mécanismes plus évolués visent à remédier à ces limitations
– Objets répartis (ex : Java RMI, CORBA) pour les 2 premières
– Bus à messages (Message Oriented Middleware)
– Composants répartis (ex : EJB, Corba CCM, .Net)

20 Application Réparties INSAT 2010

www.alcatel-lucent.com
INSAT 2009-2010

21 | A look Forward | January 2010