Remote Procedure Call (RPC) – une communication efficace dans les architectures client-serveur
L'équipe éditoriale IONOS9 mins
Le Remote Procedure Call (en français « appel de procédure à distance ») est un outil central permettant de réaliser des structures opérationnelles et basées sur la division du travail dans des réseaux et des architectures client-serveur. Vous découvrirez ci-après comment fonctionne la collaboration via RPC entre des ordinateurs séparés physiquement, à quels niveaux elle a lieu et où les concepts RPC sont utilisés aujourd’hui.
Qu’est-ce qu’un Remote Procedure Call (RPC) ?
Le terme Remote Procedure Call désigne un concept définissant la communication interprocessus, c’est-à-dire l’échange d’informations entre les processus d’un système. En 1984, les informaticiens Andrew Birrell et Bruce Nelson ont défini le RPC comme un mécanisme synchrone « transférant le flux de contrôle et les données sous la forme d’un appel de procédure entre deux espaces d’adressage via un réseau à bande étroite ». Le franchissement d’un espace d’adressage permet de lancer des processus sur un ordinateur distant dans le réseau et d’intégrer des instances externes de manière opérationnelle dans les processus de calcul et de traitement des données. Le transfert de paramètres et la restitution d’une valeur de fonction font partie du processus de communication via RPC. En pratique, il y a fréquemment plusieurs appels puisque plusieurs requêtes se déroulent souvent en parallèle.
Finalement, le concept du RPC aspire à une harmonisation des niveaux de traitement : dans l’idéal, il ne doit y avoir aucune différence entre les appels de procédure pour les programmeurs et les utilisateurs. En principe, les appels à distance doivent donc être réalisables de façon tout aussi simple que des appels de procédure locaux (principe de transparence). Dans les réseaux et les architectures client-serveur, les appels RPC sont souvent synonymes d’une communication bidirectionnelle axée sur la demande. Ils complètent la communication basée entièrement sur les messages qui s’appuie sur le paradigme entrée/sortie (utilisation des fonctionnalités I/O).
Le domaine spécifique des appels RPC est la communication entre différents ordinateurs, mais ils peuvent également contribuer à la communication entre différents processus au sein d’un système interdépendant.
Stub client et stub serveur – fonctionnement du RPC
Les appels RPC se déroulent toujours selon un modèle défini : un client contacte par exemple un serveur de base de données central lors de la recherche d’une pièce de rechange. Le serveur situé à distance vérifie ensuite les données disponibles et envoie le résultat au client. Ce dernier traite les données obtenues et affiche par exemple une liste des données disponibles dans le logiciel de gestion.
Des instances spécifiques appelées « stubs » participent à l’implémentation d’un Remote Procedure Call côté expéditeur et destinataire. Côté client, le stub client vient remplacer la procédure du serveur à distance. Côté serveur, le stub serveur remplace le code client appelant. Les stubs simulent une unité locale fonctionnelle d’un point de vue opérationnel en dissimulant l’« éloignement » du code à l’autre côté. Par ailleurs, ils fonctionnent comme des interfaces pour la procédure. Le déroulement habituel d’un appel RPC est caractérisé par les étapes suivantes :
- le code client appelle une procédure stub (stub client local).
- À partir des paramètres transmis par l’appel de procédure, le stub client génère un message prêt à l’envoi suivant le protocole RPC. Une sérialisation a lieu lors du transfert pendant laquelle les données structurées sont transférées sous une forme séquentielle. Ce processus de traduction est également appelé marshalling (de l’anglais « to marshal », ce qui signifie en français « lister », « trier »).
- Le stub client contacte ensuite le système de communication de l’ordinateur local qui utilise TCP/IP ou UDP/IP pour l’échange de messages qui se déroule ensuite entre le client et le serveur.
- Une fois le message envoyé parvenu au destinataire, le stub serveur exécute un demarshalling ou unmarshalling, en décompressant les paramètres contenus dans le message (sur la base du protocole RPC).
- Le stub serveur transmet les paramètres décodés et assure ainsi l’appel local d’une procédure de serveur.
- La valeur de fonction qui en résulte est communiquée au stub serveur.
- Le processus est alors exécuté dans le sens inverse : génération d’un message prêt à l’envoi conformément au protocole RPC, échange de messages entre le serveur et le client, puis transport de la valeur de retour au code client en attente. L’application est poursuivie sur l’ordinateur d’origine.
Cloud computing et clusters : domaines d’application des appels RPC
Les appels RPC sont aujourd’hui utilisés dans de nombreux secteurs. Ils servent d’éléments de base pour les services Web (par exemple sous la forme du protocole XML-RPC pour des appels de fonction à distance via HTTP) et permettent des applications distribuées (Distributed Applications), dans lesquelles différents ordinateurs se partagent les ressources disponibles et les tâches entrantes. Les services de Cloud computing et les systèmes bancaires et comptables dans le secteur du tourisme ainsi que les bases de données en font notamment partie. Parmi les autres domaines d’application, on compte notamment les clusters (grappes de serveurs), les réseaux pair-à-pair décentralisés ainsi que les blockchains (par exemple pour les cryptomonnaies) qui utilisent également la technologie RPC de manière fréquente.
Les Remote Procedure Calls sont par ailleurs essentiels pour les systèmes d’exploitation actuels. Avec ces appels, Windows peut par exemple réaliser de nombreuses routines qui se produisent de façon récurrente. Les services de fax, les files d’attente d’impression ou les connexions réseau établies utilisent par exemple un service de système intitulé « appel de procédure à distance » dans les versions françaises de ces systèmes.
Dans les univers Unix et Linux, le Network File System (NFS), développé par Sun Microsystems, joue un rôle essentiel. Il utilise des appels RPC entre les clients et les serveurs afin, par exemple, de monter partiellement ou totalement le système de fichiers d’un ordinateur à distance sur un ordinateur local afin de le rendre disponible. À travers cette procédure, l’utilisateur peut accéder aux différents fichiers d’un ordinateur à distance comme s’ils se trouvaient sur son propre ordinateur. Les autorisations de fichiers définies règlent ensuite les droits de lecture et d’écriture. Le Network Information System (NIS) utilise RPC et gère ainsi les systèmes UNIX et Linux de façon centralisée.
Quels sont les avantages du RPC ?
Le protocole RPC traite la communication interprocessus de façon fiable et nécessite des temps de traitement relativement faibles. La programmation des processus de communication d’ordinateurs à distance physiquement est considérablement simplifiée, notamment parce qu’il n’est pas nécessaire de tenir compte des détails complexes du réseau utilisé. Par ailleurs, le concept RPC permet une modularisation considérable. Les processus peuvent ainsi être délocalisés ce qui permet de soulager les différents ordinateurs. Les réseaux et les systèmes distribués peuvent travailler de façon plus efficace grâce à la division du travail en utilisant des plateformes spécialisées pour les tâches spécifiques (par exemple des serveurs de base de données). Les protagonistes peuvent ainsi être connectés dans le monde entier. L’incroyable évolutivité des architectures client-serveur réalisées ainsi que la possibilité de travailler sans difficulté depuis le Cloud constituent d’autres avantages.
Quels sont les inconvénients du RPC ?
Parmi les inconvénients de la technologie RPC, on compte le fait qu’il n’existe aucun standard uniforme pour les appels RPC. En temps normal, les différentes réalisations – généralement spécifiques à une entreprise (par ex. ONC-RPC de Sun) – ne sont pas compatibles entre elles. D’autre part, les niveaux de transfert et de transmission des systèmes basés sur le RPC induisent des pertes de vitesse, ce qui n’est pas le cas avec les appels de procédure purement locaux. Le client et le serveur utilisant des environnements d’exécution différents pour leurs routines respectives, l’utilisation des ressources (par ex. des fichiers) est plus complexe. Les systèmes RPC ne sont par conséquent pas très adaptés à la transmission de grands volumes de données.
La répartition sur différentes instances de traitement augmente la probabilité d’une erreur. Les messages peuvent être perdus dans la communication (erreur réseau, panne d’un nœud dans le réseau) ce qui peut entraîner des retards et des interruptions. Les problèmes de délai, les exécutions redondantes (par ex. d’appels de procédure) ou les asynchronies non désirées dans la communication entre machines font partie des complications pouvant en résulter. En cas de RPC synchrone, un problème de serveur (par ex. un crash) peut impacter le client lorsque le processus appelant attend en vain la valeur de retour. D’autre part, le serveur est également freiné lorsque la réponse du client est retardée ou ne lui parvient pas du tout. Cette propension à l’erreur peut avoir des conséquences considérables, en particulier dans des architectures avec une division du travail complète ou importante.
Les sources d’erreur possibles impliquent par ailleurs de tenir compte d’une sémantique des erreurs RPC spécifique, ce qui complique encore la programmation. Les programmeurs et les développeurs de systèmes doivent se pencher sur les aspects de sécurité qu’impliquent les systèmes distribués et leur communication via RPC et UDP/IP ou TCP/IP (sécurité réseau, piratage, attaques par déni de service etc.).
Certains problèmes résultant d’une synchronie générale du client et du serveur peuvent être résolus avec des concepts RPC asynchrones. Dans cette procédure, le client ne doit pas nécessairement attendre une réponse du serveur. Il peut en effet poursuivre le flux du programme et exécuter d’autres opérations après un appel. La réponse du serveur est alors traitée à un moment ultérieur par le client. La programmation spéciale des appels RPC asynchrones est toutefois très complexe et laborieuse.
