RPC

Applications RépartiesRemote Procedure CallRemote Procedure Call

INSAT 2009-2010

Atef Ben Ismail

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

P (x,y, …)

Processus P

2 Application Réparties INSAT 2010

ProcedureP (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.

� 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

RPC: avantages

• Indépendance par rapport au système de communication


� 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

RPC: problèmes


RPC: mise en oeuvre

Talon/Souche (Stub) Client

Talon/Souche (Stub) Serveur


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

� 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

Notion de souches

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


Talon client - stub

� procédure d’interface sur le site client

• reçoit l’appel en mode local,

• "emballe" les paramètres et le transforme en appel distant en envoyantun message,

RPC: rôles des talons

Talon Serveur- skeleton

� procédure d’interface sur le site client

• reçoit l’appel sous forme de message,

• " déballe" les paramètres d'appel,

• fait réaliser l’exécution sur le site serveur par la procédure de service

• attend les résultats en provenance du serveur,

• "déballe" les paramètres résultats, et les retourne au programme client "comme” dans un retour de procédure local.


serveur par la procédure de service invoquée,

• "emballe" les paramètres résultats et les retransmet par message.

RPC: étape d’appel


� 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

Langages de description d'interfaces (IDL)

• Langage déclaratif

• Outils de génération des talons (stub et skeleton)


IDL: chaîne de compilation


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


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

RPC: Quelques problèmes de mise en œuvre

� Traitement des défaillances


� 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

Passage de paramètres

• 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.


� 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

Désignation


� 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

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

• 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


� 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)

Traitement des défaillances

– 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


� 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

Méthodologie de développement

• 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»


Méthodologie Synthèse


� 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.

RPC traditionnelle: implémentation


� 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

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

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)


www.alcatel-lucent.comINSAT 2009-2010

21 | A look Forward | January 2010

INSAT 2009-2010

Documents

RPC