Rappel du schéma client-serveur 2! Appel synchrone Requête-Réponse LES APPELS DE PROCÉDURE DISTANTS heithem.abbes@gmail.com! Mise en œuvre! 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 Avantages attendus! 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) 4! 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 Mise en œuvre 5 6! 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 1 2 4! Par migration! Par mémoire partagée! Par messages! Par appel léger (LRPC) Réalisation par migration 1 Réalisation en mémoire partagée répartie 2 7! 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. 8! 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.
Réalisation en mémoire partagée répartie 2 Réalisation par messages 9 10! Avantages! Efficace en cas de nombreux appels! Efficace si tout le code et les données ne sont pas visités! Résout le problème de l utilisation des pointeurs (références d adresses en mémoire)! Inconvénients! Univers de systèmes homogènes! Volume de codes et de données à échanger pages par pages! Problèmes de partage selon la cohérence de la mémoire répartie! 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) Notion des souches (2/2) 11! 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)! Objectif: transformer l appel local en un appel distant 12! 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 serveur,! Récupère les résultats et retransmet les résultats par message.
Etapes de RPC par messages (1/2) Etapes de RPC par messages (2/2) 14 15! É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 : 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! É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. 16 Diagramme de RPC par messages Description d interface 17 Talon (stub) client Les talons (ou souches) client et serveur sont créés (générés automatiquement) à partir d une description d interface Talon (stub) serveur! 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 Lightweight RPC (LRPC) 4 18 19! 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! 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) 4 Synthèse sur les modes de réalisation 20! Avantages! Transmission d appel très performant comme mode de RPC local.! Limites! Uniquement applicable dans une même machine. 21! 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 : " Chorus a développé les quatre solutions. " DCOM a développé RPC par messages + LRPC
22 Transmission des arguments 2 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 données commune au client et au serveur 24 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) 25 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
26 Génération des souches 27 Exemples d IDL et de format de présentation en RPC Source code client Compilateur (C, java,..) Définition de l interface en IDL Compilateur IDL Source code serveur Souche client Entête Souche serveur Compilateur (C, java,..) Compilateur (C, java,..) Compilateur (C, java,..)! 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 Binaire client Binaire souche client Binaire souche serveur Binaire serveur Autres modes de transmission : passage par adresse Simulation par copie restauration 28 29! 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)! 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! 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 0! 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 1 Désignation et liaison Désignation Liaison 2! 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 : une structure de données permettant de réaliser l appel! Moment de liaison : précoce (statique) ou tardive (dynamique)! Statique : " localisation du serveur connue à la compilation! 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)! Désignation de la procédure! Serveur de nom : une table qui assure la correspondance entre nom symbolique et référence " 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
Désignation & liaison Désignation & liaison 4 5! 1, 2 : le serveur s enregistre auprès de l annuaire avec nom, @serveur, #port!, 4, 5 : le client consulte l annuaire pour trouver @serveur, #port à partir du nom symbolique! L appel peut alors avoir lieu 6 Gestion du contrôle 7 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.
Contrôle client : RPC en mode synchrone Contrôle client : RPC en mode asynchrone 8 9! 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.! 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 Contrôle serveur: exécution parallèle des appels 40! 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. 41! 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é.
Gestion des données applicatives sans données partagées persistantes 4 42 Gestion des données! L appel de procédure s exécute en fonction des paramètres d entrée en produisant des paramètres résultats! Données locales à la procédure! Pas de modification de données persistantes sur le serveur! Situation très favorable, on n a pas à gérer:! la tolérance aux pannes! le contrôle de concurrence Gestion des données applicatives partagées persistantes Gestion des données protocolaires mode avec ou sans état 44 45! Les exécutions successives manipulent des données persistantes sur le serveur:! Une exécution modifie le contexte sur le serveur " Exemple: un serveur de fichier, de bases de données. # Problème de contrôle de concurrence # Problème des pannes en cours d exécution! La terminologie avec ou sans état porte sur l existence ou non d un descriptif pour chaque relation client serveur au niveau du serveur.! Notion d état : un ensemble de données persistantes au niveau du protocole pour chaque relation client serveur :! Permettrait de traiter les requêtes dans l ordre d émission.! Permettrait de traiter une requête en fonction des caractéristiques de la relation client serveur (qualité de service).
46 Mode sans état! Les appels successifs d une même procédure s exécutent sans liens entre eux! Chaque opération du point de vue du protocole s effectue sans référence au passé! Exemples! NFS "Network File System" de SUN " système de fichier réparti basé sur RPC sans état! HTTP "HyperText Transfer Protocol" " protocole d exécution de méthodes distantes sans état 47 Mode avec état! Les appels successifs s exécutent en fonction d un état de la relation client serveur laissé par les appels antérieurs! La gestion de l'ordre des requêtes est indispensable! Exemple :! Opérations d achat des produits sur Internet (payement électronique) Avantages des RPC 56 Conclusion 57! De plus haut niveau! Les détails de communication sont cachés.! Une structure de contrôle bien connue, l appel de procédure! Support naturel de l approche client-serveur! Qui s intègre à l univers réparti des concepts modernes de génie logiciel: approche objets, approches composants! Modularité, encapsulation, réutilisation par délégation.