Chapitre 3: LES APPELS DE PROCÉDURE DISTANTS Contexte Les systèmes distribues modernes consistent souvent en des milliers voire des millions de processus disperses sur des réseaux peu fiables. → Comment peuvent-ils communiquer ? Une solution = Les RPCs (Remote Procedure Call) – Un modele tres repondu de communication entre des processus d’un systeme distribue ● Objectif : Un processus appel localement une procédure qui est réellement implémentée sur une machine distante Rappel du schéma CS Appel synchrone Requête-Réponse ! Mise en oeuvre Bas niveau : utilisation directe du transport : sockets (construit sur TCP ou UDP) ! " Exemple : utilisation des sockets en C Haut niveau : intégration dans un langage de programmation : RPC (construit sur sockets) ! " Exemple : RPC en C Définition Appel de procédure à distance (Remote Procedure Call, ou RPC) : un outil pour construire des applications client-serveur dans un langage de haut niveau ! L’appel et le retour ont lieu sur un site , l’exécution se déroule sur un site distinct L’effet de l’appel doit être identique dans les deux situations (local et distant) Les RPCs Objectif : permettre aux programmes d’appeler des procedures situees sur d'autres machines. ● Lorsqu'un processus sur la machine A appelle une procedure sur le machine B, le processus d'appel sur A est suspendu et l'execution de la procedure a lieu sur B. ● Les informations sont acheminees dans les parametres et les resultats de la procedu – Aucune transmission de message n’est visible au programmeur. Les approches à RPC SUN ONC/RPC Open Network Computing / Remote Procedure Call OSF DCE Open Software Foundation - Distributed Computing Environnment Systèmes de gestion de bases de données: procédures stockées. OMG CORBA Object Management Group - Common Object Request Broker Architecture SUN Java RMI ❙ Remote Method Invocation MOM –Middleware Oriented Message Microsoft - DCOM Distributed Component Object Mod Avantages attendus Facilité de programmation ! La complexité des protocoles de communication est cachée ! Ne pas avoir à programmer des échanges au niveau réseau ! ! Facilité de mise au point : une application peut être mise au point sur un site unique, puis déployée sur plusieurs sites ! Portabilité : résulte de l’usage d’un langage de haut niveau ! Indépendance par rapport au système de communication Problèmes de réalisation ! Transmission des paramètres ! conversion entre la forme interne, propre à un langage, et une forme adaptée à la transmission ! Gestion des processus ! Séquentielle et parallèle ! Réaction aux défaillances ! Trois modes de défaillance indépendants : client, serveur, réseau Mise en œuvre 1. Par migration 2. Par mémoire partagée 3. Par messages 4. Par appel léger (LRPC) Réalisation par migration Stratégie de migration ! Le code et les données de la procédure distante sont amenés sur le site appelant pour y être exécutés par un appel local habituel. ! Analogie ! Stratégie de pré-chargement en mémoire. ! Avantages ! Très efficace pour de nombreux appels ! Inconvénients ! Univers d’exécutions homogènes (ex machine virtuelle). ! Performances selon le volume de codes et de données. ! Problèmes de partage des objets. Réalisation en mémoire partagée répartie L’appel distant est réalisé en utilisant une mémoire virtuelle partagée répartie La procédure est installée pour le client comme pour le serveur dans la mémoire virtuelle partagée répartie. Mais, réellement, elle est dans l’espace mémoire du serveur. L’appel du client se fait comme si la procédure était locale, provoquant un premier défaut de page sur le début du code de la procédure. Le code et les données de la procédure distante sont amenés page par page sur le site appelant selon le parcours du code et des données. ! Analogie avec une stratégie page à la demande. 2 Réalisation par messages Deux messages (au moins) échangés : requête et réponse Le premier message correspondant à la requête est celui de l'appel de procédure, porteur des paramètres d'appel. Le second message correspondant à la réponse est celui du retour de procédure porteur des paramètres résultats. Notion des souches (1/2) Un mode de réalisation par interception (wrapping) ! Une procédure intercepteur (wrapper) intercepte l’appel d’un client vers un serveur et modifie le traitement serveur à sa guise ! Décomposition en traitements avant et après le traitement serveur ! Décomposition en intercepteur coté client, souche client, et intercepteur coté serveur, souche serveur ! Souches (ou Stubs) =Talons = Squelettes (ou Skeletons)… Notion des souches (2/2) La souche client ("client stub") Intercepteur (procédure) coté client qui reçoit l’appel en mode local, Le transforme en appel distant, Envoie message d’appel de procédure, Reçoit le message contenant les résultats après l’exécution, Retourne les résultats comme dans un retour local de procédure. La souche serveur ("server stub") Intercepteur (procédure) coté serveur qui reçoit le message d’appel, Fait réaliser l’exécution sur le site serveur par la procédure Etapes de RPC par messages (1/2) Étape 1 : Le client réalise un appel procédural vers la procédure souche client, la souche client collecte les paramètres , les emballe dans le message d’appel ! Étape 2 : La souche client demande à une entité de transport locale la transmission du message d'appel ! Étape 3 : Le message d’appel est transmis sur un réseau au site serveur Étape 4 : Le message d’appel est délivré à la souche serveur La souche serveur déballe les paramètres ! Étape 5 : La souche serveur réalise l’appel effectif de la procédure serveur Etapes de RPC par messages (2/2) Étape 6 La procédure serveur ayant terminé son exécution transmet à la souche serveur dans son retour de procédure les paramètres résultats. La souche serveur collecte les paramètres retour, les emballe dans un message. ! Étape 7 La procédure souche serveur demande à l ’entité de transport serveur la transmission du message de réponse. Étape 8 : Le message de réponse est transmis sur un réseau au site client. ! Étape 9 : Le message de réponse est délivré à la souche client. La souche client déballe les paramètres résultats. ! Étape 10 : La procédure souche client transmet les résultats au client en effectuant un retour habituel de procédure en mode local. ! Diagramme de RPC par messages Les talons (ou souches) client et serveur sont créés (générés automatiquement) à part d’une description d’interface Description d’interface ! Interface = “contrat” entre client et serveur ! Définition commune abstraite ! Indépendante d’un langage particulier (adaptée à des langages multiples) ! Indépendante de la représentation des types ! Indépendante de la machine (hétérogénéité) ! Contenu minimal ! Identification des procédures (nom, version) ! Définition des types des paramètres, résultats ! Définition du mode de passage (IN, OUT, IN-OUT) ! Extensions possibles ! Procédures de conversion pour types complexes RPC par message ! Avantages ! Applicable en univers hétérogènes moyennant des conversions ! Partage d’accès sur le site serveur ! Inconvénients ! Pas d’usage des pointeurs dans les paramètres ! Échange de données complexes/de grande taille délicat ! Peu efficace pour de très nombreux appels Lightweight RPC (LRPC) Quand on appelle un serveur qui se trouve sur la même machine, la traversée des couches réseaux est inutile et coûteuse # Optimisation de la communication ! Problème: Client et Serveur (2 processus) qui se trouvent dans deux domaines de protection différents ! ! Solution: la communication réseau est réalisée par un segment de mémoire partagée entre le client et le serveur qui contient une pile pour les paramètres d’appel et de réponse. ! LRPC: principe de RPC mais entre processus locaux s'exécutant sur la même machine Lightweight RPC (LRPC) ! Avantages ! Transmission d’appel très performant comme mode de RPC local. ! Limites ! Uniquement applicable dans une même machine. Synthèse sur les modes de réalisation ! RPC par messages : Le premier modèle implémenté ! Supporte l’hétérogénéité ! Le plus simple à réaliser ! " RPC, RMI, DCE, CORBA, DCOM, SOAP Des optimisations peuvent être obtenues par l’usage des autres solutions ! ! Exemple : a développé les quatre solutions. " DCOM a développé RPC par messages + LRPC " Chorus “ Transmission des arguments ” Transmission par valeur Le seul mode de transmission des données dans les messages en réseau ! Si le client et le serveur utilisent des formats de de données différents $ Conversion ! Définition du couple syntaxe abstraite/syntaxe de transfert des données échangées: ! ! Syntaxe abstraite ! analogue à celles des langages évolués, ! facile à générer pour un développeur d’application ! À partir de la syntaxe abstraite : codage/décodage de la syntaxe de Transfert ! Syntaxe de transfert : une représentation lexicale des données simples et une convention d’alignement (emballage/déballage) des Transmission par valeur dans l’appel de procédure distante En appel de procédure distante : ! génération automatique du code des souches à partir de la syntaxe abstraite ! les souches fabriquent la syntaxe de transfert en réalisant l’alignement (emballage/déballage) des paramètres dans les messages. ! Définition des nouveaux langages de syntaxe abstraite adaptés aux appels de procédure distante : Interface Definition Language (IDL) Pourquoi les langages IDL ? ! Être indépendant des langages évolués utilisant le RPC ! Permettre l’appel distant avec tout langage évolué ! Définition d’un langage pivot (intermédiaire) de description de données ayant des fonctionnalités assez riches pour les langages les plus récents. ! Notion de correspondance entre les types d’IDL et les types des langages existants Exemples d’IDL et de format de présentation en RPC ! SUN RPC ! RPCL - XDR eXternal Data Representation ! OSF DCE ! IDL DCE - Format NDR Network Data Representation ! OMG CORBA IDL Corba - Format CDR Common Data Representation, Protocole IIOP ! ! SUN Java RMI ! Java - Protocole JRMP Java Remote Method Protocol ! Microsoft DCOM MIDL Microsoft IDL - DCOM Protocole ORPC Object RPC Format NDR ! ! Services Web ! Web Services Definition Language (WSDL) – SOAP Autres modes de transmission : passage par adresse Le passage par adresse utilise une adresse mémoire centrale du site de l’appelant qui n’a aucun sens sur l’appelé (sauf cas particulier) ! 3 solutions : ! Interdiction totale des pointeurs "La solution la plus répandu ! Passage par adresse en mémoire virtuelle partagée répartie ! Simulation du passage par adresse en utilisant une copie restauration Simulation par copie restauration A l’appel: copie des valeurs des paramètres de l’appelant vers l’appelé ! Au retour: copie de nouvelles valeurs pour les paramètres de l’appelé vers l’appelant ! Marche bien dans beaucoup de cas mais violation dans certains cas de la sémantique du passage Simulation par copie restauration Exemple du problème de violation procédure double_incr ( x , y ) ; x , y : entier ; début x := x + 1 ; y := y + 1 ; fin ; Séquence d’appel : passage par adresse a := 0 ; double_incr ( a , a ) ; Résultat attendu : a = 2 Utilisation d’une copie restauration Résultat obtenu : a = 1 ! “ Désignation et liaison ” Désignation La structuration des noms et références permet de désigner les services distants : Nom symbolique : une chaîne de caractères désignant la procédure dans un annuaire ou serveur de nom Référence Référence : selon l’implantation considérée: Désignation du protocole permettant l’accès distant (TCP ou UDP) Désignation de l’hôte où se trouve le serveur (adresse IP) Désignation du point d’accès de service transport (numéro de port) : une structure de données permettant de réaliser l’appel Désignation de la procédure Serveur de nom : une table qui assure la correspondance entre nom symbolique et référence Liaison Moment de liaison : précoce (statique) ou tardive (dynamique) Statique : localisation du serveur connue à la compilation pas d’appel à un serveur de noms (ou appel à la compilation) Dynamique : localisation au moment de l’exécution, non connue à la compilation Désignation symbolique des services (non liée à un site d’exécution) Liaison au premier appel : consultation du serveur de noms au premier appel seulement Liaison à chaque appel : consultation du serveur de noms à chaque appel 1, 2 : le serveur s’enregistre auprès de l’annuaire avec nom, @serveur, #port 3, 4, 5 : le client consulte l’annuaire pour trouver @serveur, #port à partir du nom symbolique L’appel peut alors avoir lieu RPC : désignation et liaison utilisant le portmapper Si le serveur est connu (cas fréquent): on peut utiliser un service de nommage local au serveur, le portmapper Un service enregistre le n° de port de son veilleur auprès du portmapper et le veilleur se met en attente sur ce port Le portmapper a un n° de port fixé par convention (111) Solution proposée par les RPC ONC, un programme de binding (RFC 1823) : le portmapper (version 2) : spécifique à TCP/UDP: le portmapper est lui-même un serveur rpc. rpcbind (versions 3 et 4) : indépendant du transport “ Gestion du contrôle ” Contrôle client : RPC en mode synchrone L’exécution du client est suspendue tant que la réponse du serveur n’est pas revenue ou qu’une condition d’exception n’a pas entraîné un traitement spécifique Avantage : le flot de contrôle est le même que dans l’appel en mode centralisé. Inconvénient : le client reste inactif. Solution au problème de l’inactivité du client : création des activités concurrentes Création de (au moins) deux activités (« processus léger » ou « threads ») sur le site client: L’une occupe le site appelant par un travail à faire. L’autre gère l’appel en mode synchrone en restant bloquée : Le fonctionnement est exactement celui d’un appel habituel. Contrôle client : RPC en mode asynchrone Le client poursuit son exécution immédiatement après l’émission du message porteur de l’appel La procédure distante s’exécute en parallèle avec la poursuite du client Le client doit récupérer les résultats quand il en a besoin Contrôle serveur : exécution séquentielle des appels Les requêtes d’exécution sont traitées l’une après l’autre par le serveur exclusion mutuelle entre les traitements. Si la couche transport assure la livraison en séquence et que l’on gère une file d’attente « FIFO : premier arrivé premier servi », on a un traitement ordonné des suites d’appels. Contrôle serveur: exécution parallèle des appels le serveur créé un processus ou une activité (« processus léger » ou « thread ») pour chaque appel Gestion possible de pool de processus ou d’activités Les appels sont exécutés en parallèle. Si les procédures manipulent des données globales persistantes sur le site serveur, le contrôle de concurrence doit être géré.
