Client-Serveur File - Plateforme e
Transcription
Client-Serveur File - Plateforme e
INSA - ASI InfoRep : Client-Serveur Informatique Répartie Architectures Client-Serveur Alexandre Pauchet INSA Rouen - Département ASI BO.B.RC.18, [email protected] 1/36 INSA - ASI InfoRep : Client-Serveur Programmation “classique” vs. Informatique Répartie 2/36 (1/6) Quelques constats Applications Client-Serveur La plupart des applications réseaux sont du type Client-Serveur Dans ce cadre, le client appelle un “service” auprès d’un serveur ⇒ la dénomination architectures orientées services existe par ailleurs ; elle désigne principalement les Services Web Exemples Un navigateur web demande une page html à un serveur Un client FTP demande la liste des fichiers et des répertoires contenus dans un répertoire etc. INSA - ASI InfoRep : Client-Serveur Programmation “classique” vs. Informatique Répartie 3/36 (2/6) Objectifs de l’Informatique Répartie Programmation “classique” En programmation classique lorsque qu’un programme a besoin d’un service, il appelle une fonction d’une librairie, une méthode d’un objet, etc. Objectif de l’Informatique Répartie Proposer des méthodes et outils pour simplifier le développement d’applications réseau Client-Serveur, en essayant de s’abstraire de l’aspect “distant” : proposer une programmation “naturelle” Pour les applications “lourdes” : Décomposer les applications en ensembles de services Rationaliser la répartition des services pour limiter les échanges d’informations INSA - ASI InfoRep : Client-Serveur Programmation “classique” vs. Informatique Répartie 4/36 (3/6) Programmation “classique” / Programmation distribuée Une seule machine Même OS Même espace mémoire Pas de problème de transport Disponibilité du service assuré (tant que l’on a accès à la librairie) Deux machines (sans compter celles “traversées”) OS différents Représentations différentes des types de bases Espace mémoire : “passer un pointeur/référence comme argument” ? Problème de transport : firewall, réseau HS, etc. Retrouver le service ? Où se trouve-t-il ? Qui le propose ? INSA - ASI InfoRep : Client-Serveur Programmation “classique” vs. Informatique Répartie 5/36 (4/6) Interopérabilité des langages Un même langage Même paradigme de programmation Même représentation des types de base Même représentation de l’information composite Deux langages Représentation des types de base et de l’information composite pouvant être différente Association des paramètres effectifs aux paramètres formels ? comment gérer les différents types de passage de paramètre ? Paradigmes de programmation différents : qu’est-ce-qu’un objet pour un langage procédural ? Comment gérer les erreurs ? INSA - ASI InfoRep : Client-Serveur Programmation “classique” vs. Informatique Répartie Une solution 6/36 (5/6) 1/2 Séparer la spécification/conception de l’implantation Utilisation de langage propre à la spécification/conception Utilisation de “traducteurs” vers le langage cible en distinguant le client du serveur Utiliser un langage de représentation de l’information Langage de représentation indépendant du langage de programmation Pour chaque langage de programmation, définir un ensemble d’opérations pour “sérialiser” ces types (prédéfinis ou utilisateur) INSA - ASI InfoRep : Client-Serveur Programmation “classique” vs. Informatique Répartie Une solution 7/36 (6/6) 2/2 Utiliser un protocole de transport Comment spécifier le service demandé Comment associer les paramètres effectifs aux paramètres formels Comment transmettre les erreurs Définir la gestion du service Utiliser un mécanisme permettant d’identifier la librairie (au sens large) qui fournit le service Utiliser un mécanisme qui permet d’activer le service si besoin INSA - ASI Client-Serveur InfoRep : Client-Serveur (1/15) Définitions Application Client-Serveur Application faisant appel à des services distants au travers d’un échange de messages (les requêtes et les réponses) plutôt que par un partage de données (mémoire ou fichiers) Serveur Programme offrant un service sur un réseau (par extension, machine offrant un service) Client Programme qui émet des requêtes (ou demandes de service). Il est toujours l’initiateur du dialogue 8/36 INSA - ASI InfoRep : Client-Serveur Client-Serveur 9/36 (2/15) Vues du client et du serveur Vue du client requête Client réponse Serveur Vue du serveur Sélection Requêtes Traitement Serveur Réponses Remarques 2 messages échangés au minimum (requête+réponse) Toute application répartie peut se décomposer en ensemble de requêtes de type Client-Serveur INSA - ASI InfoRep : Client-Serveur Client-Serveur 10/36 (3/15) Mises en oeuvre Différents types de client-serveur de données (ou procédural/fonctionnel) à objets à composants Niveau de description Bas niveau : socket ; orienté objets : RMI ; orienté services : Web Services ; orienté ressources : REST ; orienté composants : J2EE Langages de description d’interface : RPCL (RPC Sun), Corba XDR, Java RMI Intégration dans un langage de programmation INSA - ASI InfoRep : Client-Serveur Client-Serveur (4/15) Conception : les protocoles de communication Protocole de communication Un protocole de communication formalise les messages (types, contenus et ordre) échangés par les entités d’un système réparti. Ils sont souvent décrits en UML par des diagrammes de séquence. Ils sont une abstraction des protocoles de transport. Exemple : calculatrice sur entiers positifs Requête : C, request(opération, entier, opération) → S Réponse : S, response(entier) → C Réponse : S, error(description) → C 11/36 INSA - ASI InfoRep : Client-Serveur Client-Serveur 12/36 (5/15) Formalisation des messages : de la conception à l’implémentation Selon l’hétérogénéité entre le client et le serveur et le type d’architecture, certains éléments de conception peuvent être modifiés : Contenus des messages, Typage des messages Exceptions Exemple Un objet peut être sérialisé par l’ensemble de ses attributs Une valeur en retour peu correspondre à une exception INSA - ASI InfoRep : Client-Serveur Client-Serveur (6/15) Conception : serveur Éléments à prendre en compte lors de la conception du serveur : Gestion du(des) processus Gestion des requêtes (priorités) Exécution du service (séquentiel/parallèle) Gestion de la mémoire et du stockage des informations Taille des données manipulées Lien entre appels successifs Gestion des pannes Vérification des échanges et détection des pannes, Mémorisation de l’interaction et de l’état du client, Processus de reprise 13/36 INSA - ASI Client-Serveur InfoRep : Client-Serveur 14/36 (7/15) Processus unique 1 2 3 Requêtes Traitement Serveur tantque Processus a c t i f message <− r e c e p t i o n M e s s a g e ( . . . ) t r a i t e m e n t M e s s a g e ( message , . . . ) traitementService ( . . . ) envoyerMessage ( . . . ) fintantque 1 2 3 Réponses INSA - ASI Client-Serveur InfoRep : Client-Serveur 15/36 (8/15) Exemple de processus unique : sockets en mode non connecté Exemple Serveur Client socket() socket() bind() bind() recvfrom() bloquant sendto() sendto() recvfrom() INSA - ASI Client-Serveur InfoRep : Client-Serveur 16/36 (9/15) Processus unique avec gestion de file d’attente 1 2 3 Requêtes Sélection et Ordonnancement Traitement Serveur tantque Processus a c t i f message <− d e f i l e r M e s s a g e ( . . . ) t r a i t e m e n t M e s s a g e ( message , . . . ) traitementService ( . . . ) envoyerMessage ( . . . ) fintantque 1' 2' 3' Réponses INSA - ASI Client-Serveur InfoRep : Client-Serveur 17/36 (10/15) Exemple de processus unique avec file : sockets en mode connecté Exemple Serveur Client socket() socket() bind() bind() accept() bloquant connect() read()/write() read()/write() INSA - ASI Client-Serveur InfoRep : Client-Serveur 18/36 (11/15) Création d’exécutants Réponses Requêtes n atio cré Sélection et Ordonnancement création cr éa tio Traitement Traitement ... n Traitement Serveur tantque processus a c t i f m e s s a g e <− r e c e p t i o n M e s s a g e (...) t r a i t e m e n t M e s s a g e ( message , ...) p <− c r e a t i o n P r o c e s s u s processusTraitement (p , . . . ) fintantque procedure processusTraitement (p , . . . ) debut traitementService ( . . . ) envoyerMessage ( . . . ) fin INSA - ASI Client-Serveur InfoRep : Client-Serveur 19/36 (12/15) Exemple de création d’exécutants : sockets connectés avec fork() Exemple Serveur Client socket() socket() bind() bind() accept() bloquant connect() fork() read()/write() read()/write() INSA - ASI Client-Serveur InfoRep : Client-Serveur 20/36 (13/15) Pool d’exécutants Réponses Requêtes ... tiv ac Sélection n atio activation ac tiv at ion Traitement Traitement ... Traitement Serveur tantque processus a c t i f m e s s a g e <− r e c e p t i o n M e s s a g e (...) t r a i t e m e n t M e s s a g e ( message , ...) empilerTache ( tache , . . . ) fintantque tantque processus a c t i f t a c h e <− d e p i l e r T a c h e ( ) traitementService ( . . . ) envoyerMessage ( . . . ) fintantque INSA - ASI InfoRep : Client-Serveur Client-Serveur (14/15) Types de service / données manipulées Sans données persistantes Service fonction des paramètres d’entrée uniquement Solution très favorable ⇒ tolérance aux pannes ⇒ contrôle de la concurrence Exemple : calcul de fonction Avec données persistantes Exécutions successives manipulent les données ⇒ modification du contexte d’exécution ⇒ problèmes de contrôle de la concurrence ⇒ difficultés en cas de panne en cours d’exécution Exemple : serveur de fichiers répartis 21/36 INSA - ASI InfoRep : Client-Serveur Client-Serveur 22/36 (15/15) Types de service / mode Appels de procédures non liés Modification de données globales possible mais l’opération s’effectue sans lien avec les appels précédents Exemple : serveur d’enregistrement avec accès aléatoire Appels de procédures liés Appels successifs s’exécutent selon l’état laissé par les appels antérieurs ⇒ ordonnancement des requêtes Exemples : serveur d’enregistrement avec accès séquentiel, utilisation de variables statiques, calculatrice avec mémoire INSA - ASI InfoRep : Client-Serveur Appel de procédure à distance (1/14) Description Infrastructure minimale pour mettre en place un Client-Serveur Service : procédure ou fonction que le client peut faire exécuter à distance par le serveur But : forme et effet identiques à ceux d’un appel local ⇒ sans se préoccuper de la localisation de la procédure ⇒ sans se préoccuper du traitement des pannes Mise en oeuvre classique : sockets, RPC Sun Mise en oeuvre objet : Corba, RMI Problèmes courants : Pannes indépendantes client/serveur Problèmes réseau Temps de réponse 23/36 INSA - ASI InfoRep : Client-Serveur Appel de procédure à distance 24/36 (2/14) Principe de fonctionnement Programme client Talon client 1 Module de transport Module de transport Empaquetage Dépaquetage Talon serveur 2 Corps de m() Le réseau m(a,b) 4 Dépaquetage Programme serveur Empaquetage 3 INSA - ASI InfoRep : Client-Serveur Appel de procédure à distance 25/36 (3/14) Rôle des modules Rôle des talons Récupération des paramètres et résultats Conversion des données Rôle des modules de transport Empaquetage-dépaquetage et transmission des paramètres et résultats Gestion des erreurs de transport INSA - ASI InfoRep : Client-Serveur Appel de procédure à distance 26/36 (4/14) Utilisation d’un langage pivot Description du service Langage XXXL Compilateur XXXL → langage de programmation Talon serveur Talon client Squelettes pour implanter services Types définis dans XXXL .... .... .... INSA - ASI InfoRep : Client-Serveur Appel de procédure à distance (5/14) Problématiques courantes Défaillances Congestion du réseau ou du serveur Panne du client Panne du serveur Erreur de transport ou de communication ... Problèmes de sécurité Authentification du client Authentification du serveur Confidentialité des échanges ... Performance ... 27/36 INSA - ASI InfoRep : Client-Serveur Appel de procédure à distance 28/36 (6/14) Types de panne Panne du serveur ⇒ attente du client Client décide de la stratégie de reprise Serveur applique la stratégie de reprise Risque d’exécuter plusieurs fois la même procédure Serveur orphelin : panne du client Réalisation de travaux inutiles Risque de confusion du client États inconsistants En cas d’erreur Détection à l’aide d’horloges de garde Mécanisme de reprise : nombre de relances en cas de dépassement de délai (infini, au moins une fois, au moins X fois, ...) INSA - ASI InfoRep : Client-Serveur Appel de procédure à distance (7/14) Traitement d’une panne client Panne du client après émission de la requête ⇒ requête est correctement traitée Changement d’état du serveur L’appel de procédure est déclaré orphelin Détection : expiration du délai de garde 3 Recouvrement : Client re-émet la requête : sémantique “Au moins UN” Serveur ne peut pas détecter la répétition (id différente) Service idempotent : pas d’incidence Service non idempotent : service transactionnel (annulation par le client des effets de l’appel orphelin) 29/36 INSA - ASI InfoRep : Client-Serveur Appel de procédure à distance (8/14) Traitement d’une panne serveur Panne du serveur après émission de la requête ⇒ requête peut-être partiellement traitée Détection : expiration du délai de garde 1 Recouvrement : Client re-émet la requête : sémantique “Au moins UN” Client ne connaît pas l’endroit de la panne Si avant 2 : pas d’incidence Si entre 2 et 3 : changement d’état du serveur Service transactionnel pour mémoriser id et l’état avant exécution ⇒ gestion serveur 30/36 INSA - ASI InfoRep : Client-Serveur Appel de procédure à distance (9/14) Représentation des données Problème classique des réseaux Conversion est nécessaire si le client et le serveur n’utilisent pas le même codage (big endian, little endian) utilisent des formats internes différents Dans réseau : passage de paramètres uniquement par valeur ⇒ émulation des autres modes Solutions Solution normalisée : syntaxe abstraite de transfert Représentation externe commune ; ex : XDR Sun Représentation locale pour le client, conversion par le serveur Choix d’une représentation parmi n, conversion par le serveur Négociation client/serveur 31/36 INSA - ASI InfoRep : Client-Serveur Appel de procédure à distance (10/14) Passage par référence Référence : adresse mémoire chez le client (resp. serveur) ⇒ aucun sens pour le serveur (resp. client) Callback Un callback (appel en retour) est le fait qu’un serveur (resp. un client) exécute une action dont les résultats doivent être également répercutées chez le client (resp. serveur). Interdiction (procédures locales 6= distantes) Simulation en découpant l’appel (copie de restauration) Reconstruire la mémoire du client (solution coûteuse) Mémoire virtuelle répartie (nécessite un système répartie avec mémoire virtuelle) 32/36 INSA - ASI InfoRep : Client-Serveur Appel de procédure à distance 33/36 (11/14) Sérialisation et callbacks lors de passage d’objets 3 types de passage d’objet : Passage simple d’information (structure) : sérialisation Passage d’objet (attributs+méthodes) : sérialisation + accessibilité au code Passage d’objet non délocalisable (références locales=callback) : stub Callback objet Dans le cadre de systèmes orientés objets distribués, on appelle Callback (fonction en retour) une méthode appelée par le serveur (resp. le client) sur un objet transmis en paramètre par le client (resp. le serveur) et nécessitant d’être exécuté par le client (resp. le serveur). INSA - ASI InfoRep : Client-Serveur Appel de procédure à distance (12/14) Désignation Objets à désigner : Le site d’exécution, le serveur, la procédure Désignation globale indépendante de la localisation Désignation : statique : localisation du serveur connue à la compilation dynamique : non connue à la compilation Liaison : Liaison statique Liaison au premier appel Liaison à chaque appel 34/36 INSA - ASI InfoRep : Client-Serveur Appel de procédure à distance 35/36 (13/14) Solution classique : DNS Internet Client Serveur 4 8 7 Talon client 5 6 1 Talon serveur 3 2 Serveur d'annuaire Etapes 1,2,3 : enregistrement en BD (serveur d’annuaire) des services et noms de serveur Etapes 5,6 : liaison client/serveur Etapes 4,7,8 : Appel de procédure à distance INSA - ASI InfoRep : Client-Serveur Appel de procédure à distance Performance : utilisation de cache (14/14) 36/36