Université des Sciences et Technologies Houari Boumediene

Faculté d’Informatique

La communication de groupes
et les protocoles de diffusion
 Introduction

• Communication one to one

• Pour de meilleures performances et une aisance de programmation=> notion de
groupes
• Un groupe de communication est un ensemble de un ou plusieurs processus
s’exécutant sur des nœuds différents et coopérants pour assurer un service ou une
tâche donnée.
• Cet ensemble est vu et manipulé comme une entité logique unique et identifié par un
identificateur unique.
• La notion de groupe est très utilisée pour les applications de travail coopératif
Architecture

=consommation= transmission
 Type de communication de groupes

• Trois types de communication de groupes :

• one to many (un émetteur - plusieurs récepteurs)
• many to one (plusieurs émetteurs - un récepteur)
• many to many (plusieurs émetteurs - plusieurs récepteurs)
 Communication one to many
ordre séquentielle

num de séquence m1 1
m2 2
m1 1 m3 3
m2 2 - pour l'ordre il faut attendre le processus précèdent pour voir l'ordre multicast
m3 3 - on vas séquencé les messages par un serveur de séquence

.... 1
m2 2
m3 3

.... 1
.... 2
m3 3
 Communication one to many

• Un émetteur et plusieurs processus récepteurs

• Géré par le mécanisme de Multicast .
• La communication en Broadcast (diffusion) est un cas particulier de la communication
Multicast où le message est envoyé à tous les processus connectés au Réseau.
• Le Multicast et le Broadcaste sont intéressants pour plusieurs applications pratiques.
• Exemple : L’administration d’un Réseaux qui gère un groupe de processus
serveurs qui offrent un même service. Le processus administrateur peut réaliser un
multicast pour transmettre une requête de service aux groupe de serveurs. Il
sélectionnera alors le premier serveur qui y répond. Ainsi, l’administrateur n’est pas
tenu à maintenir une liste des serveurs libres.
 Gestion de groupe

Type de groupe
• closed groupe vs open groupe
• L’utilisation d’un « Open Group » ou d’un « Closed Group » dépend de
l’application.
• Exemple d’un closed groupe : Téléconférence
• Exemple d’un open groupe: traitement distribués de requêtes.

• Dynamique vs statique
Adhésion/Suppression d’un membre
• Ajout d’un processus dans un groupe.
• Suppression d’un processus d’un groupe
• Mécanisme de gestion des informations sur les groupes et leurs membres
Solution : l’utilisation d’un processus serveur de groupe centralisé

Serveur centralisé de groupe

• Avantage: gestion efficace de groupes
• Inconvénient : non fiable, non appropriée en cas de passage à l’échelle.
=> Solution : l’utilisation de plusieurs serveurs de groupes

Serveur de groupe distribué

• Réaliser un ou des copies du serveur afin de remédier à ces problèmes.
• Un coût en communication est nécessaire pour maintenir ces serveurs dans des états
cohérents.
• Ce cout en communication ne doit pas être trop important pour maintenir l’avantage de
cette solution.
 Adressage d’un Groupe et transmission des messages

• Le nom de haut niveau est une chaine ASCII indépendante de la localisation du

processus.
• Le nom de bas niveaux dépend des couches matérielles sous-jacentes.

Transmission des messages

• Transmission Multicast (Adresse Multicast de classe D)
• Transmission Broadcast (Adresse de broadcast)
• Transmission one-to-one (Liste des adresses de tous les membres)

La transmission one-to-one est intéressante dans le cas où les groupes comportent peu de
membres.
Par contre, elle génère un trafic important dans le cas contraire car elle envoie un paquet
de message à chaque processus, alors que les deux premières transmettent un seul message.
 Emission de messages

• Une application usager utilise le nom de haut niveau du groupe. Le serveur de

groupe centralisé maintient:
• une table des noms de haut niveau avec les noms de bas niveau
correspondants et,
• pour chaque groupe, une liste des identificateurs des membres appartenant
au groupe.
• A l’émission d’un message à un groupe, le site émetteur contacte le serveur de
groupe pour récupérer le nom de bas niveau du groupe selon le mode de
transmission choisi.
• Dans le cas d’une adresse multicast ou d’une adresse broadcast, l’émetteur
envoie le message à cette adresse.
• Dans le cas d’une transmission one-to-one, la liste des adresses des membres du
groupe est récupérée puis un message est transmis à chaque membre..
 Emission Multicast

Il y’a deux sémantiques d’émission multicast :

• One-to-all : une copie du message est envoyée à chaque processus du groupe de
multicast et le message est mit en buffer en attendant sa réception.
• Bulletin de bord: le message est adressé à un canal. Le canal joue le rôle d’un
bulletin de bord. Un processus qui reçoit le message prend une copie du
message mais ne le supprime pas du canal. Ainsi, le message reste disponible
aux autres processus. Les processus ayant le droit d’accès au canal appartiennent
au groupe de multicast.

Multicast bufferisé et non bufferisé
Le multicast est un mécanisme asynchrone car :
• il n’est pas réaliste de faire attendre les processus émetteurs jusqu’à ce que
tous les membres du groupe reçoivent le message.
• le processus émetteur n’est pas concerné par le traitement du message
permet à un expéditeur d'envoyer des messages à un
groupe de destinataires en même temps, mais chaque
destinataire peut recevoir et traiter le message à son propre
rythme. Les membres du groupe de multicast peuvent
traiter les messages de manière indépendante et à des
moments différents, en fonction de leur propre état et de
leurs capacités

Le traitement du message à la réception dépend du fait que :

• Multicast non-bufferisé: dans ce cas, le message est perdu si le processus
récepteur n’est pas en attente du message. Le message ne peut être reçu que
par les processus qui sont prêt à le recevoir. utiliser pour les app qui exige pas la fiabilité car pas de buffer donc on aura une perte

• Multicast bufferisé: le message est stocké dans un buffer et tous les

processus finiront par recevoir le message.
 Multicast Atomique

• Un message émie à un groupe multicast doit être reçu par tous les membres
du groupe ou pas aucun d’entre eux.
• On suppose qu’un membre d’un groupe multicast qui tombe en panne n’est
plus membre dès qu’il est en panne.
• L’atomicité peut être spécifiée au niveau du message.
• Comment implémenter un mécanisme de multicast atomique ?
Solution 1
• un message est envoyé à chaque membre
• et chaque membre envoie un acquittement ACK au noyau.
• Au bout d’un délai, si tous les membres n’ont pas répondu, le message est retransmis
• et ainsi de suite jusqu'à recevoir les ACK de tous les membres
• Puis le système confirme la réalisation du multicast atomique.

 Cette solution peut être adoptée dans le cas où on suppose qu’il n’y a pas de panne de
l’émetteur et de récepteur
 Sinon, il faut adopter un protocole de tolérance aux pannes.

Solution 2 Solution de relais-intragroupe proposée par Joseph et Birman en 1989

• L’émetteur envoie un message à tous les membres du groupe et initialise un délai de
retransmission.
• Un membre du groupe, qui reçoit le message pour la première fois, doit l’envoyer à tous les
autres membres du groupe et initialise à son tour un délai de retransmission.
• un membre du groupe, qui a déjà reçu ce message, doit le détruire.
 Communication many to one
émetteurs

l'ordre n'est pas important le récepteur choisi l'ordre qu'il veut

récepteur
 Communication many to one

• Multiple émetteurs et un seul récepteur.

• Le récepteur unique peut être sélectif ou non sélectif.
• Un récepteur sélectif spécifie un émetteur unique. Un échange de message aura
lieu uniquement si cet émetteur envoie un message.
• Un récepteur non sélectif spécifie un ensemble d’émetteurs. Dans ce cas, un
échange de message a lieu si un élément de l’ensemble des émetteurs envoie un
message.
 Communication many to many
émetteurs récepteurs
 Communication many to many
• Plusieurs émetteurs et plusieurs récepteurs.
• Les schémas de communications many-to-one et one-to-many sont implicitement inclus
dans le schéma de communication many-to-many.
=> Donc, les concepts déjà vus s'appliquent toujours mais de nouveaux concepts sont
propres à ce type de communication telle que la délivrance ordonnés de messages à cause
de certaines problématiques propres à ce type de communication.

Ordre de délivrance des messages

Exemple: La réception non ordonnée des messages
(opérations de mise à jour (a+1) et (a/2) de la donnée a)
entraine une incohérence de la BDD (contenus différents
et incorrectes).
• Plusieurs types d’ordre de délivrance:
• Absolu délivrance=consommation=transmission

• Consistant
• Causal
 Ordre absolu

Les messages doivent être transmis aux récepteurs dans l'ordre exacte de leur émission.
=> La solution est d’utiliser une horloge globale.

Le protocole proposé suppose que les horloges des processus sont synchronisées:
• L’heure d’émission d’un message est alors insérée dans chaque message.
• Le système de réception utilise alors une file d’attente pour chaque émetteur où les
messages reçus de cet émetteur sont stockés.
• Et, régulièrement, toutes les périodes, des messages sont délivrés au récepteur.
• Cette fenêtre a une taille représentée par un intervalle de temps fixe. Périodiquement, les
messages reçu et qui sont à l’intérieur de cette fenêtre sont délivrés et les messages non
encore inclus dans la fenêtre restent en attente dans la file car d’autres messages avec des
dates inférieures peuvent arriver.
• La taille de la fenêtre est définie en prenant en considération le temps maximal possible
pour la transmission d’un message d’une machine à n’importe quelle autre machine.
Algorithme de délivrance de messages dans un ordre absolu
Hypothèses :
- Processus membres d’un groupe distribués sur plusieurs sites géographiques
- Horloges synchronisées
- Au niveau de chaque récepteur, nous trouvons une file d’attente (FAi) par émetteur
m1
Ei
m3
m2
m1 1 m4
A l’émission d’un message m: m2 3
m1
- Insérer l’heure d’émission dans le message m m3
m2
m4
- Emettre le message aux processus du groupe m3 2 m1
pour avoir cette
ordre on doit faire
m4 4 m3 une horloge
m2 globale(adaptatio)
m4
A la réception d’un message m :
- Insérer m dans file d’attente de l’émetteur Ei (les messages de chaque émetteur sont triés
dans FAi), en respectant l’ordre
- A chaque fin fenêtre (période ou délai de temps).
- Délivrer les messages inclus dans la fenêtre courante au récepteur
 Ordre consistent moins utilisé car les processus ne sont pas synchronisé

• Un ordre absolu nécessite des horloges synchrones

• La plupart des applications n’exigent pas l’ordre absolu.
• Exemple: Pour les requêtes de mise à jour d’une BDD, émises par des émetteurs (clients)
différents, il suffit qu’elles arrivent dans le même ordre au niveau des serveurs de copies
de la BDD, puisque le résultat nous mènera vers des copies de BDD cohérentes.
• Dans le cas des communications many-to-one, l'ordre est maintenu par le récepteur
unique.
• Dans le cas d'une communication one-to-many, le séquencement est évident. Il suffit que
l'émetteur unique confirme la fin d’un premier multicast avant d'initier le suivant ou
d’intégrer un numéro de séquence au message
• Dans le cas de communications many-to-many, il n'est pas évident de l'assurer. L'ordre de
réception est non déterministe .
 Ordre consistent d’une communication many-to-many

Solution 1: Intégrer un serveur de séquencement

• utiliser la communication de groupe many-to-one et one- to-many.
• Les messages sont alors envoyés à un serveur de séquence qui attribue à chaque message un numéro de séquence
unique dans le système.
• Exemple: le système CODA utilise ce type de solution. En effet, le serveur délivre un numéro unique aux opérations de
mises à jour de copies de fichier, ce numéro est dit CSN (“Commit Sequence Number“).
• Au niveau d’un récepteur les messages sont ordonnés séparément dans des files différentes (une pour chaque émetteur):
• Le message est alors consommé directement s’il n’y a pas de creux dans les numéros de séquence des messages reçus
• Sinon, le message reste dans la file jusqu’à la réception de tous les messages ayant des numéros de séquence inférieur.

fonctionnement de one to many serveur de séquencement

Inconvénients :
• Dépendance vis-à-vis du serveur de séquencement (le serveur central de
séquencement). Elle présente, donc, tous les inconvénients d’une solution
centrale (cas de panne du serveur de séquencement, congestion,…).
• Problème de la taille du buffer, puisqu’un message ne peut être
consommé avant de recevoir les messages précédents.
• A la réception d’un message (i+1) du séquenceur, le récepteur envoie un
ACK négatif au séquenceur pour l’informer du manque du message i.
 étape de ABCAST
Solution 2: Une solution distribuée étape de proposition

étape de décision

• Le protocole ABCAST ce protocole permet aux nœuds de consommer les messages en même temps

• Chaque nœud dispose d’une horloge logique et d’une file d’attente des
messages diffusés au groupe de communication.
• Les messages sont ordonnés selon l’estampille associée dans la file d’attente.
• Cependant, cette estampille peut être :
• Soit temporaire (choisie par le récepteur et proposée par l’émetteur).
• Soit définitive (définie par l’émetteur de la diffusion)
• un message ne peut être délivré que si, son estampille est définitive et la plus
petite de la file d’attente.
 Exemple ABCAST

P1 envoi un message m1 avec numseq 1 a P2 et P3

P2 reçoit m1 et le stock sans sa file d’attente avec numseq 2
P2 envoi le numseq proposé pour m1 à p1
P1 choisi le max entre ancien numseq et le nouveau proposé par p2
P2 envoi un message m2 a p1 et p3 avec numseq 3
P1 et P3 enregistrent m2 dans la file d’attente avec numseq 4
P1 et P3 envoient le nouveau numseq de m2 à p2
P2 choisi le max des numseq pour m2 et enregistre le message m2 dans sa
file avec numseq 4
P3 reçoit m1 et l’enregistre dans sa file avec numseq 5 puis envoi la
proposition a p1
P2 reçoit les deux propositions et affecte numseq= 4 définitif à m2
P2 envoi le numseq définitif a P1 et P3
P1 reçoit numseq de P3 et choisi le max puis attribue numseq définitif à m1
P1 envoi le numseq définitif de m1 à P2 et P3
P1 consomme m2 puis m1
P3 consomme m2
P3 reçoit le numseq définitif de m1 et le consomme
P2 reçoit le numseq définitif de m1
P2 consomme m2 puis m1
Tous les processus ont consommé m2 puis m1
Ordre consistent respecté
 exemple:
m1 m2 m4 m2
m2 m3 m2 m1
m3 m1 m1 m4
Ordre causal m4 m4 m3 m3
2 messages lié causalement (msg reçu msg envoyé)
et doivent être dans le même ordre (le msg3 ne peut pas être envoyé jusqu'à ou le msg2 est reçue
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é.

• Deux événements d’émission non liés par une relation de causalité peuvent arriver dans un ordre quelconque
contrairement à deux événements liés par une relation « hapened-before » (relation de causalité).
La première condition assure que le La seconde condition assure que l’émetteur
récépteur a reçu tous les messages n’a reçu aucun message que le récepteur
émis avant le message courant par n’a pas reçu. Cette condition assure que le
l’émetteur, message de l’émetteur n’est pas
causalement lié à un message non reçu par
le récepteur.

si S[i]<=R[i] donc récepteur n'a pas reçu de l'émetteur des msgs

S[i]=R[i]+1
Si la condition est vérifiée, le message est délivré sinon il est mis dans un buffer et le test est refait plus
tard.
 (1,0,0)

(0,0,0)

(0,0,0)

P1 initialise son vecteur (V[1]=1, les autres cases V[i]=0)

P1 envoi un message à P2 et P3
 (1,0,0)

(0,0,0) (1,0,0)

P2 reçoit le message de P1
Les deux conditions sont vérifié=> message délivré
P2 incrémente V[2] (suite à la réception du message de P1)
P2 prend le max entre V[1] local et V[1] inclus dans le message
 (1,0,0)

(1,1,0)

P2 incrémente V[2] (envoi du message)

P2 envoi un message à P1 et P3
 (1,0,0) (1,1,0)

(1,1,0)

(0,0,0) (0,1,0)

Au niveau de P1: les conditions sont vérifiées, maj du vecteur, délivrance du message
Au niveau de P3: les conditions ne sont pas vérifiées (s[1]>r[1]), maj du vecteur et mise en
attente du message
 (1,1,0)

(1,1,0)

(0,1,0) (1,1,0)

P3 reçoit le message de P1
Maj du vecteur
Les conditions sont vérifiées
Délivrance du message de P1 puis le message de P2