Embed Size (px)
Citation preview
Stéphane Frénot -MID - V.0.2.0 I - C/S 1
MODELES DE COMMUNICATION
C/S
Évènements
Flux
Stéphane Frénot -MID - V.0.2.0 I - C/S 2
Répartition d'une application
Données
Systèmed'exploitation
Application detraitement
Données
Systèmed'exploitation
Application dePrésentation
Données
Systèmed'exploitation
Application deDonnées
Middleware Implicite
Middleware Explicite
Middleware Système
Stéphane Frénot -MID - V.0.2.0 I - C/S 3
la brique de base
Middleware Orienté Client/Serveur
Stéphane Frénot -MID - V.0.2.0 I - C/S 4
Caractéristiques de la communicationInterProcessus
• 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.0.2.0 I - C/S 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.0.2.0 I - C/S 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.0.2.0 I - C/S 7
Modèle client/serveur : partage
• Vu du client
• Vu du serveur– Gestion des requêtes (priorité)
– Exécution du service (séquentielle, concurrent)
– Mémorisation ou non l'état du client
Client Serveurrequête
réponse
requêtesFile des requêtes
Traitement
Sélection
réponses
Stéphane Frénot -MID - V.0.2.0 I - C/S 8
Modèle Client-ServeurGestion 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.0.2.0 I - C/S 9
Modèle Client-ServeurProtocoles 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.0.2.0 I - C/S 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.0.2.0 I - C/S 11
Modèle Client/Serveur Serveurs à états : panne
• Panne du client : – 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.0.2.0 I - C/S 12
Modèle client/serveurServeur 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.0.2.0 I - C/S 13
Modèle client/serveurServeurs 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.0.2.0 I - C/S 14
Middleware Orienté Message
La performance évolutive
Stéphane Frénot -MID - V.0.2.0 I - C/S 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.0.2.0 I - C/S 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.0.2.0 I - C/S 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
os
Serveur de communication
os
applicationApplicationde routage
internetLAN
os
application
RécepteurServeur de communication
os
Applicationde routage
Stéphane Frénot -MID - V.0.2.0 I - C/S 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.0.2.0 I - C/S 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.0.2.0 I - C/S 20
Middleware Orienté Flux
Les données continues
Stéphane Frénot -MID - V.0.2.0 I - C/S 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.0.2.0 I - C/S 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-en-bout
– Isochrone : borne max et min pour la communication de bout-en bout. La jigue est bornée
Stéphane Frénot -MID - V.0.2.0 I - C/S 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.0.2.0 I - C/S 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 (token-bucket)
Un jeton est ajouté à la bassinetous les dt
Application
Caractéristiques d'entréeTaille max d'unités (octets)Rythme du seau à jeton (octets/s)Taille du seau (octets)Rythme de transmission max (octets/s)
Services requisSensibilité 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.0.2.0 I - C/S 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.0.2.0 I - C/S 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 sous-flux 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.0.2.0 I - C/S 27
Répartition d'une application
Données
Systèmed'exploitation
Application detraitement
Données
Systèmed'exploitation
Application dePrésentation
Données
Systèmed'exploitation
Application deDonnées
Middleware Implicite
Middleware Explicite
Middleware Système
