Protocole Rpc. Le mécanisme d'appel de procédure à distance est RPC. Remplissez le champ titre

Appel de procédure à distance - RPC Le concept d'appel de procédure à distance - RPC est d'étendre le mécanisme bien connu et bien compris pour transférer le contrôle et les données au sein d'un programme fonctionnant sur une seule machine pour transférer le contrôle et les données sur un réseau. Les fonctions RPC sont conçues pour faciliter le calcul distribué.Le RPC est plus efficace dans les applications où il existe une communication interactive entre des composants distants avec des temps de réponse rapides et un transfert de données relativement faible.

Ces applications sont appelées orientées RPC. Les caractéristiques d'un appel de procédure locale sont l'asymétrie, c'est-à-dire que l'une des parties en interaction lance la synchronisation, c'est-à-dire que l'exécution de la procédure d'appel s'arrête lorsque la demande est émise et ne reprend qu'après le retour de la procédure appelée. La mise en œuvre des appels à distance est beaucoup plus complexe que celle des appels de procédure locale.

Pour commencer, comme l'appelant et la procédure appelée sont exécutés sur des machines différentes, ils ont des espaces d'adressage différents, ce qui crée des problèmes lors de la transmission des paramètres et des résultats, en particulier si les machines ne sont pas identiques. Comme RPC ne peut pas s'appuyer sur la mémoire partagée, cela signifie que les paramètres RPC ne doivent pas contenir de pointeurs vers des emplacements de mémoire non-pile et que les valeurs des paramètres doivent être copiées d'un ordinateur à un autre.

La différence suivante entre RPC et un appel local est qu'il utilise nécessairement le système de communication sous-jacent, mais cela ne devrait pas être explicitement vu ni dans la définition des procédures ni dans les procédures elles-mêmes. L'éloignement introduit des problèmes supplémentaires. L'exécution de l'appelant et de la procédure locale appelée sur la même machine se fait en un seul processus, mais la mise en œuvre de RPC implique au moins deux processus, un sur chaque machine.

Si l'un d'entre eux plante, les situations suivantes peuvent survenir lorsque la procédure d'appel se bloque, les procédures appelées à distance deviendront orphelines et si les procédures distantes se terminent anormalement, les appelants deviendront des parents désavantagés, qui attendront en vain une réponse des procédures distantes. les problèmes liés à l'hétérogénéité des langages de programmation et des environnements d'exploitation, des structures de données et des structures d'appel de procédure prises en charge dans un langage de programmation ne sont pas pris en charge de la même manière dans tous les autres langages.

Ces problèmes et d'autres sont résolus par la technologie RPC répandue qui sous-tend de nombreux systèmes d'exploitation distribués. Opérations RPC de base Pour comprendre le fonctionnement de RPC, envisagez d'abord d'exécuter un appel de procédure locale sur une machine normale qui est hors ligne, par exemple l'appel système count read fd, buf, nbytes où fd est un entier, buf est un tableau de caractères et nbytes est un entier. ...

Pour effectuer l'appel, la procédure d'appel pousse les paramètres sur la pile dans l'ordre inverse. Une fois l'appel à lire exécuté, il place la valeur de retour dans un registre, déplace l'adresse de retour et renvoie le contrôle à la procédure appelante, qui fait sortir les paramètres de la pile et la ramène à son état d'origine. Notez qu'en C, les paramètres peuvent être appelés soit par référence , ou par valeur. Par rapport à la procédure appelée, les paramètres de valeur sont des variables locales initialisables.

La procédure appelée peut les modifier, sans affecter la valeur des originaux de ces variables dans la procédure appelante. Si un pointeur vers une variable est passé à une procédure appelée, alors une modification de la valeur de cette variable par la procédure appelée modifiera également la valeur de cette variable pour la procédure appelante. Ce fait est très significatif pour RPC. Il existe également un autre mécanisme pour passer des paramètres, qui n'est pas utilisé en langage C. Il est appelé restauration appel par copie, et consiste en la nécessité pour l'appelant de copier des variables sur la pile en tant que valeurs, puis de les recopier après l'appel sur les valeurs d'origine de la procédure appelante.

Il appartient aux concepteurs de langage de décider quel mécanisme de passage de paramètres utiliser. Cela dépend parfois du type de données transmises. En C, par exemple, les données entières et autres données scalaires sont toujours transmises par valeur et les tableaux sont toujours passés par référence.

Figure: 3.1. a Stack avant que l'appel de lecture ne soit effectué b Stack pendant l'exécution de la procédure sur la pile après retour à l'appelant L'idée derrière RPC est de faire ressembler un appel de procédure distante aussi près que possible à un appel de procédure locale. En d'autres termes, pour rendre RPC transparent, l'appelant n'a pas besoin de savoir que la procédure appelée est sur une machine différente, et vice versa. RPC réalise la transparence de la manière suivante.

Lorsque la procédure appelée est effectivement distante, au lieu de la procédure locale, une autre version de la procédure est placée dans la bibliothèque, appelée stub client. Comme la procédure d'origine, le stub est appelé en utilisant la séquence d'appel de la figure 3.1, et le noyau est interrompu. Seulement, contrairement à la procédure originale, il ne met pas de paramètres dans les registres et ne demande pas de données au noyau, à la place il génère un message à envoyer au noyau de la machine distante. Étapes de l'exécution du RPC L'interaction des composants logiciels dans l'exécution d'un appel de procédure à distance est illustrée à la Figure 3.2. Une fois que le stub client a été appelé par le programme client, sa première tâche consiste à remplir le tampon avec le message envoyé.

Sur certains systèmes, le stub client a un seul tampon de longueur fixe qui est rempli dès le début à chaque nouvelle demande. Sur d'autres systèmes, un tampon de messages est un pool de tampons pour les champs de message individuels, dont certains sont déjà pleins.

Cette méthode est particulièrement utile lorsque le paquet est formaté avec un grand nombre de champs, mais les valeurs de plusieurs de ces champs ne changent pas d'un appel à l'autre. Les paramètres doivent ensuite être convertis au format approprié et insérés dans la mémoire tampon des messages. À ce stade, le message est prêt pour la transmission, de sorte qu'une interruption est effectuée sur l'appel du noyau. Figure: 3.2. Appel de procédure à distance Lorsque le noyau prend le contrôle, il change de contexte, enregistre les registres du processeur et les descripteurs de page de mappage de mémoire, et configure une nouvelle mappe de mémoire à utiliser pour le mode noyau. Comme le noyau et les contextes utilisateur sont différents, le noyau doit copier le message exactement dans son propre espace d'adressage, afin de pouvoir y accéder, se souvenir de l'adresse de destination et éventuellement d'autres champs d'en-tête, et il doit le transmettre à l'interface réseau.

Ceci termine le travail côté client.

Le temporisateur de transmission est activé et le noyau peut soit interroger une réponse, soit passer le contrôle au planificateur, qui choisit un autre processus à exécuter. Dans le premier cas, l'exécution des requêtes est accélérée, mais il n'y a pas de multiprogrammation. Côté serveur, les bits entrants sont placés par le matériel récepteur soit dans un tampon intégré soit dans la RAM, et lorsque toutes les informations sont reçues, une interruption est générée.

Le gestionnaire d'interruption vérifie la validité des données du paquet et détermine quel stub doit être transmis. Si aucun des stubs n'attend ce paquet, le gestionnaire doit soit le mettre dans une mémoire tampon, soit le supprimer complètement. S'il existe un stub en attente, le message y est copié. Enfin, un changement de contexte est effectué, à la suite de quoi les registres et la carte mémoire sont restaurés, en prenant les valeurs qu'ils avaient au moment où le stub a effectué l'appel de réception.

Maintenant, le stub de serveur commence à fonctionner. Il décompresse les paramètres et les pousse de manière appropriée sur la pile. Lorsque tout est prêt, un appel au serveur est effectué. Une fois la procédure terminée, le serveur envoie les résultats au client en suivant toutes les étapes décrites ci-dessus, uniquement dans l'ordre inverse. La figure 3.3 montre la séquence de commandes qui doivent être exécutées pour chaque appel RPC, et la figure 3.4 montre combien de temps d'exécution RPC total est passé à exécuter chacune des 14 étapes décrites.

La recherche a été menée sur une station de travail multiprocesseur DEC Firefly, et bien que la présence de cinq processeurs ait nécessairement affecté les résultats de mesure, l'histogramme montré sur la figure donne un aperçu du processus d'exécution RPC. Figure: 3.3. Étapes de la procédure RPC Fig. 3.4. Répartition du temps entre 14 étapes d'exécution du RPC 1. Appel de stub 2. Préparer le tampon 3. Paramètres du pack 4. Remplir le champ d'en-tête 5. Calculer la somme de contrôle dans le message 6. Interruption vers le cœur 7. File d'attente de paquets pour l'exécution 8. Envoyer le message au contrôleur via QBUS 9. Heure de transmission par réseaux Ethernet 10. Recevoir un paquet du contrôleur 11. Procédure de traitement des interruptions 12. Calcul somme de contrôle 13. Basculement du contexte vers l'espace utilisateur 14. Exécution de la liaison dynamique du stub de serveur Considérez la manière dont le client spécifie l'emplacement du serveur.

Une méthode pour résoudre ce problème consiste à utiliser directement l'adresse réseau du serveur dans le programme client.

L'inconvénient de cette approche est son extrême inflexibilité lors du déplacement du serveur, ou lorsque le nombre de serveurs augmente, ou lorsque l'interface est modifiée dans tous ces cas et bien d'autres, il est nécessaire de recompiler tous les programmes qui ont utilisé une affectation dure de l'adresse du serveur. Afin d'éviter tous ces problèmes, en certains systèmes distribués utilisent ce qu'on appelle la liaison dynamique.

Le point de départ de la liaison dynamique est de définir formellement la spécification du serveur. La spécification contient le nom du serveur de fichiers, le numéro de version et une liste des procédures de service fournies par ce serveur pour les clients. Pour chaque procédure, une description de ses paramètres est donnée, indiquant si ce paramètre est une entrée ou une sortie par rapport au serveur. Certains paramètres peuvent être simultanément en entrée et en sortie - par exemple, un tableau envoyé par le client au serveur y est modifié, puis l'opération est renvoyée au client copie de restauration. Figure: 3.5. Spécification du serveur RPC La spécification formelle du serveur est utilisée comme entrée d'un programme générateur de stub qui crée des stubs de client et de serveur.

Ensuite, ils sont placés dans les bibliothèques appropriées. Lorsqu'un programme client personnalisé appelle une procédure définie dans la spécification du serveur, la procédure stub correspondante est associée à code binaire programmes.

De même, lorsqu'un serveur est compilé, les stubs de serveur lui sont associés. Lorsque le serveur démarre, sa toute première action est de transmettre son interface serveur à un programme spécial appelé binder. Ce processus, appelé processus d'enregistrement du serveur, implique que le serveur envoie son nom, son numéro de version, son identifiant unique et son descripteur d'emplacement. L'enregistreur est indépendant du système et peut être IP, Ethernet, X.500 ou une autre adresse.

De plus, il peut contenir d'autres informations, par exemple liées à l'authentification. Lorsque le client appelle l'une des procédures distantes pour la première fois, par exemple, read, le stub client voit qu'il n'est pas encore connecté au serveur et envoie un message au programme de reliure lui demandant d'importer l'interface de la version requise serveur souhaitéSi un tel serveur existe, le classeur transmet un handle et un identificateur unique au stub client.

Le stub client utilise un descripteur comme adresse lors de l'envoi d'un message de demande. Le message contient des paramètres et un identifiant unique que le cœur du serveur utilise afin de transmettre le message entrant au bon serveur au cas où il y en aurait plusieurs sur cette machine. Cette méthode d'importation et d'exportation d'interfaces est très flexible. Par exemple, plusieurs serveurs peuvent prendre en charge la même interface et les clients sont répartis de manière aléatoire entre les serveurs.

Dans le cadre de cette méthode, il devient possible d'interroger périodiquement les serveurs, d'analyser leurs performances et, en cas de panne, arrêt automatique, ce qui augmente la tolérance aux pannes globale du système. Cette méthode peut également prendre en charge l'authentification client. Par exemple, un serveur peut déterminer qu'il ne peut être utilisé que par les clients d'une liste spécifique. Cependant, la liaison dynamique présente des inconvénients, tels que la surcharge supplémentaire et le temps nécessaire pour exporter et importer des interfaces.

Le montant de ces coûts peut être important, car de nombreux processus client existent pendant une courte période, et à chaque démarrage du processus, la procédure d'importation d'interface doit être à nouveau exécutée. De plus, dans les grands systèmes distribués, il peut devenir goulot binder, et la création de plusieurs programmes ayant un objectif similaire augmente également la surcharge de création et de synchronisation des processus Sémantique RPC sur les échecs Idéalement, RPC devrait fonctionner correctement en cas d'échec.

Considérez les classes d'échec suivantes: 1. Le client ne parvient pas à localiser le serveur, par exemple, si le serveur correct échoue, ou parce que le programme client a été compilé il y a longtemps et a utilisé une ancienne version de l'interface serveur. Dans ce cas, un message contenant un code d'erreur est reçu en réponse à la demande du client. 2. La requête du client vers le serveur est perdue, la solution la plus simple est de répéter la requête après un certain temps. 3. Message de réponse perdu du serveur au client.

Cette option est plus compliquée que la précédente, car certaines procédures ne sont pas idempotentes. Une procédure idempotente est une procédure dont la demande d'exécution peut être répétée plusieurs fois, et le résultat ne changera pas. Un exemple d'une telle procédure est la lecture d'un fichier, mais la procédure de retrait d'un certain montant d'un compte bancaire n'est pas idempotente, et si la réponse est perdue, une demande répétée peut modifier considérablement l'état du compte du client.

L'une des solutions possibles est de mettre toutes les procédures sous une forme idempotente. Cependant, dans la pratique, ce n'est pas toujours possible, donc une autre méthode peut être utilisée - la numérotation séquentielle de toutes les demandes par le noyau client. Le cœur du serveur se souvient du numéro de la requête la plus récente de chacun des clients, et à la réception de chaque requête, il analyse si cette requête est principale ou répétée. 4. Le serveur a planté après avoir reçu la requête. La propriété d'idempotence est également importante ici, mais malheureusement, l'approche de numérotation des requêtes ne peut pas être appliquée.

Dans ce cas, le moment où l'échec s'est produit est important - avant ou après l'opération. Mais le noyau client ne peut pas reconnaître ces situations, il sait seulement que la réponse a expiré. Il existe trois approches à ce problème. Attendez que le serveur redémarre et réessayez. Cette approche garantit que le RPC a été effectué au moins une fois, voire plus. Signalez immédiatement l'erreur à l'application.

Cette approche garantit que le RPC n'a pas été exécuté plus d'une fois. La troisième approche ne garantit rien. Lorsque le serveur tombe en panne, il n'y a pas de support pour le client. Le RPC peut être exécuté ou pas du tout, ou plusieurs fois. Dans tous les cas, cette méthode est très simple à mettre en œuvre. Aucune de ces approches n'est très attrayante et l'option idéale qui garantirait exactement une exécution RPC ne peut généralement pas être mise en œuvre pour des raisons de principe.

Supposons, par exemple, qu'une opération à distance imprime du texte, ce qui inclut le chargement de la mémoire tampon de l'imprimante et la définition d'un bit dans un registre de contrôle de l'imprimante, ce qui entraîne le démarrage de l'imprimante. Une panne de serveur peut se produire une microseconde avant ou une microseconde après la définition du bit de contrôle. Le moment de l'échec détermine complètement la procédure de récupération, mais le client ne peut pas connaître le moment de l'échec.

En bref, la possibilité d'un crash du serveur change radicalement la nature du RPC et reflète clairement la différence entre un système centralisé et un système distribué. Dans le premier cas, une panne du serveur entraîne une panne du client et la récupération est impossible. Dans le second cas, les étapes de restauration du système sont à la fois possibles et nécessaires. 1. Le client a subi un accident après l'envoi de la demande. Dans ce cas, les calculs sont effectués avec des résultats auxquels personne ne s'attend et sont appelés orphelins. La présence d'orphelins peut entraîner divers problèmes, surcharge du temps processeur, blocage des ressources, remplacement de la réponse à la requête en cours par la réponse à une requête émise par la machine client avant le redémarrage du système.

Que faire des orphelins? Considérez 4 solutions possibles... Destruction. Avant que le stub client n'envoie un message RPC, il fait une note dans le journal pour indiquer ce qu'il va faire maintenant. Le journal est stocké sur le disque ou une autre mémoire tolérante aux pannes.

Après l'accident, le système redémarre, le journal est analysé et les orphelins sont éliminés. Les inconvénients de cette approche comprennent, d'une part, les coûts accrus associés à l'écriture de chaque RPC sur disque, et, d'autre part, l'inefficacité possible due à l'apparition d'orphelins de deuxième génération générés par les appels RPC émis par des orphelins de première génération. Réincarnation: Dans ce cas, tous les problèmes sont résolus sans utiliser l'écriture sur disque. La méthode consiste à diviser le temps en périodes numérotées séquentiellement. Lorsque le client redémarre, il diffuse sur toutes les machines pour démarrer une nouvelle période.

Après avoir reçu ce message, tous les calculs distants sont supprimés. Bien sûr, si le réseau est segmenté, certains orphelins peuvent survivre. La réincarnation douce est similaire au cas précédent, sauf que tous les calculs distants ne sont pas trouvés et détruits, mais uniquement ceux du client de redémarrage. Expiration: Chaque demande a un intervalle de temps standard T, pendant lequel elle doit être complétée.

Si la demande n'est pas exécutée dans le délai imparti, un quantum supplémentaire est alloué. Bien que cela nécessite un travail supplémentaire, si, après un crash client, le serveur attend un intervalle T avant le redémarrage du client, alors tous les orphelins sont nécessairement détruits. En pratique, aucune de ces approches n'est souhaitable; de \u200b\u200bplus, la destruction des orphelins peut aggraver la situation. Par exemple, supposons qu'un orphelin a verrouillé un ou plusieurs fichiers de base de données.

Si l'orphelin est soudainement détruit, ces verrous resteront.De plus, les orphelins détruits peuvent rester debout dans diverses files d'attente système, à l'avenir, ils peuvent provoquer l'exécution de nouveaux processus, etc.

Que ferons-nous du matériel reçu:

Si ce matériel s'est avéré utile pour vous, vous pouvez le sauvegarder sur votre page sur les réseaux sociaux:

Conférence 4

4.1 Concept d'appel de procédure à distance

L'idée derrière l'appel de procédures à distance (Appel de procédure à distance - RPC) est d'étendre le mécanisme bien connu et bien compris de transfert de contrôle et de données dans un programme exécuté sur une machine pour transférer le contrôle et les données sur un réseau. Les fonctions d'appel de procédure à distance sont conçues pour faciliter l'organisation de l'informatique distribuée. L'utilisation la plus efficace de RPC est obtenue dans les applications dans lesquelles il existe une communication interactive entre des composants distants avec des temps de réponse courts et relativement peu de transfert de données. Ces applications sont appelées orientées RPC.

Les caractéristiques des procédures locales d'appel sont: l'asymétrie, c'est-à-dire qu'une des parties en interaction est l'initiateur; la synchronicité, c'est-à-dire l'exécution de la procédure appelante lorsqu'elle s'arrête à partir du moment où la requête est émise et ne reprend qu'après le retour de la procédure appelée.

Les appels à distance sont beaucoup plus complexes que les appels de procédure locale. Pour commencer, comme l'appelant et l'appelé sont exécutés sur des machines différentes, ils ont des espaces d'adressage différents, ce qui crée des problèmes lors de la transmission des paramètres et des résultats, surtout si les machines ne sont pas identiques. Étant donné que RPC ne peut pas compter sur la mémoire partagée, cela signifie que les paramètres RPC ne doivent pas contenir de pointeurs vers des emplacements de mémoire non-pile et que les valeurs de paramètres doivent être copiées d'un ordinateur à un autre. La différence suivante entre RPC et un appel local est qu'il utilise nécessairement le système de communication sous-jacent, mais cela ne devrait pas être explicitement vu ni dans la définition des procédures ni dans les procédures elles-mêmes. L'éloignement introduit des problèmes supplémentaires. L'exécution du programme appelant et de la procédure locale appelée sur la même machine se fait en un seul processus. Mais il y a au moins deux processus impliqués dans la mise en œuvre de RPC - un sur chaque machine. Si l'une d'entre elles plante, les situations suivantes peuvent survenir: si la procédure appelante plante, les procédures appelées à distance deviendront "orphelines", et si les procédures distantes se terminent anormalement, les appelants deviendront des "parents privés" des appelants, qui attendront en vain une réponse des procédures distantes.

En outre, il existe un certain nombre de problèmes associés à l'hétérogénéité des langages de programmation et des environnements d'exploitation: les structures de données et les structures d'appel de procédure prises en charge dans un langage de programmation ne sont pas prises en charge de la même manière dans tous les autres langages.

Ces problèmes et d'autres sont résolus par la technologie RPC largement répandue qui sous-tend de nombreux systèmes d'exploitation distribués.

Opérations RPC de base

Pour comprendre le fonctionnement de RPC, envisagez d'abord d'exécuter un appel de procédure locale sur une machine conventionnelle qui s'exécute de manière autonome. Par exemple, que ce soit un appel système

count \u003d read (fd, buf, nbytes);

où fd est un entier;

buf - tableau de caractères;

nbytes est un entier.

Pour effectuer l'appel, la procédure d'appel pousse les paramètres sur la pile dans l'ordre inverse. Une fois l'appel à lire terminé, il place la valeur de retour dans un registre, déplace l'adresse de retour et renvoie le contrôle à la procédure appelante, qui fait sortir les paramètres de la pile, la ramenant à son état d'origine. Notez qu'en C, les paramètres peuvent être appelés soit par référence (par nom) soit par valeur (par valeur). Par rapport à la procédure appelée, les paramètres de valeur sont des variables locales initialisables. La procédure appelée peut les modifier, sans affecter la valeur des originaux de ces variables dans la procédure appelante.

Si un pointeur vers une variable est passé à la procédure appelée, alors une modification de la valeur de cette variable par la procédure appelée modifiera également la valeur de cette variable pour la procédure appelante. Ce fait est essentiel pour RPC.

Il existe également un autre mécanisme pour passer des paramètres, qui n'est pas utilisé en langage C. Il est appelé call-by-copy / restore et consiste en la nécessité pour le programme appelant de copier des variables sur la pile en tant que valeurs, puis de les recopier après l'appel sur les valeurs d'origine de la procédure appelante.

Il appartient aux concepteurs de langage de décider quel mécanisme de passage de paramètres utiliser. Parfois, cela dépend du type de données transférées. En C, par exemple, les données entières et autres données scalaires sont toujours passées par valeur, et les tableaux sont toujours passés par référence.

L'idée derrière RPC est de rendre un appel de procédure à distance aussi proche que possible d'un appel de procédure locale. En d'autres termes, rendez RPC transparent: l'appelant n'a pas besoin de savoir que la procédure appelée se trouve sur une machine différente, et vice versa.

RPC réalise la transparence de la manière suivante. Lorsque la procédure appelée est effectivement distante, au lieu de la procédure locale, une autre version de la procédure appelée stub client (stub) est placée dans la bibliothèque. Comme la procédure d'origine, le stub est appelé à l'aide de la séquence d'appel et une interruption se produit lors de l'accès au noyau. Seulement, contrairement à la procédure originale, il ne met pas de paramètres dans les registres et ne demande pas de données au noyau, mais génère un message à envoyer au noyau de la machine distante.

Étapes RPC

L'interaction des composants logiciels lors de l'exécution d'un appel de procédure à distance est illustrée à la figure 2.

Figure 2. Appel de procédure à distance

Une fois que le stub client a été appelé par le programme client, sa première tâche consiste à remplir le tampon avec le message envoyé. Sur certains systèmes, le stub client a un seul tampon de longueur fixe qui est rempli dès le début à chaque nouvelle demande. Sur d'autres systèmes, un tampon de messages est un pool de tampons pour les champs de message individuels, dont certains sont déjà pleins. Cette méthode est particulièrement utile lorsque le paquet est formaté avec un grand nombre de champs, mais les valeurs de plusieurs de ces champs ne changent pas d'un appel à l'autre.

Les paramètres doivent ensuite être convertis au format approprié et insérés dans la mémoire tampon des messages. À ce stade, le message est prêt à être envoyé, donc une interruption est effectuée sur l'appel du noyau.

Lorsque le noyau prend le contrôle, il change de contexte, enregistre les registres du processeur et une carte mémoire (descripteurs de page), et installe une nouvelle carte mémoire qui sera utilisée pour s'exécuter en mode noyau. Étant donné que les contextes du noyau et de l'utilisateur sont différents, le noyau doit copier le message exactement dans son propre espace d'adressage pour pouvoir y accéder, se souvenir de l'adresse de destination (et éventuellement d'autres champs d'en-tête), et il doit également le transmettre à l'interface réseau. Ceci termine le travail côté client. Le minuteur de transmission est activé et le noyau peut soit interroger une réponse, soit passer le contrôle au planificateur, qui choisit un autre processus à exécuter. Dans le premier cas, l'exécution des requêtes est accélérée, mais il n'y a pas de multiprogrammation.

Côté serveur, les bits entrants sont placés par le matériel récepteur soit dans un tampon intégré soit en RAM. Lorsque toutes les informations sont reçues, une interruption est générée. Le gestionnaire d'interruption vérifie l'exactitude des données du paquet et détermine quel stub doit lui être transmis. Si aucun des stubs n'attend ce paquet, le gestionnaire doit soit le placer dans un tampon, soit le rejeter complètement. S'il existe un stub en attente, le message y est copié. Enfin, un changement de contexte est effectué, à la suite de quoi les registres et la carte mémoire sont restaurés, en prenant les valeurs qu'ils avaient au moment où le stub a effectué l'appel de réception.

La figure 3 montre la séquence de commandes qui doivent être exécutées pour chaque appel RPC.

Figure 3. Étapes de la procédure RPC

Toute modification du système d'exploitation Windows, à partir de la version XP, inclut un composant de service désigné comme RPC. Ce que c'est, les utilisateurs ordinaires pour la plupart ne savent pas, de plus, ils ne savent pas à quoi sert ce service et comment il fonctionne. À cet égard, il est proposé d'examiner certains aspects de base liés au composant lui-même, aux principes de son fonctionnement et au domaine d'utilisation sans décrire les termes techniques inutiles et complexes. Arrêtons-nous séparément sur les erreurs de service possibles et les méthodes pour leur élimination rapide.

Procédures à distance (appel de procédure à distance): de quoi s'agit-il?

Apparemment, de nombreux utilisateurs, sur la base du nom de ce composant de service, ont déjà conclu de quoi il s'agissait. En effet, les procédures distantes (appel de procédures distantes) impliquent certaines actions lorsqu'elles ne sont pas exécutées sur ordinateur local, mais sur une télécommande (le plus souvent sur un serveur).

C'est-à-dire que la demande est formée sur un terminal, puis transférée à un autre, où elle est exécutée, après quoi une réponse (rapport) sur l'exécution est renvoyée au premier ordinateur. Mais ce n'est qu'une explication primitive. En fait, tout est beaucoup plus compliqué, car ici il faut prendre en compte les protocoles de transfert de données (UDP, TCP, HTTP) et de nombreux autres mécanismes.

A quoi sert ce service?

Malgré son objectif principal, RPC RPC peut être utilisé sur un ordinateur plutôt que sur différents ordinateurs. L'exemple le plus simple est un appel à une fonction d'un programme depuis une autre application. De nombreux musiciens travaillant avec des studios virtuels et des séquenceurs sont conscients que chacune de ces applications possède son propre module d'édition ou de traitement audio, qui ne répond pas toujours aux exigences de l'utilisateur. Et n'importe quel studio vous permet de connecter n'importe quel autre programme externe à la place.

Par exemple, dans les paramètres du séquenceur FL Studio, vous pouvez spécifier une autre application (par exemple, Adobe Audition), qui sera utilisée par défaut pour éditer les fichiers son (échantillons) dans l'environnement principal du programme. Dans le même temps, la connexion d'Adobe Audition à FL Studio ne se fera pas via des hôtes virtuels tels que VST, RTAS ou DX, mais directement via l'utilisation du service d'appel de procédure à distance. Il va sans dire que cet exemple n'est pas le seul, car la portée du composant décrit est beaucoup plus large.

Très souvent, ce service est également associé à la répartition de la charge de calcul sur les terminaux, entre lesquels s'établit une communication interactive. Dans le même temps, si la charge sur les ressources informatiques de plusieurs ordinateurs est uniformément répartie, des performances maximales ne peuvent être atteintes que si de petites quantités de données et une réponse rapide sont échangées entre les composants.

Échec de l'appel de procédure à distance: pourquoi?

Malheureusement, en raison de cette demande, l'apparition de pannes et d'erreurs associées à ce service est assez courante.

En conséquence, il devient impossible non seulement d'utiliser le composant lui-même. Parfois, il n'est même pas possible d'accéder à certains paramètres du système, et Windows XP se bloque simplement, après quoi il peut être assez problématique de le restaurer à un état de fonctionnement normal. Un autre problème est l'outil de réparation DISM en ligne inclus avec le système d'exploitation.

C'est aux violations de son travail que l'apparition de l'erreur 1726 est associée, ce qui affecte directement le fonctionnement des composants du service RPC.

Les principales raisons de ces échecs sont appelées l'invocation d'un vérificateur système ou d'une réparation système lorsque le processus DISM est actif ou ne peut pas s'arrêter correctement (par exemple, lorsque les outils DISM et SFC sont démarrés à partir de deux consoles de commande en même temps); lorsque le service s'exécute en parallèle avec la maintenance des composants RPC; lorsque le service est bloqué par un logiciel antivirus.

Par conséquent, si RPC échoue sur Windows 7 et supérieur, la première chose à faire est de quitter DISM, de redémarrer votre ordinateur et de redémarrer le service. Si cela ne résout pas le problème, vous pouvez essayer de passer en mode sans échec et désactiver complètement la protection antivirus pendant la récupération. Nous nous attarderons sur des mesures supplémentaires permettant de résoudre tout échec lors d'un appel de procédure à distance et lors de toute modification de Windows. Pour l'instant, examinons les problèmes liés à la désactivation de ce composant système (hélas, de nombreux utilisateurs qui ne connaissent pas l'essence du problème essaient de faire de telles choses).

Puis-je désactiver le service RPC?

Voyons donc à quel point il est réaliste de désactiver le RPC. Les procédures à distance, basées sur les recommandations des développeurs, ne peuvent en aucun cas être désactivées. C'est important! En principe, elle-même ne le permettra pas. Il existe, bien sûr, des solutions de contournement qui impliquent l'utilisation d'un logiciel, mais pour des raisons évidentes, les noms de ces applications ne sont pas donnés, car si elles sont mal utilisées, l'ensemble du système peut devenir inutilisable.

Conséquences de la désactivation des processus RPC

Même si l'utilisateur parvient à désactiver d'une manière ou d'une autre les procédures distantes (appel de procédures distantes), les conséquences, malheureusement, peuvent être très imprévisibles. Comme déjà mentionné, Windows XP peut cesser de fonctionner complètement, et dans un système d'exploitation avec un rang plus élevé, par conséquent, un grand nombre de pannes du système, qui ne peut être éliminé, ne serait-ce qu'en raison du manque d'accès aux paramètres critiques et aux paramètres de Windows, de plus, même dans mode sans échec ou lors du démarrage à partir d'un support amovible. Cependant, vous pouvez corriger un plantage lors de l'appel de procédures à distance sur Windows 10 ou des systèmes d'exploitation antérieurs. La méthode n'est pas la plus simple, vous devez donc être très prudent lors de son utilisation.

Désactiver le localisateur d'accès à distance

Ainsi, le service RPC principal ne peut pas être désactivé. Mais peut-être est-il logique de désactiver certains de ses composants d'accompagnement? Oui, en effet, si vous accédez à la section des services système et de leurs composants (services.msc), vous pouvez trouver le soi-disant localisateur RPC.

Mais il peut être désactivé sans crainte de conséquences catastrophiques. Après avoir entré la modification de ses paramètres, vous devez arrêter le composant et définir le type de démarrage sur désactivé. Les programmes qui peuvent utiliser des procédures distantes appelleront de toute façon des procédures distantes (sans son aide).

Si pour une raison quelconque les paramètres définis ne fonctionnent pas, vous pouvez utiliser l'installation disque Windows, lors du chargement à partir de celui-ci, appelez la ligne de commande et entrez ce qui suit:

cd X: \\ i386 (X est la lettre du lecteur amovible);
développez explorer.ex_% TEMP% \\ explorer.exe;
développez svchost.ex_% TEMP% \\ svchost.exe.

Après le redémarrage, le "Gestionnaire des tâches" est appelé, et il se termine alors la copie de combinaison% TEMP% \\ explorer.exe% SYSTEMROOT% / y est écrite dans la ligne de commande, après quoi absolument tout est terminé dans le "Gestionnaire des tâches" processus svchost... Maintenant, vous devez être particulièrement prudent, car après avoir terminé les processus en seulement soixante secondes dans la console de commande, vous devez avoir le temps d'écrire la commande copy% TEMP% \\ svchost.exe% systemroot% \\ system32 / y.

Si un utilisateur, par exemple, en mode normal ou sans échec, a accès au registre système, dans l'éditeur (regedit) de la branche HKCC, recherchez le paramètre CSConfigFlags et attribuez-lui la valeur zéro.

Dépannage du crash 1726

Enfin, le dépannage de l'erreur 1726 est également effectué via le registre. Mais dans ce cas, dans la branche HKLM, vous devez trouver le répertoire RpcSs, et sur la droite, éditer la valeur du paramètre Start.

Il doit passer de quatre, généralement défini par défaut, à deux, puis redémarrer le système.

Épilogue

C'est tout ce qu'il y a aux appels RPC. Procédures à distance, les principes de fonctionnement de ce composant dans une version étendue peuvent être décrits pendant très longtemps, mais l'accent dans le matériel présenté a été mis sur une connaissance générale du service et de certaines méthodes pour éliminer les erreurs et les pannes qu'il peut provoquer dans un système informatique. Les utilisateurs ordinaires devront être patients et très prudents, car une mauvaise action dans le registre peut conduire à un crash complet du système d'exploitation.

Veuillez noter que ces types de plantages ne sont résolus par aucun autre moyen, comme les optimiseurs et les tuners de paramètres du système d'exploitation Windows. Avec tout le désir, ni la ligne de commande, ni, de surcroît, aucune intervention dans le registre au niveau de l'édition des clés de tels progiciels ne sont prévues.

Appel de procédure à distance (ou Appel de procédures à distance) (de l'anglais. Appel de procédure à distance (RPC)) est une classe de technologies qui permettent aux programmes informatiques d'appeler des fonctions ou des procédures dans un espace d'adressage différent (généralement sur des ordinateurs distants). En règle générale, une implémentation de technologie RPC comprend deux composants: un protocole réseau pour l'échange client-serveur et un langage de sérialisation d'objets (ou structures, pour RPC non-objet). Différentes implémentations RPC ont des architectures et des capacités très différentes: certaines implémentent SOA, d'autres CORBA ou DCOM. Au niveau de la couche de transport, les RPC sont principalement utilisés par les protocoles TCP et UDP, cependant, certains sont basés sur HTTP (ce qui viole l'architecture ISO / OSI, puisque HTTP n'était pas à l'origine un protocole de transport).

la mise en oeuvre

Il existe de nombreuses technologies qui fournissent RPC:

Sun RPC (protocole binaire basé sur TCP et UDP et XDR) RFC-1831 deuxième nom ONC RPC RFC-1833
.Net Remoting (protocole binaire basé sur TCP, UDP, HTTP)
SOAP - Simple Object Access Protocol voir la spécification: RFC-4227
XML RPC (HTTP Based Text Protocol) Voir la spécification: RFC-3529
Java RMI - Invocation de méthode à distance Java - voir les spécifications: http://java.sun.com/j2se/1.5.0/docs/guide/rmi/index.html
JSON-RPC JavaScript Object Notation Appels de procédure distante (protocole de texte basé sur HTTP) Voir la spécification: RFC-4627
DCE / RPC - Distributed Computing Environment / Remote Procedure Calls (protocole binaire basé sur divers protocoles de transport, y compris TCP / IP et Named Pipes du protocole SMB / CIFS)
DCOM - Modèle d'objet de composant distribué connu sous le nom de MSRPC Microsoft Remote Procedure Call ou «Network OLE» (une extension orientée objet de DCE RPC qui vous permet de passer des références aux objets et d'appeler des méthodes d'objets via de telles références)

Principe

L'idée derrière Remote Procedure Call (RPC) est d'étendre le mécanisme bien connu et bien compris pour transférer le contrôle et les données dans un programme exécuté sur une seule machine pour transférer le contrôle et les données sur un réseau. Les fonctions d'appel de procédure à distance sont conçues pour faciliter l'organisation de l'informatique distribuée et créer un client-serveur distribué systèmes d'information... La plus grande efficacité de l'utilisation de RPC est obtenue dans les applications dans lesquelles il existe une communication interactive entre des composants distants avec un temps de réponse court et une quantité relativement faible de données transférées. Ces applications sont appelées orientées RPC.

L'implémentation d'appels distants est beaucoup plus complexe que l'implémentation d'appels de procédure locale. Les problèmes et tâches suivants peuvent être identifiés et doivent être résolus lors de la mise en œuvre de RPC:

Étant donné que l'appelant et la procédure appelée sont exécutés sur des machines différentes, ils ont des espaces d'adressage différents, ce qui crée des problèmes lors du passage des paramètres et des résultats, surtout si les machines exécutent différents systèmes d'exploitation ou ont des architectures différentes (par exemple, big ou big endian ). Étant donné que RPC ne peut pas compter sur la mémoire partagée, cela signifie que les paramètres RPC ne doivent pas contenir de pointeurs vers des emplacements de mémoire non-pile et que les valeurs de paramètre doivent être copiées d'un ordinateur à un autre. Pour copier les paramètres de procédure et le résultat de leur exécution sur le réseau, ils sont sérialisés.
Contrairement à un appel local, RPC utilise nécessairement la couche transport de l'architecture réseau (par exemple TCP), mais cela reste caché au développeur.
L'exécution du programme appelant et de la procédure locale appelée sur la même machine se fait en un seul processus. Mais il y a au moins deux processus impliqués dans la mise en œuvre de RPC - un sur chaque machine. Si l'une d'elles se termine anormalement, les situations suivantes peuvent survenir: si la procédure appelante plante, les procédures appelées à distance deviendront "orphelines", et si les procédures distantes se terminent anormalement, les procédures appelantes deviendront des "parents privés" de l'appelant, qui attendra une réponse des procédures distantes en vain.
L'hétérogénéité des langages de programmation et des environnements d'exploitation pose un certain nombre de problèmes: les structures de données et les structures d'appel de procédure prises en charge dans un seul langage de programmation ne sont pas prises en charge de la même manière dans tous les autres langages. Ainsi, il existe un problème de compatibilité qui n'a encore été résolu ni par l'introduction d'une norme généralement acceptée, ni par la mise en œuvre de plusieurs normes concurrentes dans toutes les architectures et dans toutes les langues.

Sous-systèmes

Sous-système de transport

Gestion des connexions sortantes et entrantes. - prise en charge du concept de "limite de message" pour les protocoles de transport qui ne le prennent pas directement en charge (TCP). - Prise en charge de la livraison garantie pour les protocoles de transport qui ne la prennent pas directement en charge (UDP).

Pool de threads (appelé uniquement). Fournit un contexte d'exécution pour le code appelé sur le réseau.

Marshaling (également appelé «sérialisation»). Emballage des paramètres d'appel dans un flux d'octets d'une manière standard qui ne dépend pas de l'architecture (en particulier, de l'ordre des octets dans un mot). En particulier, il peut être exposé à des tableaux, des chaînes et des structures pointés par des paramètres de pointeur.

Cryptage des packages et signatures numériques.

Authentification et autorisation. Transmission sur le réseau d'informations identifiant le sujet appelant.

Dans certaines implémentations RPC (.NET Remoting), les limites des sous-systèmes sont des interfaces polymorphes ouvertes et il est possible d'écrire votre propre implémentation de presque tous les sous-systèmes répertoriés. Dans d'autres implémentations (DCE RPC sous Windows) ce n'est pas le cas.

voir également

Appel de procédure distante (RPC) Concept d'appel de procédure distante

L'idée derrière Remote Procedure Call (RPC) est d'étendre le mécanisme bien connu et bien compris de transfert de contrôle et de données dans un programme exécuté sur une seule machine pour transférer le contrôle et les données sur un réseau. Les fonctions d'appel de procédure à distance sont conçues pour faciliter l'organisation de l'informatique distribuée. L'utilisation la plus efficace de RPC est obtenue dans les applications dans lesquelles il existe une communication interactive entre les composants distants avec des temps de réponse courts et relativement peu de transfert de données. Ces applications sont appelées orientées RPC.

Les caractéristiques de l'appel des procédures locales sont:

L'asymétrie, c'est-à-dire que l'une des parties en interaction est l'initiateur;
La synchronisation, c'est-à-dire que l'exécution de la procédure appelante est suspendue à partir du moment où la requête est émise et ne reprend qu'après le retour de la procédure appelée.

Les appels à distance sont beaucoup plus complexes que les appels de procédure locale. Pour commencer, comme l'appelant et la procédure appelée sont exécutés sur des machines différentes, ils ont des espaces d'adressage différents, ce qui crée des problèmes lors du passage des paramètres et des résultats, surtout si les machines ne sont pas identiques. Étant donné que RPC ne peut pas compter sur la mémoire partagée, cela signifie que les paramètres RPC ne doivent pas contenir de pointeurs vers des emplacements de mémoire non-pile et que les valeurs de paramètre doivent être copiées d'un ordinateur à un autre. La différence suivante entre RPC et un appel local est qu'il utilise nécessairement le système de communication sous-jacent, mais cela ne devrait pas être explicitement vu ni dans la définition des procédures ni dans les procédures elles-mêmes. L'éloignement introduit des problèmes supplémentaires. L'exécution du programme appelant et de la procédure locale appelée sur la même machine se fait en un seul processus. Mais il y a au moins deux processus impliqués dans la mise en œuvre de RPC - un sur chaque machine. Si l'une d'elles se termine anormalement, les situations suivantes peuvent survenir: si la procédure appelante plante, les procédures appelées à distance deviendront "orphelines", et si les procédures distantes se terminent anormalement, les appelants deviendront des "parents privés" des appelants, qui attendront une réponse des procédures distantes en vain.

Ces problèmes et d'autres sont résolus par la technologie RPC largement répandue qui sous-tend de nombreux systèmes d'exploitation distribués. Opérations RPC de base

count \u003d read (fd, buf, nbytes);

où fd est un entier, buf est un tableau de caractères, nbytes est un entier.

Pour effectuer l'appel, la procédure d'appel pousse les paramètres sur la pile dans l'ordre inverse (Figure 3.1). Une fois l'appel à lire terminé, il place la valeur de retour dans un registre, déplace l'adresse de retour et renvoie le contrôle à la procédure appelante, qui fait sortir les paramètres de la pile, la ramenant à son état d'origine. Notez qu'en C, les paramètres peuvent être appelés soit par référence (par nom) soit par valeur (par valeur). Par rapport à la procédure appelée, les paramètres de valeur sont des variables locales initialisables. La procédure appelée peut les modifier, sans affecter la valeur des originaux de ces variables dans la procédure appelante.

Application

La plupart des outils de gestion à distance du système d'exploitation Windows (Observateur d'événements, Gestionnaire de serveur, Gestion de l'impression, Listes d'utilisateurs) utilisent DCE RPC comme moyen de communication réseau entre le service géré et l'application d'interface utilisateur de gestion. Le support DCE RPC est présent dans Windows NT depuis la toute première version 3.1. Les clients DCE RPC étaient également pris en charge sur la gamme légère des systèmes d'exploitation Windows 3.x / 95/98 / Me.

Les bibliothèques système Windows qui fournissent ce contrôle et servent de couche de base pour les applications d'interface utilisateur de contrôle (netapi32.dll et en partie advapi32.dll) contiennent en fait le code client des interfaces DCE RPC qui effectuent ce contrôle.

Cette conception architecturale a fait l'objet d'intenses critiques de la part de Microsoft. Les procédures génériques de marshaling trouvées dans DCE RPC sont très complexes et ont un énorme potentiel de failles qui peuvent être exploitées sur le réseau en envoyant un paquet DCE RPC délibérément malformé. Une partie importante des failles de sécurité Windows découvertes de la fin des années 90 au milieu des années 2000 était des erreurs dans le code de rassemblement DCE RPC.

En plus de DCE RPC, Windows utilise activement la technologie DCOM. Par exemple, il est utilisé comme outil de communication entre les outils de gestion du serveur Web IIS et le serveur géré lui-même. Interface de communication complète avec système postal MS Exchange Server - MAPI - est également basé sur DCOM.

Les programmes communiquant sur un réseau ont besoin d'un mécanisme de communication. Au niveau inférieur, à l'arrivée des paquets, un signal est traité par le programme de traitement du signal du réseau. Au plus haut niveau, le mécanisme de rendez-vous, adopté dans le langage Ada, fonctionne. NFS utilise un mécanisme d'appel de procédure à distance (RPC) dans lequel le client communique avec le serveur (voir la figure 1). Selon ce processus, le client accède d'abord à une procédure qui envoie une requête au serveur. A l'arrivée d'un paquet avec une requête, le serveur appelle la procédure d'ouverture de celui-ci, exécute le service demandé, envoie une réponse et le contrôle est retourné au client.

L'interface RPC peut être considérée comme trois couches:

Le niveau supérieur est complètement transparent. Un programme à ce niveau peut, par exemple, appeler rnusers (), qui renvoie le nombre d'utilisateurs sur la machine distante. Vous n'avez pas besoin de savoir comment utiliser le mécanisme RPC car vous effectuez l'appel dans le programme.
Le niveau intermédiaire est destiné aux applications les plus courantes. Les appels RPC à ce niveau sont gérés par les routines registerrpc () et callrpc (): registerrpc () reçoit du code sombre à l'échelle du système et callrpc () exécute un appel de procédure à distance. L'appel rnusers () est implémenté en utilisant ces deux routines.
Le niveau inférieur est utilisé pour les tâches plus complexes, en remplaçant la valeur par défaut par les valeurs des paramètres de procédure. À ce niveau, vous pouvez manipuler explicitement les sockets utilisées pour transmettre les messages RPC.

Généralement, vous devez utiliser niveau supérieur et évitez d'utiliser des niveaux inférieurs inutilement.

Malgré le fait que dans ce manuel nous considérons l'interface uniquement en C, l'accès aux procédures distantes peut se faire depuis n'importe quel langage. Le travail du mécanisme RPC pour organiser la communication entre les processus sur différentes machines ne diffère pas de son travail sur une machine.

RPC (Remote Procedure Call) est une interface entre des utilisateurs distants et des programmes hôtes spécifiques qui sont appelés à la demande de ces utilisateurs. Un service RPC pour un hôte fournit généralement aux clients une suite de programmes. Chacun de ces programmes, à son tour, consiste en une ou plusieurs procédures distantes. Par exemple, un service de système de fichiers distant NFS qui repose sur des appels RPC ne peut être constitué que de deux programmes: par exemple, un programme interagit avec des interfaces utilisateur de haut niveau et l'autre avec des fonctions d'E / S de bas niveau.

Chaque appel RPC implique deux parties: le client actif, qui envoie la demande d'appel de procédure au serveur, et le serveur, qui envoie la réponse au client.

Remarque. Notez que les termes «client» et «serveur» dans ce cas font référence à une transaction spécifique. Un hôte ou un logiciel (processus ou programme) spécifique peut fonctionner à la fois dans les rôles client et serveur. Par exemple, un programme qui fournit un service de procédure à distance peut en même temps être un client pour un système de fichiers réseau.

Le protocole RPC est construit sur un modèle d'appel de procédure distante similaire à celui des appels de procédure locale. Lorsque vous appelez une procédure locale, vous envoyez des arguments vers un emplacement de mémoire, une pile ou des variables d'environnement spécifiques, et vous transférez le contrôle du processus vers une adresse spécifique. Après avoir terminé le travail, vous lisez les résultats à une adresse spécifique et continuez votre processus.

Dans le cas d'une procédure distante, la principale différence est que l'appel de fonction distante est servi par deux processus: le processus client et le processus serveur.

Le processus client envoie un message au serveur, qui comprend les paramètres de la procédure appelée et attend un message de réponse avec les résultats de son travail. Lorsqu'une réponse est reçue, le résultat est lu et le processus se poursuit. Du côté du serveur, le processus du gestionnaire d'appels est dans l'état d'attente, et lorsqu'un message arrive, il lit les paramètres de la procédure, l'exécute, envoie une réponse et passe à l'état d'attente pour l'appel suivant.

Le protocole RPC n'impose aucune exigence sur les connexions supplémentaires entre les processus et ne nécessite pas de synchronisation des fonctions exécutées, c'est-à-dire que les appels peuvent être asynchrones et non indépendants, afin que le client puisse exécuter d'autres procédures en attendant une réponse. Le serveur RPC peut allouer un processus distinct ou une machine virtuelle pour chaque fonction, par conséquent, sans attendre la fin des demandes précédentes, il peut immédiatement accepter la suivante.

Cependant, il existe plusieurs différences importantes entre les appels de procédure locaux et distants:

Traitement des erreurs. Le client doit dans tous les cas être averti des erreurs qui se produisent lors de l'appel de procédures distantes sur le serveur ou sur le réseau.
Variables globales. Étant donné que le serveur n'a pas accès à l'espace d'adressage du client, vous ne pouvez pas utiliser de paramètres masqués sous la forme de variables globales dans les appels RPC.
Performance. En règle générale, la vitesse d’exécution des procédures à distance est inférieure d’un ou deux ordres de grandeur à la vitesse d’exécution de procédures locales similaires.
Authentification. Étant donné que les appels de procédure distante se produisent sur le réseau, des mécanismes d'authentification client doivent être utilisés.

Principes de construction du protocole.

Le protocole RPC peut utiliser plusieurs protocoles de transport différents. La seule responsabilité du protocole RPC est d'appliquer les normes et d'interpréter le transfert des messages. La fiabilité et la fiabilité de la transmission des messages sont entièrement assurées par la couche transport.

Cependant, RPC peut contrôler le choix et certaines fonctions du protocole de transport. À titre d'exemple de l'interaction entre RPC et le protocole de transport, considérons la procédure d'attribution d'un port RPC pour un processus d'application via RPC - Portmapper.

Cette fonction attribue dynamiquement (à la demande) un port spécifique à une connexion RPC. La fonction Portmapper est utilisée assez souvent car l'ensemble des ports de transport réservés pour RPC est limité et le nombre de processus pouvant potentiellement s'exécuter à la fois est très élevé. Le mappeur de ports, par exemple, est appelé lorsque vous sélectionnez les ports de communication d'un client et d'un serveur système NFS.

Le service Portmapper utilise le mécanisme de diffusion de messages RPC vers un port spécifique - III. Sur ce port, le client diffuse une requête pour le port d'un service RPC spécifique. Le service Portmapper traite le message de taxe, détermine l'adresse du service RPC local et envoie une réponse au client. Le service RPC Portmapper peut fonctionner avec les protocoles TCP et UDP.

RPC peut fonctionner avec divers protocoles de transport, mais il ne duplique jamais leurs fonctions, c'est-à-dire que si RPC s'exécute sur TCP, RPC place toutes les préoccupations concernant la fiabilité et la fiabilité de la connexion sur TCP. Cependant, si RPC est installé sur UDP, il peut fournir des fonctionnalités natives supplémentaires pour assurer la remise des messages.

Remarque.

Les applications peuvent afficher le protocole RPC comme une procédure d'appel de fonction définie sur le réseau JSR (Jump Subroutine Instruction).

Pour que le protocole RPC fonctionne, les conditions suivantes doivent être remplies:

Identification unique de toutes les procédures appelées à distance sur un hôte donné. Les requêtes RPC contiennent trois champs d'identifiants: le numéro du programme distant (service), le numéro de version du programme distant et le numéro de la procédure distante du programme spécifié. Le numéro de programme est attribué par le fabricant du service, le numéro de procédure indique la fonction spécifique de ce service
Identification de la version du protocole RPC. Les messages RPC contiennent un champ de version de protocole RPC. Il est utilisé pour faire correspondre les formats des paramètres transmis lorsque le client travaille avec différentes versions de RPC.
Fournir des mécanismes pour authentifier le client auprès du serveur. Le protocole RPC fournit une procédure d'authentification du client dans le service, et, si nécessaire, à chaque requête ou à l'envoi d'une réponse au client. De plus, RPC permet divers mécanismes de sécurité supplémentaires.

RPC peut utiliser quatre types de mécanismes d'authentification:

AUTH_NULL - aucune authentification utilisée
AUTH_UNIX - Authentification standard UNIX
AUTH_SHORT - Authentification UNIX avec sa propre structure de codage
AUTH_DES - Authentification DES

Identification des messages de réponse aux requêtes correspondantes. Les messages de réponse RPC contiennent l'ID de demande à partir duquel ils ont été créés. Cet identifiant peut être appelé l'identifiant de transaction de l'appel RPC. Ce mécanisme est particulièrement utile lorsque vous travaillez en mode asynchrone et lors de l'exécution d'une séquence de plusieurs appels RPC.
Identification des erreurs de protocole. Toutes les erreurs de réseau ou de serveur ont des identifiants uniques par lesquels chacun des participants à la connexion peut déterminer la cause de l'échec.

Structures des messages de protocole

Lors du transfert de messages RPC via un protocole de transport, plusieurs messages RPC peuvent se trouver dans un même paquet de transport. Afin de distinguer un message d'un autre, un marqueur d'enregistrement (RM - Record Marker) est utilisé. Chaque message RPC est "marqué" avec exactement un RM.

Un message RPC peut être composé de plusieurs fragments. Chaque bloc se compose de quatre octets d'en-tête et de (0 à 2 ** 31-1) données. Le premier bit de l'en-tête indique si ce fragment est le dernier et les 31 bits restants indiquent la longueur du paquet de données.

La structure RPC est formellement décrite dans le langage de description et de représentation des formats de données - XDR avec des ajouts concernant la description des procédures. On pourrait même dire que le langage de balisage RPC est une extension de XDR, complétée par un travail avec des procédures.

La structure du package RPC ressemble à ceci:

La structure reply_body peut contenir soit une structure transmise en cas d'erreur (auquel cas elle contient le code d'erreur), soit une structure permettant de traiter avec succès la requête (auquel cas elle contient les données renvoyées).

Interface de programmation de haut niveau.

L'utilisation de sous-programmes dans un programme est la manière traditionnelle de structurer une tâche, pour la rendre plus claire. Les sous-programmes les plus fréquemment utilisés sont rassemblés dans des bibliothèques, où ils peuvent être utilisés par divers programmes. Dans ce cas, nous parlons d'un appel local (local), c'est-à-dire que l'appelant et les objets appelés fonctionnent dans le même programme sur le même ordinateur.

Dans le cas d'un appel à distance, un processus exécuté sur un ordinateur démarre le processus sur l'ordinateur distant (c'est-à-dire qu'il exécute en fait le code de procédure sur l'ordinateur distant). Évidemment, un appel de procédure à distance diffère considérablement d'un appel local traditionnel, cependant, du point de vue d'un programmeur, de telles différences sont pratiquement absentes, c'est-à-dire que l'architecture d'un appel de procédure à distance vous permet de simuler un appel local.

Cependant, si, dans le cas d'un appel local, le programme transmet des paramètres à la procédure appelée et reçoit le résultat du travail à travers la pile ou les zones de mémoire partagée, alors dans le cas d'un appel à distance, le transfert de paramètres se transforme en une transmission d'une demande sur le réseau, et le résultat du travail est dans la réponse reçue.

Cette approche est une base possible pour créer des applications distribuées, et bien que systèmes modernes n'utilisez pas ce mécanisme, les concepts de base et les termes sont conservés dans de nombreux cas. En décrivant le mécanisme RPC, nous appellerons traditionnellement le processus appelant le client et le processus distant qui implémente la procédure en tant que serveur.

Un appel de procédure à distance comprend les étapes suivantes:

Le programme client effectue un appel local à une procédure appelée stub. Dans ce cas, le client "semble" que, en appelant le stub, il effectue un appel à la procédure serveur. En effet, le client passe les paramètres requis au stub, et il renvoie le résultat. Cependant, ce n'est pas exactement ce que le client envisage. Le travail du stub est d'accepter les arguments de la procédure distante, peut-être de les convertir en format standard et former une requête réseau. Le regroupement d'arguments et l'envoi d'une requête réseau s'appellent le rassemblement.
La demande réseau est envoyée via le réseau au système distant. Pour ce faire, le stub utilise les appels appropriés, par exemple, ceux décrits dans les sections précédentes. Notez que dans ce cas, différents protocoles de transport peuvent être utilisés, et pas seulement la famille TCP / IP.
Sur l'hôte distant, tout se passe dans l'ordre inverse. Le stub du serveur attend une demande et, à la réception, récupère les paramètres - les arguments de l'appel de procédure. L'extraction (unmarshalling) peut inclure les transformations nécessaires (par exemple, changer l'ordre des octets).
Le stub fait un appel à la procédure serveur réel à laquelle la demande du client est adressée, en lui passant les arguments reçus sur le réseau.
Une fois la procédure terminée, le contrôle retourne au stub du serveur, en lui passant les paramètres requis. Comme un talon de client; le stub de serveur convertit les valeurs renvoyées par la procédure pour former un message de réponse réseau qui est envoyé sur le réseau au système d'où provient la demande.
Le système d'exploitation transmet le message reçu au stub client qui, après la transformation nécessaire, transmet les valeurs (qui sont les valeurs renvoyées par la procédure distante) au client, qui interprète cela comme un retour normal de la procédure.

Ainsi, du point de vue du client, il effectue un appel de procédure à distance comme il le ferait pour un appel local. On peut dire la même chose du serveur: la procédure est appelée de manière standard, un objet (stub de serveur) appelle la procédure locale et reçoit les valeurs renvoyées par elle. Le client traite le stub comme une procédure serveur appelable et le serveur interprète son propre stub en tant que client.

Ainsi, les stubs constituent le cœur du système RPC, responsable de tous les aspects de la génération et de la transmission des messages entre le client et le serveur distant (procédure), bien que le client et le serveur supposent tous deux que les appels sont effectués localement. C'est le concept de base de RPC - pour cacher complètement la nature distribuée (réseau) de l'interaction dans le code de stub. Les avantages de cette approche sont évidents: le client et le serveur sont indépendants de implémentation réseaules deux s'exécutent dans une machine virtuelle distribuée et les appels de procédure ont une interface standard.

Passer des paramètres

Passer des paramètres de valeur est simple. Dans ce cas, le stub client place la valeur du paramètre dans la requête réseau, effectuant éventuellement des conversions vers le formulaire standard (par exemple, en modifiant l'ordre des octets). La situation avec le passage de pointeurs est beaucoup plus compliquée lorsque le paramètre est l'adresse des données, et non leur valeur. Passer une adresse dans une requête n'a pas de sens, puisque la procédure distante est exécutée dans un espace d'adressage complètement différent. La solution RPC la plus simple consiste à empêcher les clients de passer des paramètres autrement que par valeur, bien que cela impose certainement de sérieuses restrictions.

Contraignant

Avant qu'un client puisse appeler une procédure distante, il doit se lier au système distant hébergeant le serveur souhaité. Ainsi, la tâche de liaison est divisée en deux:

Recherche de l'hôte distant avec le serveur requis
Recherche du processus serveur requis sur un hôte donné

Différentes approches peuvent être utilisées pour trouver un hôte. Une option possible est de créer une sorte de répertoire centralisé dans lequel les hôtes annoncent leurs serveurs, et où le client, s'il le souhaite, peut choisir une adresse d'hôte et de procédure qui lui convient.

Chaque procédure RPC est identifiée de manière unique par un numéro de programme et de procédure. Le numéro de programme définit un groupe de procédures distantes, chacune avec son propre numéro. Chaque programme se voit également attribuer un numéro de version, de sorte que lorsque des modifications mineures sont apportées au programme (par exemple, lorsqu'une procédure est ajoutée), il n'est pas nécessaire de changer son numéro. Typiquement, plusieurs procédures fonctionnellement similaires sont implémentées dans un module de programme qui, une fois lancé, devient le serveur de ces procédures et qui est identifié par le numéro de programme.

Ainsi, lorsqu'un client souhaite appeler une procédure distante, il doit connaître les numéros de programme, de version et de procédure qui fournissent le service requis.

Pour transmettre la demande, le client doit également connaître l'adresse réseau de l'hôte et le numéro de port associé au programme serveur fournissant les procédures requises. Ceci est fait en utilisant le démon portmap (IM) (appelé rpcbind (IM) sur certains systèmes). Le démon s'exécute sur l'hôte qui fournit le service de procédure à distance et utilise un numéro de port connu. Lorsqu'un processus serveur s'initialise, il enregistre ses routines et ses numéros de port avec portmap (IM). Désormais, lorsque le client a besoin de connaître le numéro de port pour appeler une procédure particulière, il envoie une requête au serveur portmap (IM), qui à son tour renvoie le numéro de port ou redirige la requête directement vers le serveur RPC et renvoie une réponse au client lors de son exécution. Dans tous les cas, si la procédure requise existe, le client reçoit le numéro de port de la procédure du serveur portmap (IM), et d'autres demandes peuvent être effectuées directement sur ce port.

Gérer les exceptions

La gestion des exceptions lors de l'appel des procédures locales n'est pas particulièrement problématique. UNIX gère les erreurs de processus telles que la division par zéro, les accès mémoire non valides, etc. L'appel d'une procédure distante augmente la probabilité de situations d'erreur. En plus des erreurs de serveur et de stub, des erreurs liées, par exemple, à la réception d'un message réseau erroné sont ajoutées.

Par exemple, lorsque vous utilisez UDP comme protocole de transport, les messages sont retransmis après un délai spécifié. Une erreur est renvoyée au client si, après un certain nombre de tentatives, une réponse du serveur n'a pas été reçue. Dans le cas où le protocole TCP est utilisé, une erreur est renvoyée au client si le serveur a mis fin à la connexion TCP.

Sémantique des appels

L'appel d'une procédure locale conduit sans ambiguïté à son exécution, après quoi le contrôle revient au programme principal. La situation est différente lors de l'appel d'une procédure distante. Il est impossible de déterminer quand exactement la procédure sera exécutée, si elle sera exécutée du tout, et si oui, combien de fois? Par exemple, si la demande est reçue par le système distant après la fin anormale du programme serveur, la procédure ne sera pas exécutée du tout. Si le client, après ne pas avoir reçu de réponse après un certain laps de temps (timeout), renvoie une demande, alors une situation peut se produire lorsque la réponse est déjà transmise sur le réseau, et la demande répétée est à nouveau acceptée pour traitement par la procédure distante. Dans ce cas, la procédure sera effectuée plusieurs fois.

Ainsi, l'exécution d'une procédure distante peut être caractérisée par la sémantique suivante:

Une et une seule fois. Ce comportement (dans certains cas le plus souhaitable) est difficile à appliquer en raison de possibles pannes de serveur.
Temps maximum. Cela signifie que la procédure n'a pas été exécutée du tout ou n'a été effectuée qu'une seule fois. Une déclaration similaire peut être faite lorsqu'une erreur est reçue au lieu d'une réponse normale.
Au moins une fois. La procédure a probablement été effectuée une fois, mais plus est possible. Pour travail normal dans une telle situation, la procédure distante doit avoir la propriété idempotency (de l'anglais idemponent). Cette propriété est possédée par une procédure dont l'exécution répétée n'entraîne pas de changements cumulatifs. Par exemple, la lecture d'un fichier est idempotente, mais l'ajout de texte à un fichier ne l'est pas.

Présentation des données

Lorsque le client et le serveur s'exécutent sur le même système sur le même ordinateur, il n'y a aucun problème d'incompatibilité des données. Les données binaires sont représentées de la même manière pour le client et le serveur. Dans le cas d'un appel distant, le problème est compliqué par le fait que le client et le serveur peuvent fonctionner sur des systèmes avec des architectures différentes avec des représentations de données différentes (par exemple, représentation en virgule flottante, ordre des octets, etc.)

La plupart des implémentations de système RPC définissent types standard des représentations de données vers lesquelles toutes les valeurs transmises dans les demandes et les réponses doivent être converties.

Par exemple, le format de représentation des données dans RPC à partir de Sun Microsystems est le suivant:

Ordre des octets - Le plus important - Dernier
Représentation en virgule flottante - IEEE
Représentation de caractères - ASCII

Net

En termes de fonctionnalité, le système RPC est intermédiaire entre la couche application et la couche transport. Selon le modèle OSI, cette disposition correspond aux couches présentation et session. Ainsi, RPC est théoriquement indépendant de l'implémentation du réseau, en particulier de protocoles réseau couche de transport.

Les implémentations logicielles du système, en règle générale, prennent en charge un ou deux protocoles. Par exemple, le système RPC de Sun Microsystems prend en charge le transfert de messages à l'aide des protocoles TCP et UDP. Le choix d'un protocole particulier dépend des exigences de l'application. Le choix d'UDP est justifié pour les applications présentant les caractéristiques suivantes:

Les procédures appelées sont idempotentes
La taille des arguments passés et le résultat renvoyé sont inférieurs à la taille du paquet UDP - 8 Ko.
Le serveur permet de travailler avec plusieurs centaines de clients. Étant donné que, lorsqu'il travaille avec les protocoles TCP, le serveur est obligé de maintenir une connexion avec chacun des clients actifs, cela occupe une part importante de ses ressources. UDP est moins gourmand en ressources à cet égard

D'autre part, TCP assure un fonctionnement efficace des applications avec les caractéristiques suivantes:

L'application nécessite un protocole de transfert fiable
Les procédures appelées ne sont pas des composants
Les arguments ou le résultat renvoyé sont supérieurs à 8 Ko

Le choix du protocole est généralement laissé au client et le système organise la formation et la transmission des messages de différentes manières. Ainsi, lors de l'utilisation du protocole TCP, pour lequel les données transmises sont un flux d'octets, il est nécessaire de séparer les messages les uns des autres. Pour cela, par exemple, le protocole d'étiquetage d'enregistrement décrit dans RFC1057 «RPC: spécification du protocole d'appel de procédure distante version 2» est utilisé, qui précède chaque message avec un entier de 32 bits spécifiant la taille du message en octets.

La situation est différente avec la sémantique de l'appel. Par exemple, si le RPC est effectué à l'aide d'un protocole de transport non fiable (UDP), le système retransmet le message à de courts intervalles (délais d'attente). Si l'application cliente ne reçoit pas de réponse, alors il est prudent de dire que la procédure a été exécutée zéro ou plusieurs fois. Si une réponse a été reçue, l'application peut conclure que la procédure a été exécutée au moins une fois. Lors de l'utilisation du protocole de transport fiable (TCP), si une réponse est reçue, on peut dire que la procédure a été exécutée une fois. Si aucune réponse n'est reçue, il est impossible de dire avec certitude que la procédure n'a pas été effectuée3.

Comment ça fonctionne?

Essentiellement, le système RPC réel est intégré au programme client et au programme serveur. Il est gratifiant que lors du développement d'applications distribuées, vous n'ayez pas à vous plonger dans les détails du protocole RPC ou du traitement des messages du programme. Le système suppose l'existence d'un environnement de développement approprié, ce qui facilite grandement la vie des créateurs de logiciels d'application. L'un des points clés de RPC est que le développement d'une application distribuée commence par la définition d'une interface objet - une description formelle des fonctions du serveur, écrite dans un langage spécial. Les stubs client et serveur sont ensuite générés automatiquement à partir de cette interface. La seule chose à faire après cela est d'écrire le code de procédure réel.

Prenons l'exemple du RPC de Sun Microsystems. Le système se compose de trois parties principales:

rpcgen (1) est un compilateur RPC qui génère des stubs client et serveur sous la forme de programmes C basés sur la description de l'interface de procédure distante.
Bibliothèque XDR (eXternal Data Representation), qui contient des fonctions de conversion de différents types de données en une forme indépendante de la machine, permettant l'échange d'informations entre des systèmes hétérogènes.
Une bibliothèque de modules garantissant le fonctionnement du système dans son ensemble.

Regardons un exemple d'application de base de journalisation d'événements distribués. Le client, une fois démarré, appelle la procédure distante pour écrire un message dans le fichier journal de l'ordinateur distant.

Pour ce faire, vous devrez créer au moins trois fichiers: la spécification des interfaces des procédures distantes log.x (dans le langage de description de l'interface), le texte réel des procédures distantes log.c et le texte du programme client principal main () - client.c (en langage C).

Le compilateur rpcgen (l) génère trois fichiers basés sur la spécification log.x: le texte de stub client et serveur C (log clnt.c et log svc.c) et le fichier de définition log.h utilisé par les deux stubs.

Alors, regardons le code source des programmes.

Ce fichier spécifie les paramètres d'enregistrement de la procédure distante - numéros de programme, de version et de procédure - et définit l'interface appelante - arguments d'entrée et valeurs de retour. Ainsi, la procédure RLOG est définie, qui prend une chaîne comme argument (qui sera écrite dans le journal), et la valeur de retour, par défaut, indique le succès ou l'échec de l'opération ordonnée.

programme LOG_PROG ( version LOG_VER ( int RLOG (chaîne) \u003d 1; ) \u003d 1; ) \u003d 0x31234567;

Le compilateur rpcgen (l) génère un fichier d'en-tête log.h où, en particulier, les procédures sont définies:

Examinons de plus près ce fichier. Le compilateur traduit le nom RLOG défini dans le descripteur d'interface en rlog_1, en remplaçant les majuscules par des minuscules et en ajoutant le numéro de version du programme par un trait de soulignement. Le type de retour est passé de int à int *. C'est la règle - RPC vous permet d'envoyer et de recevoir uniquement les adresses des paramètres déclarés lors de la description de l'interface. La même règle s'applique à la chaîne passée en argument. Bien que cela ne découle pas du fichier print.h, en fait, l'adresse de la ligne est également passée en argument à la fonction rlog_l ().

En plus du fichier d'en-tête, le compilateur rpcgen (l) génère des modules stub client et serveur. Essentiellement, le texte de ces fichiers contient tout le code d'appel distant.

Le stub de serveur est le programme principal qui gère toutes les interactions réseau avec le client (plus précisément, avec son stub). Pour effectuer l'opération, le stub du serveur effectue un appel local à la fonction, dont le texte doit être écrit:

Le stub client prend un argument passé à la procédure distante, effectue les transformations nécessaires, émet une requête au serveur portmap (1M), communique avec le serveur de procédure distant et transmet finalement la valeur de retour au client. Pour le client, un appel de procédure à distance est un appel de stub et n'est pas différent d'un appel local normal.

client.c

#comprendre #comprendre "log.h" principale(int argc, carboniser * argv) (CLIENT * cl; carboniser * serveur, * mystring, * clnttime; time_t bintime; int * résultat; si (argc! \u003d 2) (fprintf (stderr, "Format d'appel:% s adresse_hôte \\ n", argv); exit (1);) serveur \u003d argv; / * Récupère le descripteur du client. En cas de panne, nous vous informerons de l'impossibilité d'établir la connexion avec le serveur * / si ((c1 \u003d clnt_create (serveur, LOG_PROG, LOG_VER, "udp")) \u003d\u003d NULL) (clnt_pcreateerror (serveur); exit (2);) / * Alloue un tampon pour la chaîne * / mystring \u003d ( carboniser *) malloc (100); / * Détermine l'heure de l'événement * / bintime \u003d temps ((time_t *) NULL); clnttime \u003d ctime (& bintime); sprintf (mystring, "% s - Client démarré", clnttime); / * Envoyons un message pour le journal - l'heure à laquelle le client a commencé à travailler. En cas d'échec, nous vous signalerons une erreur * / si ((résultat \u003d rlog_l (& mystring, cl)) \u003d\u003d NUL) (fprintf (stderr, "erreur2 \\ n"); clnt_perror (cl, serveur); exit (3);) / * En cas de panne sur l'ordinateur distant, nous vous signalerons une erreur * / si (* result! \u003d 0) fprintf (stderr, "Erreur d'écriture dans le journal \\ n"); / * 0 libère le descripteur * / cint détruire (cl); sortie (0); )

Le stub client log_clnt.c est compilé avec le module client.c pour obtenir l'exécutable client.

Maintenant, sur un serveur hôte.nowhere.ru, vous devez démarrer le processus serveur:

$ enregistreur

Ensuite, lorsque le client rlog démarre sur une autre machine, le serveur ajoute l'entrée correspondante au fichier journal.

Le schéma de fonctionnement RPC dans ce cas est illustré à la Fig. 1. Les modules interagissent comme suit:

Lorsque le processus serveur démarre, il crée un socket UDP et lie tout port local à ce socket. Le serveur appelle ensuite la fonction de bibliothèque svc_register (3N) pour enregistrer les numéros de programme et les numéros de version. Pour ce faire, la fonction appelle le processus portmap (IM) et transmet les valeurs requises. Le serveur portmap (IM) est généralement démarré à l'initialisation du système et se lie à un port bien connu. Portmap (3N) connaît désormais le numéro de port de notre programme et de sa version. Le serveur attend la demande. Notez que toutes les actions décrites sont effectuées par un stub de serveur généré par le compilateur rpcgen (IM).
Lorsque rlog démarre, la première chose qu'il fait est d'appeler la fonction de bibliothèque clnt_create (3N), en lui donnant l'adresse du système distant, les numéros de programme et de version, et le protocole de transport. La fonction envoie une requête au serveur portmap (IM) du système distant server.nowhere.m et obtient le numéro de port distant pour le serveur de journalisation.
Le client appelle la routine rlog_1 () définie dans le stub client et transfère le contrôle vers le stub. Cela, à son tour, forme la demande (conversion des arguments au format XDR) sous la forme d'un paquet UDP et la transmet au port distant reçu du serveur portmap (IM). Ensuite, il attend une réponse pendant un certain temps et, s'il n'est pas reçu, renvoie la demande. Dans des circonstances favorables, la demande est acceptée par le serveur de journalisation (module de stub de serveur). Le stub identifie la fonction appelée (par le numéro de la procédure) et appelle la fonction rlog_1 () du module log.c. Une fois le contrôle revenu au stub, le stub convertit la valeur renvoyée par la fonction rlog_1 () au format XDR et forme la réponse également sous la forme d'un paquet UDP. À la réception de la réponse, le stub client extrait la valeur retournée, la transforme et la renvoie à l'hôte client