Systèmes et Applications Répartis

Ce document présente une étude détaillée du modèle de programmation client/serveur à travers le cas concret du Remote Procedure Call (RPC). Il s’adresse aux étudiants et professionnels en informatique souhaitant comprendre les mécanismes, les problématiques et les outils associés à la mise en œuvre des appels de procédures à distance dans des systèmes répartis.

Introduction au RPC

Le Remote Procedure Call (RPC) est une technique permettant d’appeler des procédures ou fonctions situées sur une machine distante, en masquant la complexité du protocole de communication sous-jacent. Cette abstraction offre une transparence de distribution, rendant l’appel distant similaire à un appel local.

Le RPC s’appuie sur des opérations de haut niveau, notamment :

• Côté client : do_Op(IN Port serverId, Name opName, Msg *arg, OUT Msg *result)
• Côté serveur : getRequest(OUT Port clientId, Message *callMessage) et sendReply(IN Port clientId, Message *replyMessage)

Principe de fonctionnement du RPC

Côté appelant (client)

Le client effectue un appel local vers un talon client (client stub) qui :

• Récupère et assemble les arguments dans un message (empaquetage ou marshalling).
• Génère un identificateur unique pour l’appel RPC.
• Détermine l’adresse du serveur (via ARP, DNS).
• Transmet le message au protocole de transport pour envoi sur le réseau.
• Arme un délai de garde (timeout) pour la gestion des pannes.

Côté appelé (serveur)

Le message est reçu par le talon serveur (skeleton) qui :

• Désassemble les arguments (dépaquetage ou unmarshalling).
• Enregistre l’identificateur de l’appel.
• Transmet l’appel à la procédure distante correspondante.
• Après exécution, empaquette les résultats dans un message de retour.
• Envoie ce message au client via le protocole de transport.
• Arme un délai de garde pour la réponse.

Retour côté client

Le talon client reçoit la réponse, dépaquette les résultats, désarme le délai de garde initial, et envoie un acquittement au serveur. Les résultats sont alors transmis à l’appelant comme dans un appel local.

Rôle des talons (stubs et skeletons)

• Talon client (stub) : interface locale côté client, transforme l’appel local en message distant, transmet les résultats au client.
• Talon serveur (skeleton) : côté serveur, reçoit le message, exécute la procédure serveur correspondante, renvoie les résultats.

Avantages et problèmes du RPC

Avantages

• Appel distant avec forme et effet identiques à un appel local.
• Applications non modifiées lors du passage à la distribution.
• Abstraction vis-à-vis des protocoles de communication.
• Réutilisation possible en environnement hétérogène.

Problèmes

• Sémantique complexe en cas de panne (client, serveur, réseau).
• Restrictions sur le passage de paramètres complexes.
• Gestion des défaillances et des délais de garde.
• Problèmes de sécurité (authentification, confidentialité).
• Adaptation à l’hétérogénéité des systèmes et performances.

Gestion des défaillances

La détection de panne se fait par expiration du délai de garde. Différentes sémantiques sont possibles :

• Indéfini : aucune hypothèse, comportement incertain.
• Au moins une fois : appel répété en cas d’échec, plusieurs exécutions possibles, acceptable si l’opération est idempotente.
• Au plus une fois : erreur si délai expiré, évite les doublons mais ne garantit pas le succès.
• Exactement une fois : idéal, avec réémission et élimination des doublons.

Désignation et liaison des services

Les objets à désigner sont la procédure appelée et le site serveur. L’objectif est une désignation indépendante de la localisation pour permettre la reconfiguration.

• Liaison statique : localisation connue à la compilation.
• Liaison dynamique : localisation inconnue à la compilation, utilisation de serveurs de noms ou annuaires.

Trois modes de liaison :

• Liaison statique sans serveur de noms.
• Liaison au premier appel avec consultation du serveur de noms.
• Liaison à chaque appel avec consultation répétée.

Utilisation d’un annuaire

Le serveur s’enregistre auprès de l’annuaire avec son nom, adresse et numéro de port. Le client consulte l’annuaire pour obtenir l’adresse et le port à partir du nom du service.

Service de nommage : portmapper et rpcbind

• Portmapper : service local au serveur, enregistre le numéro de port des services, écoute sur le port 111 TCP/UDP.
• RPCbind : remplace portmapper, indépendant du transport, permet l’enregistrement multi-transport et fournit des fonctions supplémentaires (horloge, statistiques).

Gestion des paramètres

Les espaces d’adressage client et serveur sont distincts, ce qui empêche le passage par référence. Les paramètres doivent être sérialisés et convertis si les machines sont hétérogènes.

Traitement de l’hétérogénéité

• Conversion nécessaire si codages ou formats internes différents (entiers, flottants, alignement).
• Solutions : syntaxe abstraite de transfert de données (ASN.1), représentation externe commune (XDR), négociation client-serveur.

Représentation de données en mémoire

• Différences entre architectures Little-endian (x86, alpha) et Big-endian (ppc, sparc).
• Représentation des flottants selon IEEE 754.
• Alignement des données dépendant du compilateur.
• Tailles variables des registres (32 ou 64 bits).

XDR – eXternal Data Representation

XDR est une représentation portable des données sur le réseau, utilisant un codage Big-endian avec des mots de 4 octets complétés par des zéros. Il définit des types de données binaires standards orientés C, tels que :

• Types fondamentaux : int, double, float, enum, struct, union, tableaux.
• rpcgen génère automatiquement les fonctions de traduction à partir d’un fichier .x.

Types XDR (exemples)

Type	Identificateur	Taille
Entier relatif	int	4 octets
Entier positif	unsigned int	4 octets
Enumération	enum	4 octets
Booléen	bool	4 octets
Entier long	hyper	8 octets
Réels simples	float	4 octets
Réels doubles	double	4 octets
Vide	void	0 octet

Les données à taille variable utilisent la notation <> ou <m> pour indiquer une taille maximale.

Passage des paramètres

• Passage par valeur : simple et sans problème.
• Passage par copie-restauration : copie des valeurs à l’appel puis copie inverse au retour.
• Passage par référence : impossible en RPC classique à cause des espaces d’adressage distincts.

Palliatifs :

• Interdire le passage par référence.
• Utiliser la copie-restauration.
• Programmer manuellement les procédures d’emballage/déballage pour structures complexes.
• Utiliser des modèles avancés comme la mémoire virtuelle répartie.

Composants d’un système RPC

• IDL (Interface Definition Language) : langage de description des données et fonctions, proche du C, indépendant des machines et langages.
• Méthode de représentation portable des données (XDR).
• Protocole d’appel : transmission des paramètres et résultats.
• Protocole de publication et recherche de services.

Langage de Description d’Interface (IDL)

L’IDL définit un contrat entre client et serveur, avec :

• Identification des procédures (nom, version).
• Définition des types des paramètres, résultats et exceptions.
• Mode de passage des paramètres (IN, OUT, IN-OUT).

Il masque les problèmes d’hétérogénéité et permet la conversion automatique des types complexes.

Mode opératoire

Le fichier de description est compilé par un générateur de talons qui produit :

• Les stubs côté client.
• Les skeletons côté serveur.
• Les définitions communes et bibliothèques.

Langage RPCL (RPC Language)

Le fichier de spécification a l’extension .x et contient :

• Définitions des constantes.
• Définitions des types (struct, typedef, union, string, opaque).
• Déclaration d’un programme RPC avec ses versions et fonctions.

Exemple de structure et union en RPCL

struct point {
  int x;
  int y;
};

union res_calcul switch(int errno) {
  case 0:
    float res;
  default:
    int error;
};

Exemple de chaînes de caractères et données opaques

• string nom<20> : chaîne de taille maximale 20.
• opaque id_client[128] : liste d’octets opaque.

Outils et mise en œuvre : ONC RPC (SUN)

ONC RPC est une solution classique sous Unix utilisant XDR pour la description et l’échange des données. L’outil principal est rpcgen qui génère :

• Les fonctions de (un)marshalling XDR.
• Les talons client et serveur.
• Un squelette serveur pour implémenter les fonctions.
• Un Makefile pour la compilation.

ONC RPC utilise un service de lookup pour la publication et la découverte des services RPC, accessible sur chaque hôte.

Identification des procédures RPC

Chaque procédure est identifiée par :

• Adresse IP de la machine hôte.
• Numéro unique de programme (32 bits).
• Numéro de version du programme.
• Numéro de procédure (commence à 1 et s’incrémente).

Exemple pratique : fichier geometrie.x

Ce fichier définit un programme RPC nommé GEOM_PROG (ID 0x20000001), avec une version GEOM_VERSION_1 (numéro 1) et trois fonctions numérotées 1, 2 et 3. Les structures coordonnees et param_inclus sont utilisées pour passer plusieurs paramètres.

Génération des fichiers avec rpcgen

$ rpcgen geometrie.x

Les fichiers générés sont :

• geometrie.h : définitions des structures et signatures.
• geometrie_xdr.c : fonctions de codage XDR.
• geometrie_clnt.c et geometrie_svc.c : talons client et serveur.
• Option -a : génère un squelette serveur geometrie_server.c.

Contenu du fichier geometrie.h (extrait)

struct point {
  int x;
  int y;
};
typedef struct point point;
bool_t xdr_point(XDR*, point*);

Pour chaque fonction, deux signatures sont générées :

• type_retour *fonction_x(type_param *, CLIENT *) : côté client.
• type_retour *fonction_x_svc(type_param *, svc_req *) : côté serveur.

Implémentation côté serveur

Les fonctions sont implémentées dans un fichier séparé ou dans le squelette serveur. Les variables de résultat sont déclarées static pour garantir leur validité après retour.

Appel côté client

Le client utilise la fonction clnt_create pour créer un identificateur de communication :

CLIENT *clnt_create(
  char *machine,
  long numero_programme,
  long numero_version,
  char *protocole);

Exemple d’appel de fonctions distantes :

• Appel des fonctions creer_rectangle_1, calculer_surface_1, inclus_1.
• Transparence totale : les appels sont identiques à des appels locaux.

Gestion des erreurs

Les fonctions retournent NULL en cas d’erreur. La fonction clnt_perror(CLIENT*, char *msg) affiche un message d’erreur.

Compilation et lancement

• Compilation des fonctions XDR : gcc -c geometrie_xdr.c
• Compilation client : gcc -c geometrie_clnt.c client.c puis gcc -o client client.o geometrie_clnt.o geometrie_xdr.o
• Compilation serveur : gcc -c geometrie_svc.c geometrie_server.c puis gcc -o serveur geometrie_svc.o geometrie_server.o geometrie_xdr.o

Le talon serveur contient un main qui enregistre automatiquement le programme comme service RPC.

Utilisation de rpcinfo

La commande rpcinfo -p machine affiche la liste des services RPC enregistrés sur une machine, avec leurs numéros de programme, versions, protocoles et ports.

Conclusions sur la programmation RPC

• La programmation traditionnelle est complexe, avec une charge importante pour le programmeur.
• Le RPC apporte une abstraction facilitant la répartition et la réutilisation.
• Des mécanismes plus évolués existent, notamment RMI (Java), CORBA, DCOM, XML-RPC, SOAP.
• Ces technologies supportent la migration de code, la sécurité et utilisent des standards comme XML et HTTPS.

Glossaire des termes clés

• RPC (Remote Procedure Call) : mécanisme d’appel de procédures distantes avec abstraction du réseau.
• Talon client (stub) : interface locale côté client qui transforme un appel local en message distant.
• Talon serveur (skeleton) : interface côté serveur qui reçoit le message, exécute la procédure et renvoie la réponse.
• Marshalling : empaquetage des arguments dans un message pour transmission.
• Unmarshalling : dépaquetage des arguments reçus pour exécution.
• Délai de garde (timeout) : période d’attente avant détection d’une panne ou d’un échec.
• IDL (Interface Definition Language) : langage de description des interfaces entre client et serveur.
• XDR (eXternal Data Representation) : norme de représentation portable des données sur le réseau.
• Portmapper : service local enregistrant les ports des services RPC.
• RPCbind : service amélioré remplaçant portmapper, indépendant du transport.
• Copie-restauration : mode de passage des paramètres où les valeurs sont copiées à l’appel puis restaurées au retour.
• Idempotence : propriété d’une opération dont l’exécution répétée a le même effet qu’une seule exécution.
• Binding : processus d’association d’un appel RPC à un serveur spécifique.
• rpcgen : outil générant automatiquement le code client/serveur et les fonctions XDR à partir d’un fichier .x.

Points clés à retenir

• Le RPC masque la complexité du réseau en offrant une interface d’appel de procédure distante transparente.
• Les talons client et serveur jouent un rôle central dans la sérialisation, la communication et l’exécution.
• La gestion des pannes et des délais de garde est essentielle pour garantir la fiabilité.
• La désignation dynamique des services via annuaires ou portmapper facilite la flexibilité et la reconfiguration.
• L’IDL et XDR assurent la portabilité et la gestion de l’hétérogénéité entre machines.
• Le passage par copie-restauration est la méthode privilégiée pour transmettre les paramètres complexes.
• Les outils comme rpcgen automatisent la génération du code nécessaire à la mise en œuvre des RPC.
• Les RPC traditionnels ont des limites, dépassées par des technologies plus avancées comme RMI, CORBA, XML-RPC et SOAP.