Université des Sciences et Technologies Houari Boumediene

Faculté d’Informatique

Les mécanismes de
communication dans un système
distribué
 Introduction

Système distribué
Échange de messages entre les différents nœuds du système
Cela dépend de plusieurs paramètres:
• Topologie du réseau
• La nature des échanges
• Les contraintes de l’application

• => Nécessité des mécanismes de communication adaptés

 Architecture de communication

• Architecture centralisée (client/serveur)

• Architecture semi-centralisée
• Architecture décentralisée
• Architecture hybride
 L’architecture Client/serveur

•Le mode client/serveur est un mode de fonctionnement dissymétrique dans lequel deux logiciels différents
sont nécessaires pour permettre les communications : un logiciel serveur et un logiciel client, nécessaire sur
toutes machines.
•Le logiciel client peut envoyer une requête au logiciel serveur. Le serveur traite la requête et se charge
d’envoyer la réponse au client concerné.
Fonctionnement d’un système client/serveur
Un system client /serveur fonctionne selon le schéma suivant :

Le client émet une requête vers le serveur grâce à son adresse IP et le port ; qui désigne un service particulier
du serveur.
Le serveur reçoit la demande et répond à l’aide de l’adresse de la machine client et son port
Client
• Interface d’utilisateur
• Saisie de requête
• Envoie de requête
• Attente du résultat
• Affichage du résultat

Serveur
• Gestion des requêtes (priorité)
• Exécution du service (séquentiel,
concurrent)
• Mémorisation ou non de l'état du client
Présentation de l’architecture à 2 niveaux

• le client demande une ressource et le serveur la lui fournit directement, en utilisant ses propres
ressources.
• Cela signifie que le serveur ne fait pas appel à une autre application afin de fournir une partie du
service.
Présentation de l’architecture à 3 niveaux

• Il existe un niveau intermédiaire

• une architecture partagée entre : Un client, le serveur d'application (appelé également middleware) et
le serveur des données
Présentation de l’architecture à N niveaux

• Spécialiser les serveurs dans une tache précise

• Avantage de flexibilité, de sécurité et de performance.
• L'architecture peut être étendue sur un nombre de
niveaux plus important : on parle dans ce cas
d'architecture à N niveaux (ou multi-tier).
Architecture semi-centralisée

• Le serveur centralisé est le point faible du système

centralisé
• Remplacer le serveur par un ensemble de serveurs
• Gérer la cohérence
Architecture semi-centralisée

• Absence totale de serveur

 Types de communications
Communication persistante
• pas de dépendance temporelle :l’émetteur et le récepteur ne sont pas obligés d’être présents en même temps
• Un message qui a été soumis pour transmission est stocké aussi longtemps que nécessaire pour le transmettre au
destinataire. lemsgmsgneest conservé temporairement dans ce system même après son envoie en attendant d'être transmis au destinataire cette étape de stockage permet d'assurer que le
sera pas perdu si des prblm surviennent
• Il n'est pas nécessaire que l'application d'envoi continue son exécution après l'envoi du message.
• De même, l'application réceptrice n’a pas besoin d’être en cours d’exécution lorsque le message est envoyé.
• Exemple type : l’émail.
Communication transitoire
• Dépendance temporelle: l’émetteur et le récepteur doivent être présents tout au long de l’échange
• Si le message n’est pas délivré au destinataire, il sera effacé.
• Les routeurs offrent une communication transitoire
• Si le routeur n’arrive pas à délivrer le message au prochain saut, le message sera effacé.
Communication synchrone (bloquante)
• L’émetteur est bloqué après l’envoi du message jusqu’a ce que le récepteur lui réponde.

Communication asynchrone (non bloquante)

L’émetteur n’est pas bloqué par la transmission en cours, il peut continuer à s’exécuter après avoir soumis le
message pour transmission
 modèles de communications

Trois modèles de communications:

• Communication Interprocessus (IPC)
• Communication à distance
• Protocole de question-réponse
• Appel de procédure à distance (RPC)
• Invocation de méthode à distance (RMI)
• Communication indirecte
• Communication de groupe
• Système d’abonnement
• Files de messages
• Mémoire distribuée partagée
Communication Interprocessus (IPC)
 Communication Interprocessus (IPC)

• Consiste à transférer des données entre les processus

• Utilise des API qui permettent de coordonner les activités de différents processus d’un
même SE
• IPC permet de s’échanger des informations entre différents processus et threads
• Le SE fourni les ressources nécessaires pour l’IPC comme les files de messages, les
sémaphores, mémoire partagée et les sockets.
• Les systèmes distribués fournissent aux API un haut niveau d’abstraction (ex:
primitives send() et receive ())

Caractéristiques
• Communication synchrone/asynchrone
• Destination des messages (Adresse IP, Numéro de port)
• Fiabilité (garantie de livraison des messages)
• Ordre des messages (même ordre d’envoi)
 Les sockets

• Il s'agit d'un modèle permettant à divers processus de communiquer aussi bien sur une
même machine qu'à travers un réseau TCP/IP.
• . On distingue ainsi deux modes de communication:
• Le mode connecté (comparable à une communication téléphonique), utilisant le
protocole TCP. Dans ce mode de communication, une connexion durable est établie
entre les deux processus, de telle façon que la socket de destination n'est pas
nécessaire à chaque envoi de données.
• Le mode non connecté (analogue à une communication par courrier), utilisant le
protocole UDP. Ce mode nécessite l'adresse de destination à chaque envoi, et aucun
accusé de réception n'est donné.
 Les sockets

Mode non connecté Mode connecté

Communication à distance
 Protocole de Requêtes/Réponses

• Le client envoi une requête au serveur via la socket et attends la réponse

• Le serveur reçoit la requête, la traite et envoi la réponse au client
• Deux modes: synchrone ou asynchrone
• UDP est recommandé au lieu de TCP
• Primitives:
• doOperation(RemoteObjectRef o )
• getRequest()
• sendReply()
• Exemple : le protocole HTTP
 Appel de procédure à distance (RPC)
• La souche client (“client stub”)
• Procédure coté client qui reçoit l’appel en mode local
• Le transforme en appel distant
• En envoyant un message
• Reçoit le message contenant les résultats après l'exécution
• Retourne les résultats comme dans un retour de procédure.
• La souche serveur (“server stub”)
• 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.
 Appel de procédure à distance (RPC)

• Mode bloquant:
• 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

• Mode non bloquant:

• 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
(primitive spéciale).
Invocation de méthodes à distance (RMI)
Communication indirecte
• La communication entre deux entités passe par un intermédiaire.
• L’émetteur ne connait pas l’identité du récepteur et vice versa
• L’émetteur et le récepteur ne dépendent pas du temps

• Exemples de systèmes de communication indirecte:

• Systèmes mobiles avec de fréquents arrivées et départs
• Systèmes de dissémination d’évènements

• Types de communication indirecte

• Communication de groupes
• Systèmes d’abonnement
• Files de messages
• Mémoire partagée répartie
 Communication de groupes

Le Mutlicast

• Moyen efficace de communication 1-vers-N

• multicast vs. unicast et broadcast
• unicast : une seule source vers une seule destination
• broadcast : une seule source vers toutes les destinations
• multicast : une seule source vers un sous-ensemble de destinataires
• Le multicast simple ne permet pas de garantir la réception des messages par tous les nœuds ni
l’ordre de leurs réception

IP Multicast
• Permet à l’émetteut d’envoyer un seul paquet IP à un groupe
de destinataires
• Le groupe Multicast est spécifié avec la classe D
 Communication de groupes

Notion de groupe
• Un groupe est composé de plusieurs membres qui peuvent joindre et quitter le groupe à tout
moment
• La communication se fait via le Multicast
• Types de groupes:
• Public/Fermé
• Monogroupe /Multigroupe
• Synchrone/asynchrone

Ordre de réception des messages

• Ordre absolu : Les messages doivent être transmis aux récepteurs dans l'ordre exact de leur émission
• Ordre consistant: Les messages doivent être transmis aux récepteurs dans le même ordre
• Ordre causal: Si un événement d’émission d’un message est causalement lié à l’événement d’émission d’un
autre message, les deux messages doivent être reçus au niveau du récepteur dans un ordre correct qui reflète
cette relation de causalité.
 Système d’abonnement

• C’est un système basé évènements ou les noeuds émetteurs (ou posteurs)

envoient des messages à des noeuds récepteurs appelés aussi abonnés
• Les messages envoyés sont catégorisés en classes et les abonnées ne
recoivent que les messages qui font partie de leurs domaines d’interêt.
• Le challenge de ce système est de faire correspondre les abonnements
avec les messages publiés et assurer que les notifications sont bien
délivrées aux abonnées concernés

Caractéristiques
• Hétérogénité
• Mode asynchrone
 Système d’abonnement

Fonctionnement
• Les émetteurs disséminent un évènement à travers une opération de publication et les récepteurs (abonnés)
expriment leurs intérêts pour les évènements à travers l’opération d’abonnement.
• Filtre des évènements
• Possibilité de se désabonner à travers une opération de désabonnement.
• L’évenèment est délivré aux abonnées concernés par l’opération de notification.
 CORBA Event Service
• Le CORBA Event Service est un composant du Common Object Request
Broker Architecture (CORBA), une architecture de middleware pour la
communication entre objets répartis.
• Le CORBA Event Service permet la gestion d'événements asynchrones
dans un environnement distribué
• Le CORBA Event Service fournit un mécanisme de gestion d'événements
qui permet aux objets répartis de publier et de souscrire à des événements.
Cela permet aux composants logiciels de communiquer de manière
asynchrone en réagissant aux événements.
• Le CORBA Event Service gère la distribution d'événements aux abonnés,
en garantissant que seuls les abonnés appropriés reçoivent les événements
qui les concernent. Il peut gérer la filtration d'événements en fonction de
critères de sélection définis par les abonnés.
 Les files de messages

• Permet de faire communiquer des applications qui s’éxécutent avec des horloges différentes.
• Communication entre des reseaux hétérogènes et des machines hors ligne
• Les émetteurs envoient les messages dans la file et récupèrent les messages à partir de la file
• La file est constuite selon l’ordre FIFO ou selon les priorités des messages
• Les récepteurs (ou consommateurs ) récupèrent les messages selon trois modes:
• Réception bloquante: bloquer le consommateur jusqu’a se que le message soit disponible
• Réception non bloquante: verifier l’état de la file et la disponibilité du message
• Réception en notification: générer une notification quand le message est disponible dans la file
 WebSphere MQ
• WebSphere MQ (IBM MQ), est un produit de messagerie d'entreprise développé par IBM.
• Il s'agit d'une solution de middleware qui permet la communication asynchrone entre les applications et les
systèmes distribués.
• Les applications peuvent envoyer des messages à des files d'attente (queues) et les récupérer ultérieurement, ce
qui facilite la communication entre des applications qui ne fonctionnent pas nécessairement en même temps.
• Les messages sont stockés dans des files d'attente, ce qui permet de garantir que les messages ne sont pas
perdus en cas de panne d'une application ou d'un système.
• Les messages peuvent être récupérés dans l'ordre dans lequel ils ont été placés dans la file d'attente.
• Il prend en charge de nombreuses plateformes, y compris les systèmes mainframe, UNIX, Windows, et
d'autres. Il offre également des bibliothèques clientes pour différents langages de programmation, ce qui facilite
l'interopérabilité.
• Il assure une livraison fiable des messages. Si un message ne peut pas être remis au destinataire, il est conservé
dans la file d'attente jusqu'à ce que le destinataire soit disponible pour le traiter.
• Il est largement utilisé dans les environnements d'intégration d'entreprise, permettant de relier des applications
hétérogènes et de gérer des flux de données complexes.
• Il est largement utilisé dans de nombreux secteurs, notamment les services financiers, la santé, la logistique et
d'autres domaines où une communication fiable est essentielle.
 Java Messaging Service
• Java Message Service (JMS) est une API Java qui permet la création, l'envoi, la réception
et le traitement de messages asynchrones entre les composants logiciels, généralement dans
un environnement distribué.
• Cette API facilite la communication entre les applications, les systèmes et les composants
au sein d'une architecture basée sur des messages.
• JMS est une API standardisée dans l'écosystème Java, ce qui signifie qu'elle peut être
utilisée avec divers fournisseurs JMS conformes à cette API. Les fournisseurs JMS les plus
couramment utilisés sont Apache ActiveMQ, IBM MQ, RabbitMQ.
• JMS gère différents types de messages, notamment les messages texte, les messages
binaires et les objets sérialisables.
• JMS offre des garanties de livraison des messages, ce qui signifie que les messages sont
généralement fiables et que des mécanismes sont en place pour gérer les erreurs et les
reprises en cas d'échec.
• JMS est couramment utilisé dans les environnements d'intégration d'entreprise pour la
communication entre les applications et les systèmes distribués, ainsi que pour la mise en
œuvre de modèles de messagerie avancés.
 Mémoire partagée distribuée (DSM)

• La mémoire partagée répartie "shared distributed memory" , est un concept qui met en commun la mémoire
entre plusieurs nœuds dans un environnement distribué, de manière à permettre aux nœuds de partager des
données en mémoire comme s'ils accédaient à une mémoire partagée unique, même s'ils sont physiquement
répartis sur un réseau.
• Pour garantir que les données partagées restent cohérentes, la mémoire partagée répartie met en place des
modèles de cohérence, déterminant comment les écritures et les lectures sont gérées pour éviter les conflits
et garantir que les données sont à jour.
• La mémoire partagée répartie peut améliorer les performances en évitant la surcharge liée à la
communication réseau. Les nœuds peuvent accéder aux données partagées plus rapidement qu'ils ne le
pourraient s'ils devaient toujours les transférer sur le réseau
• La mémoire partagée répartie est utilisée dans divers domaines, notamment la programmation parallèle et
distribuée, les systèmes de calcul haute performance, les bases de données distribuées, les systèmes de
traitement en temps réel et les environnements de cloud computing.
• La mémoire partagée répartie est particulièrement utile pour les applications nécessitant une
communication et une collaboration efficaces entre nœuds distribués, tout en minimisant la latence associée
aux communications réseau.