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
[Link]
INSAT 2009-2010
21 | A look Forward | January 2010