MODELES DE COMMUNICATION C/S
Évènements Flux
Répartition d'une application
Données Système d'exploitation Application de
traitement
Données Système d'exploitation Application de
Présentation
Données Système d'exploitation Application de
Données Middleware Implicite
Middleware Explicite
Middleware Système
la brique de base
Middleware Orienté
Client/Serveur
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
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é,
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
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 Serveur
requête réponse
requêtes
File des requêtes Traitement Sélection
réponses
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
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 ...
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é
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
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
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
Middleware Orienté Message
La performance évolutive
Communication orientée messages
• Communication synchrones/asynchrones
• Système de queues de messages
• Négociateurs de messages (brokers)
• Exemple : IBM MQSeries
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é)
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 application Application
de routage application
Récepteur Serveur de communication
Application de routage
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
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...
Middleware Orienté Flux
Les données continues
Communication orientée Flux
• Support pour la communication Continue
• Flux en systèmes distribués
• Gestion de flux
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
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
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 bassine tous les dt
Application
Caractéristiques d'entrée Taille max d'unités (octets)
Rythme du seau à jeton (octets/s) Taille du seau (octets)
Services requis
Sensibilité des pertes (octets)
Souplesse des intervalles vides (usec) Sensibilité des pertes en burst (data unit)
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)
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...
Répartition d'une application
Données Système d'exploitation Application de
traitement
Données Système d'exploitation Application de
Présentation
Données Système d'exploitation Application de
Données Middleware Implicite
Middleware Explicite
Middleware Système
