Remote Procedure Call (RPC) – une com­mu­ni­ca­tion efficace dans les ar­chi­tec­tures client-serveur

Le Remote Procedure Call (en français « appel de procédure à distance ») est un outil central per­met­tant de réaliser des struc­tures opé­ra­tion­nelles et basées sur la division du travail dans des réseaux et des ar­chi­tec­tures client-serveur. Vous dé­cou­vri­rez ci-après comment fonc­tionne la col­la­bo­ra­tion via RPC entre des or­di­na­teurs séparés phy­si­que­ment, à quels niveaux elle a lieu et où les concepts RPC sont utilisés aujourd’hui.

Le terme Remote Procedure Call désigne un concept dé­fi­nis­sant la com­mu­ni­ca­tion in­ter­pro­ces­sus, c’est-à-dire l’échange d’in­for­ma­tions entre les processus d’un système. En 1984, les in­for­ma­ti­ciens Andrew Birrell et Bruce Nelson ont défini le RPC comme un mécanisme synchrone « trans­fé­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 fran­chis­se­ment d’un espace d’adressage permet de lancer des processus sur un or­di­na­teur distant dans le réseau et d’intégrer des instances externes de manière opé­ra­tion­nelle dans les processus de calcul et de trai­te­ment des données. Le transfert de pa­ra­mètres et la res­ti­tu­tion d’une valeur de fonction font partie du processus de com­mu­ni­ca­tion via RPC. En pratique, il y a fré­quem­ment plusieurs appels puisque plusieurs requêtes se déroulent souvent en parallèle.

Fi­na­le­ment, le concept du RPC aspire à une har­mo­ni­sa­tion des niveaux de trai­te­ment : dans l’idéal, il ne doit y avoir aucune dif­fé­rence entre les appels de procédure pour les pro­gram­meurs et les uti­li­sa­teurs. En principe, les appels à distance doivent donc être réa­li­sables de façon tout aussi simple que des appels de procédure locaux (principe de trans­pa­rence). Dans les réseaux et les ar­chi­tec­tures client-serveur, les appels RPC sont souvent synonymes d’une com­mu­ni­ca­tion bi­di­rec­tion­nelle axée sur la demande. Ils com­plè­tent la com­mu­ni­ca­tion basée en­tiè­re­ment sur les messages qui s’appuie sur le paradigme entrée/sortie (uti­li­sa­tion des fonc­tion­na­li­tés I/O).

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 per­met­tent des ap­pli­ca­tions dis­tri­buées (Dis­tri­bu­ted Ap­pli­ca­tions), dans les­quelles dif­fé­rents or­di­na­teurs se partagent les res­sources dis­po­nibles et les tâches entrantes. Les services de Cloud computing et les systèmes bancaires et comp­tables dans le secteur du tourisme ainsi que les bases de données en font notamment partie. Parmi les autres domaines d’ap­pli­ca­tion, on compte notamment les clusters (grappes de serveurs), les réseaux pair-à-pair dé­cen­tra­li­sés ainsi que les blo­ck­chains (par exemple pour les cryp­to­mon­naies) qui utilisent également la tech­no­lo­gie RPC de manière fréquente.

Les Remote Procedure Calls sont par ailleurs es­sen­tiels pour les systèmes d’ex­ploi­ta­tion actuels. Avec ces appels, Windows peut par exemple réaliser de nom­breuses routines qui se pro­dui­sent de façon ré­cur­rente. Les services de fax, les files d’attente d’im­pres­sion ou les con­nexions 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 Mi­cro­sys­tems, joue un rôle essentiel. Il utilise des appels RPC entre les clients et les serveurs afin, par exemple, de monter par­tiel­le­ment ou to­ta­le­ment le système de fichiers d’un or­di­na­teur à distance sur un or­di­na­teur local afin de le rendre dis­po­nible. À travers cette procédure, l’uti­li­sa­teur peut accéder aux dif­fé­rents fichiers d’un or­di­na­teur à distance comme s’ils se trou­vaient sur son propre or­di­na­teur. Les au­to­ri­sa­tions de fichiers définies règlent ensuite les droits de lecture et d’écriture. Le Network In­for­ma­tion System (NIS) utilise RPC et gère ainsi les systèmes UNIX et Linux de façon cen­tra­li­sée.

Le protocole RPC traite la com­mu­ni­ca­tion in­ter­pro­ces­sus de façon fiable et nécessite des temps de trai­te­ment re­la­ti­ve­ment faibles. La pro­gram­ma­tion des processus de com­mu­ni­ca­tion d’or­di­na­teurs à distance phy­si­que­ment est con­si­dé­ra­ble­ment sim­pli­fiée, notamment parce qu’il n’est pas né­ces­saire de tenir compte des détails complexes du réseau utilisé. Par ailleurs, le concept RPC permet une mo­du­la­ri­sa­tion con­si­dé­rable. Les processus peuvent ainsi être dé­lo­ca­li­sés ce qui permet de soulager les dif­fé­rents or­di­na­teurs. Les réseaux et les systèmes dis­tri­bués peuvent tra­vail­ler de façon plus efficace grâce à la division du travail en utilisant des pla­te­formes spé­cia­li­sées pour les tâches spé­ci­fiques (par exemple des serveurs de base de données). Les pro­ta­go­nistes peuvent ainsi être connectés dans le monde entier. L’in­croyable évo­lu­ti­vité des ar­chi­tec­tures client-serveur réalisées ainsi que la pos­si­bi­lité de tra­vail­ler sans dif­fi­culté depuis le Cloud cons­ti­tuent d’autres avantages.

Parmi les in­con­vé­nients de la tech­no­lo­gie RPC, on compte le fait qu’il n’existe aucun standard uniforme pour les appels RPC. En temps normal, les dif­fé­rentes réa­li­sa­tions – gé­né­ra­le­ment spé­ci­fiques à une en­tre­prise (par ex. ONC-RPC de Sun) – ne sont pas com­pa­tibles entre elles. D’autre part, les niveaux de transfert et de trans­mis­sion 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 en­vi­ron­ne­ments d’exécution dif­fé­rents pour leurs routines res­pec­tives, l’uti­li­sa­tion des res­sources (par ex. des fichiers) est plus complexe. Les systèmes RPC ne sont par con­sé­quent pas très adaptés à la trans­mis­sion de grands volumes de données.

La ré­par­ti­tion sur dif­fé­rentes instances de trai­te­ment augmente la pro­ba­bi­lité d’une erreur. Les messages peuvent être perdus dans la com­mu­ni­ca­tion (erreur réseau, panne d’un nœud dans le réseau) ce qui peut entraîner des retards et des in­ter­rup­tions. Les problèmes de délai, les exé­cu­tions re­don­dantes (par ex. d’appels de procédure) ou les asyn­chro­nies non désirées dans la com­mu­ni­ca­tion entre machines font partie des com­pli­ca­tions 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 pro­pen­sion à l’erreur peut avoir des con­sé­quences con­si­dé­rables, en par­ti­cu­lier dans des ar­chi­tec­tures avec une division du travail complète ou im­por­tante.

Les sources d’erreur possibles im­pli­quent par ailleurs de tenir compte d’une sé­man­tique des erreurs RPC spé­ci­fique, ce qui complique encore la pro­gram­ma­tion. Les pro­gram­meurs et les dé­ve­lop­peurs de systèmes doivent se pencher sur les aspects de sécurité qu’im­pli­quent les systèmes dis­tri­bués et leur com­mu­ni­ca­tion via RPC et UDP/IP ou TCP/IP (sécurité réseau, piratage, attaques par déni de service etc.).