MODELES DE COMMUNICATION. C/S Évènements Flux. Stéphane Frénot -MID - V I - C/S 1

Transcription

1 MODELES DE COMMUNICATION C/S Évènements Flux Stéphane Frénot -MID - V I - C/S 1

2 Répartition d'une application Application de Présentation Middleware Implicite Application de traitement Application de Données Système d'exploitation Middleware Explicite Système d'exploitation Système d'exploitation Données Middleware Système Données Données Stéphane Frénot -MID - V I - C/S 2

3 Middleware Orienté Client/Serveur la brique de base Stéphane Frénot -MID - V I - C/S 3

4 Caractéristiques de la communication InterProcessus Primitives : send/receive Synchrone / Asynchrone Destinataire des messages Fiabilité Validité : même si perte de messages Intégrité : Non corrompu, Sans duplication Ordre : Ordre de l'émetteur TCP / UDP Stéphane Frénot -MID - V I - C/S 4

5 Caractéristiques du modèle client-serveur Notion de service réalisé par un serveur demandé par un client définie par une interface (API) entre client et serveur Communication par messages Requête : paramètre d'appel, spécification du service requis Réponse : résultat, indicateur d'exécution/d'erreur Synchrone : Client et serveurs sont bloqués Avantages Structuré, Protégé (espaces d'exécution distincts), Partagé Stéphane Frénot -MID - V I - C/S 5

6 Client / serveur "echo" en java L'appel client : java Client test La chaîne "test" est récupérée par le client ==> Commentaires! ==> Améliorations ==> Trois codes possibles Stéphane Frénot -MID - V I - C/S 6

7 Modèle client/serveur : partage Vu du client Vu du serveur Client requête Serveur réponse Gestion des requêtes (priorité) Exécution du service (séquentielle, concurrent) Mémorisation ou non l'état du client requêtes Sélection File des requêtes Traitement réponses Stéphane Frénot -MID - V I - C/S 7

8 Modèle Client-Serveur Gestion des processus Client et serveur exécutent des processus distincts Mise en œuvre par les primitives TCP/IP le client est suspendu (appel synchrone) éventuellement plusieurs requêtes peuvent être traitées concurremment par le serveur parallélisme réel (multiprocesseur) pseudo-parallélisme La concurrence peut prendre plusieurs formes plusieurs processus plusieurs processus légers dans le même espace virtuel Stéphane Frénot -MID - V I - C/S 8

9 Modèle Client-Serveur Protocoles sans état Chaque requête est indépendante de la suivante http, echo, X11 (à détailler), jdbc/sqlnet, Pas de causalité entre les requêtes Pas d'ordre d'arrivé Le modèle est résistant aux pannes du client et du serveur ==> Il suffit de... Stéphane Frénot -MID - V I - C/S 9

10 Modèle Client/Serveur Protocole à état Certaines requêtes dépendent des autres pour un même client Identification, Échange de clés de cryptage, Sélection de Menus Le serveur doit mémoriser la connexion du client Mode connecté : la connexion est identifiée par la socket Mode déconnecté : le protocole doit véhiculer l'information d'identification du client Problèmes Panne Sécurité Stéphane Frénot -MID - V I - C/S 10

11 Panne du client : Modèle Client/Serveur Serveurs à états : panne Le serveur peut repérer qu'il s'agit du même client Comment? Le client peut "rejouer" toute la session. Panne du serveur Le serveur doit enregistrer les états du clients Notion de journalisation ou de persistance Mais il doit pouvoir ré-identifier le client Le client peut "rejouer" toute la session Stéphane Frénot -MID - V I - C/S 11

12 Modèle client/serveur Serveur avec données rémanentes Les requêtes manipulent des données persistantes accessibles par plusieurs clients Exemple base de données Banque, Bourse L'ordre des requêtes est important : Délais, Inconsistance des données Exemple :» Crédit --> Débit --> ok» Débit --> Agios --> Crédit --> ok agios Stéphane Frénot -MID - V I - C/S 12

13 Modèle client/serveur Serveurs inter-dépendants Pour fournir une réponse un serveur dépend d'autre serveurs. Nécessité de synchronisation Panne des serveurs esclaves Transactions, 2PC Stéphane Frénot -MID - V I - C/S 13

14 Middleware Orienté Message La performance évolutive Stéphane Frénot -MID - V I - C/S 14

15 Communication orientée messages Communication synchrones/asynchrones Système de queues de messages Négociateurs de messages (brokers) Exemple : IBM MQSeries Stéphane Frénot -MID - V I - C/S 15

16 Communications Synchrones Observations : C/S est généralement synchrone Client et serveurs doivent être actifs au moment de la communication Le client est bloqué le temps de la requête Un serveur ne fait qu'attendre et traiter les requêtes Inconvénients du mode synchrone Un client est bloqué Les pannes doivent être traitées immédiatement (le client est bloqué) Dans de nombreux cas le modèle n'est pas approprié (mail, news...) Stéphane Frénot -MID - V I - C/S 16

17 Communication Asynchrone : Messages Message oriented middleware (MOM) : vise les communication asynchrones haut niveau (L5) Les processus s'envoient des messages qui sont mis en files d'attentes L'émetteur n'a pas à attendre de réponse immédiate, il peut faire d'autres choses Ces middlewares offrent souvent de la tolérance de pannes émetteur Serveur de communication Serveur de communication Récepteur application Application de routage Application de routage application os LAN os os os internet Stéphane Frénot -MID - V I - C/S 17

18 Communication persistante vs. éphémère Communication persistante : Le message est stocké sur le serveur de communication tant qu'il n'est pas livré Communication éphémère (transient) : Un message est supprimé dès qu'une erreur survient Stéphane Frénot -MID - V I - C/S 18

19 MOM Fondamentaux : La communication asynchrone persistante est mise en oeuvre par des files d'attentes. Une file d'attente est l'équivalent des tampons du système d'exploitation Exemples : MQSeries IBM, JORAM, JMS... Stéphane Frénot -MID - V I - C/S 19

20 Middleware Orienté Flux Les données continues Stéphane Frénot -MID - V I - C/S 20

21 Communication orientée Flux Support pour la communication Continue Flux en systèmes distribués Gestion de flux Stéphane Frénot -MID - V I - C/S 21

22 Media continus Observations : tous les éléments de communication jusqu'ici reposent sur un échange d'information discret, indépendant du temps Media continu : Les valeurs dépendent du temps Audio, Video, Animations, Senseurs/Capteurs Modes de transmission : Différentes garanties en fonction du transfert Asynchrone : Pas de restriction du quand la donnée est reçue Synchrone : borne max pour la communication de bout-enbout Isochrone : borne max et min pour la communication de bout-en bout. La jigue est bornée Stéphane Frénot -MID - V I - C/S 22

23 Flux Principe : Un flux (continu) données est une communication orientée connexion qui support le transfert de données isochrone Caractéristiques Unidirectionnels Source unique, un ou plusieurs puits Souvent, soit la source, soit le puit est un emballage de matériel (camera, lecteurs divers...) Types de flux Simple : Flux data simple Complexe : Multiple Stéphane Frénot -MID - V I - C/S 23

24 Flux et QoS Fondamentaux : la communication orientée flux s'intéresse au problème de temps dans la livraison de données. Comment spécifier de la QOS? Bien faire la différence entre spécification et implantation. Spécification des flux : On utilise un modèle de type bassine à jetons (tokenbucket) Application Un jeton est ajouté à la bassine tous les dt Caractéristiques d'entrée Taille max d'unités (octets) Rythme du seau à jeton (octets/s) Taille du seau (octets) Rythme de transmission max (octets/s) Services requis Sensibilité des pertes (octets) Souplesse des intervalles vides (usec) Sensibilité des pertes en burst (data unit) Délais minimum repérable (usec) Variation des délais max (usec) Qualité des garanties Stéphane Frénot -MID - V I - C/S 24

25 Implantation de la QoS Problème : les spécifications de Qos, se traduisent par de la réservation de ressources dans les couches inférieures. Pas d'approches standards pour (1)spécifier la QoS, (2) décrire les ressources, (3) associer spécifications et réservations Approches : RSVP (cf réseau) Stéphane Frénot -MID - V I - C/S 25

26 Synchronisation de flux Problème : soit un flux complexe, comment conserver les différents flux synchrones? Exemple : La stéréo doit arriver avec moins de 20-30usec! ==> Middleware dédié Plus simple (et classique) : Multiplexer les sousflux dans un flux unique, et démultiplexer à la réception. La synchronisation se fait dans le mux/demux. Avi, mpeg, matroska... Stéphane Frénot -MID - V I - C/S 26

27 Répartition d'une application Application de Présentation Middleware Implicite Application de traitement Application de Données Système d'exploitation Middleware Explicite Système d'exploitation Système d'exploitation Données Middleware Système Données Données Stéphane Frénot -MID - V I - C/S 27