1.1 Remote Procedure Call (RPC)

Transcription

1 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 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 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.

2 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) 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. 2/8

3 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 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 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 Les problèmes liés aux RPCs dans les systèmes répartis. 1. Le client ne peut pas localiser le serveur. 2. L appel du client n arrive pas au serveur. 3. La réponse du serveur n arrive pas au client. Le serveur est en panne : 3/8

4 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) Les protocoles RPC Pour le protocole RPC un certain nombre de choix sont à faire 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. 4/8

5 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) Accusé de réception Si une RPC doit être découpée en plusieurs petits paquets. 4Ko de données à envoyer Choisir entre un accusé de réception par paquet. Attente accusé avant envoi suivant. CLIENT 0 SERVEUR ACK ACK 0 ACK 0 5/8

6 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 ACK 0, 1, 2, 3 Si un problème est rencontré sur un paquet le serveur le redemande 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 Passage au contexte noyau. Copier le message dans la zone Souche Client Appelle la procédure serveur. Prépare les paramètres dans la pile. Dégroupe les paramètres. Souche Serveur Passage au contexte de la souche. Copie le message dans la mémoire de 6/8

7 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 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 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é Insertion d un champ dans la table des processus. L idée est de rajouter une entrée «expiration» dans la table des processus. 7/8

8 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 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? 8/8