1.1 Remote Procedure Call (RPC)

Copyright (C) 1997-2007. JM Rodriguez. Tous droits réservés. Reproduction interdite par tous moyens sauf à des
fins de citation.
1.1 Remote Procedure Call (RPC)
Le modèle Client-Serveur est un modèle simple à utiliser pour la structuration des
systèmes répartis.
Mais ce modèle s’appuie sur des communications de type entrée/sortie (SEND /
RECEIVE). Ce n’est pas le modèle plus efficace pour les systèmes répartis car son but
est de rendre le comportement des systèmes répartis identique à celui des systèmes
centralisés.
1.1.1 Fonctionnement d’un appel à procédure (machine unique)
Count = read ( fd, buf, nbytes) ;
• fd = entier.
• Buf = Tableau de caractères.
• Nbytes = entier.
1. Lorsque le programme principal appelle la procédure read il place les
paramètres dans la pile.
2. Lorsque la procédure read a terminé son traitement, elle :
• Place le résultat dans un registre.
• Efface l’adresse de retour.
• Rend la main à l’appelant.
3. L’appelant enlève les paramètres de la pile pour retourner à son état original.
Les paramètres peuvent être passés :
• Par valeur.
• Par référence.
• Par Copy / restore.
1.1.2 Fonctionnement du RPC
On veut que l’appel à une procédure distante se fasse comme si l’appel était local.
Même si cela doit être transparent pour l’utilisateur, il est nécessaire que le mécanisme
RPC mette en place des versions différentes pour l’appel d’une procédure selon qu’elle
soit locale ou distante.
On va donc avoir une souche client (client stub) et une souche serveur (server stub).
Souche Client :
• La version cliente de la procédure est constituée d’une souche cliente (« client
stub ») qui est placée dans la librairie locale.
• L’appel se fait ensuite comme avec une procédure locale (la pile est gérée
localement) et l’exécution est prise en charge par le noyau.
• Par contre, les paramètres ne sont pas stockés dans les registres et aucune
donnée n’est demandée au noyau.
Jean-Michel Rodriguez
Systèmes et applications répartis
2002-2007
Copyright (C) 1997-2007. JM Rodriguez. Tous droits réservés. Reproduction interdite par tous moyens sauf à des
fins de citation.
•
•
Les paramètres sont stockés dans un message construit par le noyau et envoyé au
serveur distant qui contient la partie serveur de la procédure.
Le client attend ensuite que le serveur lui réponde.
Souche Serveur :
• La version serveur de la procédure est constituée d’une souche serveur et de la
procédure.
• Lorsque le message parvient au serveur, le noyau passe le message à la souche
correspondante (qui est en attente de messages).
• La souche extrait les paramètres du message, renseigne la pile et appelle la
procédure qui pense être appelée par un client local.
• Lorsque la procédure a terminé son traitement, elle renseigne la pile et rend la
main à la souche (voir schéma suivant).
La création des souches (stubs) est de la responsabilité du compilateur.
À la compilation les stubs sont créés et le compilateur peut s’aider d’un langage de
définition d’interfaces (IDL)
1.1.3 Le passage de paramètres
Le passage de paramètres dans le cadre des RPCS n’est pas forcément quelque chose de
simple.
Dans les systèmes répartis, les machines peuvent être différentes. Des problèmes de
conversion peuvent apparaître.
La problématique va donc être de connaître le format du message et la plateforme
cliente :
• Le premier octet (Byte) du message détermine le format utilisé par le client.
• Le serveur compare cet octet avec le sien : Si c’est le même aucune
transformation n’est nécessaire, sinon il effectue la transformation.
Jean-Michel Rodriguez
Systèmes et applications répartis
2/8
2002-2007
Copyright (C) 1997-2007. JM Rodriguez. Tous droits réservés. Reproduction interdite par tous moyens sauf à des
fins de citation.
1.1.3.1 Passage de pointeurs en paramètres
Le pointeur (adresse) n’est connu que dans l’espace d’adressage du processus qui le
crée. Cette adresse n’est valide que dans la machine où s’exécute le processus.
La souche client qui récupère un pointeur, copie le contenu de la zone adressée dans le
message. Au retour elle place le résultat dans la zone.
1.1.4 Localisation du serveur
La localisation d’un serveur peut se faire de différentes manières :
• Statique : Codée en dur l’adresse du serveur dans le client. En cas de
changement de l’adresse, le client doit être recompilé (les programmes qui
accèdent au serveur).
• Dynamique : lien dynamique (dynamic binding). Ce lien permet de faire
dynamiquement connaître les clients et les serveurs.
1.1.4.1 Le lien dynamique
La construction du lien dynamique s’effectue en plusieurs étapes.
Définition de la spécification du serveur qui servira à la génération des souches.
À l’initialisation, le serveur exporte son interface. Il l’envoie à un binder (relieur) pour
signaler son existence.
C’est la phase d’enregistrement. Le serveur envoie ses informations :
• nom ;
• version identifiant (unique sur 32 bits en principe) ;
• handle (adresse IP, protocoles, etc.).
Lorsqu’un Client appelle une procédure pour la première fois :
• Il constate qu’il n’est pas relié à un serveur.
• Il envoie un message au relieur pour importer la version de la procédure qu’il
désire invoquer.
• Le relieur lui renvoie l’identifiant unique (ID) et le handle.
Avantage :
• Cette méthode d’importation et exportation des interfaces est très flexible.
• Les serveurs peuvent s’enregistrer ou se désenregistrer.
• Le client fournit le nom de la procédure et la version et il reçoit un ID unique et
handle.
1.1.5 Les problèmes liés aux RPCs dans les systèmes répartis.
1.
2.
3.
Le client ne peut pas localiser le serveur.
L’appel du client n’arrive pas au serveur.
La réponse du serveur n’arrive pas au client.
Le serveur est en panne :
Jean-Michel Rodriguez
Systèmes et applications répartis
3/8
2002-2007
Copyright (C) 1997-2007. JM Rodriguez. Tous droits réservés. Reproduction interdite par tous moyens sauf à des
fins de citation.
•
Il faut dissocier la panne avant l’exécution de la requête ou après l’exécution.
Trois écoles pour résoudre ce problème :
1. Attendre que le serveur redémarre et relancer le traitement.
« Au moins un traitement est réussi. » (peut-être plus).
2. Abandon du client et rapport de l’erreur.
« Au plus un traitement est réussi. » (peut-être aucun).
3. Ne rien dire au client (aucune garantie)
Seuls avantages : Facile à gérer et à implémenter.
En règle générale, crash du serveur = crash du client.
Le client est en panne :
Lorsqu’un client tombe en panne alors qu’il a demandé un traitement à un serveur, on
dit que l’échange devient orphelin.
Cela a pour effet de gaspiller du temps CPU, de bloquer des ressources, lorsqu’il
redémarre, il peut recevoir des messages antérieurs à la panne (problème de
confusion).
Quatre solutions peuvent être envisagées :
1. L’extermination : Le client enregistre les appels dans une log. Au redémarrage
l’orphelin est détruit.
Beaucoup d’écritures disque à chaque RPC.
2. La réincarnation : Le client tient compte du temps. Lorsqu’il redémarre, il
annule les échanges ente deux époques et reprend les échanges orphelins.
3. La réincarnation à l’amiable : Comme précédemment, avec en plus la
vérification avec le serveur concerné des échanges orphelins.
4. Expiration du délai : Un compteur de temps détermine quand un échange
devient orphelin. Les orphelins sont détruits.
Un temps T déterminé identique pour tous est donné à 1 RPC.
Difficile de choisir un temps T (les RPCs sont sur des réseaux différents).
1.1.6 Les protocoles RPC
Pour le protocole RPC un certain nombre de choix sont à faire.
1.1.6.1 Avec ou sans connexion.
Avec connexion
Avantages :
• Simple à utiliser.
• Pas d’ACK nécessaire.
• Pas de perte de paquets.
Désavantages :
• Trop difficile à mettre en place sur un WAN.
• Très pénalisant sur un LAN (performance pas bonne).
Note : Les systèmes répartis utilisent des protocoles sans connexion.
Jean-Michel Rodriguez
Systèmes et applications répartis
4/8
2002-2007
Copyright (C) 1997-2007. JM Rodriguez. Tous droits réservés. Reproduction interdite par tous moyens sauf à des
fins de citation.
1.1.6.2 Utilisation d’un protocole standard ou d’un protocole
propriétaire.
Protocole propriétaire = protocole conçu pour les RPCs.
Protocole standard (IP, TCP, UDP)
Avantages :
• Déjà construit.
• Implémentation effectuée et disponible.
• Utilisable par tous les systèmes (UNIX, Windows, etc.).
• Supporté par la majorité des réseaux.
Désavantages :
• Protocoles peu performants.
• Conçus pour des connexions TCP.
Protocole propriétaires
Avantages :
• Evite les checksums.
• Longueur de paquets variables.
• Adapté au système (spécialisé).
Désavantages :
• Beaucoup de travail de développement.
• Difficile à faire adopter par les autres (nouveau protocole).
1.1.7 Accusé de réception
Si une RPC doit être découpée en plusieurs petits paquets.
4Ko de données à envoyer.
0
1
2
3
Choisir entre un accusé de réception par paquet. Attente accusé avant envoi suivant.
CLIENT
SERVEUR
0
ACK 0
1
ACK 0
2
ACK 0
3
Jean-Michel Rodriguez
Systèmes et applications répartis
5/8
2002-2007
Copyright (C) 1997-2007. JM Rodriguez. Tous droits réservés. Reproduction interdite par tous moyens sauf à des
fins de citation.
ACK 0
Si un problème est rencontré sur un paquet le client le renvoie.
Ou seul accusé de réception à la fin de l’envoi. Envoi aussi vite qu’il peut.
CLIENT
SERVEUR
0
1
2
3
ACK 0, 1, 2, 3
Si un problème est rencontré sur un paquet le serveur le redemande.
1.1.8 Le chemin critique
Le code de la RPC est crucial pour les performances du système.
La séquence d’instructions exécutées pour chaque RPC est appelée chemin critique.
C’est le temps nécessaire et rajouté par la RPC vs si le traitement était effectué en
local.
Ce chemin critique démarre quand le client appelle la souche client et se termine lorsque
le résultat est renvoyé par le serveur.
CLIENT
Appel de la souche
Client
SERVEUR
Exécution de la tâche.
Serveur
Prépare la mémoire tampon pour le
message (Buffer).
Groupe les paramètres dans le tampon.
Renseigne les entêtes du message.
Appel au noyau
Souche Client
Appelle la procédure serveur.
Prépare les paramètres dans la pile.
Dégroupe les paramètres. Souche
Passage au contexte noyau.
Copier le message dans la zone
Passage au contexte de la souche.
Copie le message dans la mémoire de
Serveur
Jean-Michel Rodriguez
Systèmes et applications répartis
6/8
2002-2007
Copyright (C) 1997-2007. JM Rodriguez. Tous droits réservés. Reproduction interdite par tous moyens sauf à des
fins de citation.
mémoire noyau.
Détermine l’adresse destination.
Place l’adresse dans l’entête du
message.
Initialise l’interface réseau.
Démarre le timer.
Noyau
la souche.
Verif que la souche est en réception.
Choisir la souche concernée.
Contrôle la validité du paquet.
Interruption.
Noyau
Note : La question intéressante ensuite est : Quelle est lapartie du chemmin critique où
l’on passe le plus de temps. La réponse permet de savoir où l’effort d’optmisation doiy
être fait. Voir graphes page 91 (sec2.4) du D.0.S Tanenbaum.
1.1.9 Gestion du temps (timer)
Tous les protocoles sont basés sur des échanges de messages sur les moyens de
communication. Les messages peuvent être perdus et créer de graves problèmes
d’intégrité dans le système.
Un des moyens de pallier ce problème est la mise en place d’un timer (gestion du
temps). Qui va associer un horodatage à chacun des messages et définir une durée de vie
(délai d’expiration). Si le temps imparti pour la durée de vie d’un message est écoulé, le
message sera renvoyé. Le nombre de renvois est défini dans le protocole.
Deux méthodes peuvent être envisagés :
1. Mise en place d’une structure spécifique.
2. Insertion d’un champ dans la table des processus.
1.1.9.1 Mise en place d’une structure spécifique
Une structure va être construite :
• Spécification de l’expiration.
• Quelles sont les actions à prendre en cas d’expiration.
• La structure sera insérée dans une liste existante (qui contient d’autres
structures).
La liste doit être surveillée.
La liste est triée par temps.
Lorsqu’un message est envoyé la liste est mise à jour.
Lorsqu’un accusé de réception ou une réponse revient,l’entrée est retirée de la table.
Note : Parce que la plupart du temps les timers n’ont pas le temps d’expirer, on perd
beaucoup de temps à insérer puis effacer les entrées non expirées. Donc une autre
approche peut être envisageé.
1.1.9.2 Insertion d’un champ dans la table des processus.
L’idée est de rajouter une entrée « expiration » dans la table des processus.
Jean-Michel Rodriguez
Systèmes et applications répartis
7/8
2002-2007
Copyright (C) 1997-2007. JM Rodriguez. Tous droits réservés. Reproduction interdite par tous moyens sauf à des
fins de citation.
La mise à jour des timers devient quelques instructions en langage machine. A
intervalles réguliers (toutes les secondes) le noyau parcourt la table et compare les
timers avec le temps courant.
1.1.10
Quelques problèmes liés aux RPCs
Principe de transparence
L’introduction d’un mécanisme RPC dans un système mono-processeur ne doit pas :
• Générer un nouvel ensemble de règles qui empêche la construction d’objets qui
était possible avant.
• Impliquer l’utilisation obligatoire d’objets optionnels auparavant.
Problème des variables globales :
• Comment peut-on accéder à des variables globales à partir de procédures
distantes ?
• Les accès doivent être construits. Le principe de transparence est donc violé.
Problème des paramètres variables :
Comment le passage de paramètres dont on ne connaît pas la taille à priori peut se
faire ? (Par exemple les tableaux en langage C).
Idée : On peut coder les longueurs en dur mais :
• Si taille des données < maxi : perte d’espace.
• Si taille des données > maxi : erreur.
Comment gérer le passage de pointeur sur un graphe complexe ?
Jean-Michel Rodriguez
Systèmes et applications répartis
8/8
2002-2007