Les mécanismes de communication dans un 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
Architecture de communication
- Architecture centralisée (client/serveur)
- Architecture semi-centralisée
- Architecture décentralisée
- Architecture hybride
L’architecture Client/serveur
est un mode de fonctionnement dissymétrique dans lequel il y adeux logiciels différents: un logiciel
serveur et un logiciel client, nécessaire sur toutes machines.
Fonctionnement d’un système client/serveur : client envoie req d’apres IP et Port, serv traite req et
envoie reponse
Présentation de l’architecture à 2 niveaux
le client demande une ressource et le serveur la lui fournit directement, en utilisant ses propres
ressources. (BD dans le serveur)
Présentation de l’architecture à 3 niveaux
• Il existe un niveau intermédiaire (Un client, le serveur d'application 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.
Architecture semi-centralisée
Le serveur centralisé est le point faible du système centralisé donc on remplace le serveur par un
ensemble de serveurs
Architecture décentralisée
Absence totale de serveur (peer-to-peer)
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 msg envoyé stocké aussi longtemps que nécessaire pour le transmettre au destinataire.
- pas nécessaire 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 l’envoie.
Communication transitoire
- Dépendance temporelle
- Si le message n’est pas délivré au destinataire, il sera effacé.
Exemple : Les routeurs offrent une communication transitoire
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)
modèles de communications
- Communication Interprocessus (IPC)
- Communication à distance
o Protocole de question-réponse
o Appel de procédure à distance (RPC)
o Invocation de méthode à distance (RMI)
- Communication indirecte
o Communication de groupe
o Système d’abonnement
o Files de messages
o Mémoire distribuée partagée
Communication Interprocessus (IPC) (entre les processus et les threads)
transférer des données entre les processus en utilisant des API qui coordonne la cnx de meme SE
Les systèmes distribués fournissent aux API un haut niveau d’abstraction
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)
Exemple Les sockets
modèle permettant à divers processus de communiquer sur une même machine qu'à travers un
réseau TCP/IP . On distingue ainsi deux modes de communication:
Le mode connecté(comme appel) utilisant le protocole TCP. une connexion durable est
établie entre les deux processus
Le mode non connecté(commes les msg) utilisant le protocole UDP. Ce mode nécessite
l'adresse de destination à chaque envoi, et aucun accusé de réception n'est donné.
Communication à distanc
- Protocole de Requêtes/Réponses (exmp http req): 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()
- Appel de procédure à distance (RPC)
o La souche client (“client stub”)
Fonction f client tjiha appel locale tradha en distance apres trecupiri les
resultat w trad resultat comme retour ta3 la fonction
o La souche serveur (“server stub”)
Fontion f serveur tjiha appel trealiser w dir l’execution apres tab3at resultat
Modes d’appele
Mode bloquant
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
RPC VS RMI
RPC n'est pas orienté objet et ne traite pas les objets
Communication indirecte
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
Types de communication indirecte
- Communication de groupes
- Systèmes d’abonnement
- Files de messages
- Mémoire partagée répartie
1- Communication de groupes
Unicast Broadcast
*Le Mutlicast Moyen efficace de communication 1-vers-N (une seule source vers un sous-ensemble
de destinataires)
*IP Multicast Permet à l’émetteut d’envoyer un seul paquet IP à un groupe de destinataires spécifié
avec la classe D
Types de groupes:
Public/Fermé • Monogroupe /Multigroupe • Synchrone/asynchrone
Ordre de réception des messages
Ordre absolu : tab3at m1 lel r1 w m2 lel r2, tsema m1 yel7a9 l r1 avant m2 lel r2
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
2- Système d’abonnement
basé évènements, récepteurs appelés 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
- Caractéristiques • Hétérogénité • Mode asynchrone
Fonctionnement
Les émetteurs disséminent un évènement à travers une opération de publication , les récepteurs
expriment leurs intérêts à travers l’opération d’abonnement.
• Filtre des évènements • Possibilité de se désabonner • L’évenèment est délivré aux abonnées
concernés par l’opération de notification.
CORBA Event Service
permet la gestion d'événements asynchrones dans un environnement distribué, fournit un
mécanisme de gestion d'événements qui permet aux objets répartis de publier et de souscrire à des
événements, 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.
3- Les files de messages
Permet de faire communiquer des applications qui s’éxécutent avec des horloges différentes, entre
des reseaux hétérogènes et des machines hors ligne, Les émetteurs envoient les messages dans file
et récupèrent les messages à partir la file qui est constuite selon l’ordre FIFO ou selon les priorités
des messages
Les récepteurs récupèrent les messages selon trois modes:
- bloquante: jusqu’a se que le message soit disponible
- non bloquante
- en notification: générer une notification quand le message est disponible dans la file
WebSphere MQ
produit de messagerie d'entreprise, 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 et les récupérer ultérieurement,
Les messages peuvent être récupérés dans l'ordre dans lequel ils ont été placés, 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, permettant de relier des applications hétérogènes et de gérer des flux de données
complexes
Java Messaging Service
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é. Est une architecture basée
sur des messages. offre des garanties de livraison des messages
4- Mémoire partagée distribuée (DSM
est met en commun la mémoire entre plusieurs nœuds dans un environnement distribué. 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, elle améliorer les performances en évitant la surcharge
