Universit Paris-Dauphine : IUP GMI, IUP MIAGE, DESS SITN

CHAPITRE II LA COMMUNICATION
version du 21 novembre 2002

1 Introduction
Dans ce chapitre, nous nous focaliserons sur la communication aussi bien travers le mode de communication entre les entits qu' travers le comportement du rseau dans la fonction de transit. Tout d'abord, nous reviendrons sur la rception de messages. Un des avantages de la rception asynchrone est qu'un message est immdiatement trait (moyennant l'ventuel retard d l'arrive d'un message lors de l'excution d'une primitive de service). Dans le cas d'une rception synchrone, si l'application n'est pas immdiatement intresse par l'arrive d'un message celui-ci doit tre stock pour un usage ultrieur. Quelque soit la taille prvue du tampon des messages, un dbordement est toujours possible si un mcanisme adquat n'est pas prvu. Ce mcanisme s'appelle le contrle de flux et nous l'tudierons la fois dans un environnement local [Boc79] et dans un environnement tendu o les entits sont les noeuds de routage et o le graphe de communication n'est plus une cliq ue. Un des objectifs de l'algorithmique rpartie est la recherche de la symtrie car celle-ci est souvent synonyme de simplicit et d'efficacit de conception. Un des moyens d'y parvenir est de rendre les primitives de rception et d'mission quasiment identiques tout au moins en ce qui concerne la synchronisation. Ceci nous conduit au concept de rendez-vous que nous dvelopperons dans la troisime section. Enfin, nous montrerons que le fait que les canaux d'un rseau soient fifo n'empche pas des comportements pathologiques dans le transit des messages. Aussi nous dvelopperons le concept de rseau fifo qui garantit l'absence de tels comportements et nous montrerons comment muler un rseau fifo au dessus d'un rseau asynchrone quelconque. Au coeur de cette problmatique, se trouve l' ordre causalentre vnements d'une excution sur lequel nous reviendrons plusieurs reprises.

Cours dalgorithmique rpartie Joyce El Haddad et Serge Haddad

Universit Paris-Dauphine : IUP GMI, IUP MIAGE, DESS SITN

2. Contrle de flux
2.1 Contrle point point : le modle producteur / consommateur 2.1.1 Description du problme Considrons deux sites, P le producteur et C le consommateur, tels que le producteur envoie des messages au consommateur via un canal (unidirectionnel). Lorsque l'application du producteur veut envoyer un message au consommateur elle appelle la primitive produire(m) o m est un paramtre par valeur de message. Lorsque l'application du consommateur veut recevoir un message du producteur, elle appelle la primitive consommer(m) o m est un paramtre par rfrence de message. La vitesse dexcution de P ntant assujettie aucune contrainte, il est possible que le rythme de production et dmission de messages de P soit suprieur au rythme avec lequel C les consomme. Dans une telle situation, quelque soit le nombre d'emplacements prvus pour stocker les messages reus et non encore consomms, ceux-ci peuvent se trouver occups alors quun nouveau message arrive. Ncessairement soit le nouveau message est rejet, soit l'un des messages stocks est cras par le nouvel arrivant. Nous devons donc mettre en place un contrle de flux pour prvenir ce problme. 2.1.2 Description de la solution Afin de rsoudre ce problme d lasynchronisme des sites P et C, une solution consiste asservir la production et lmission des messages par le site P des informations de consommation fournies par C. Le producteur disposera ainsi d'autorisations de produire (initialement gales la taille du tampon du consommateur). A chaque envoi, celui-ci consomme une autorisation. De son ct, le consommateur envoie une autorisation la fin de chaque appel consommer signifiant qu'une place s'est libre dans le tampon. Bien entendu, le consommateur ne peut consommer que si son tampon n'est pas vide. 2.1.3 Algorithme Nous dbutons notre spcification par les deux variables de contrle de chacun des sites. Nbmess, la variable du consommateur indiquant le nombre de messages dans le tampon Nbcell, la variable du producteur indiquant le nombre d'autorisations D'autre part la gestion du tampon chez le consommateur amne dfinir les variables suivantes : T, le tampon de taille N contenant les messages consommer in, l'indice d'insertion dans le tampon out, l'indice d'extraction du tampon Le tampon est gr de manire circulaire : lorsqu'un indice est en fin de tableau, il est remis zro. Algorithme du producteur Var Nbcell : entier initialis N; Cours dalgorithmique rpartie Joyce El Haddad et Serge Haddad 2

Universit Paris-Dauphine : IUP GMI, IUP MIAGE, DESS SITN

produire(m) Dbut Attendre(Nbcell>0); envoyer_(C,m); Nbcell = Nbcell - 1; Fin sur_rception_de(C,Ack) Dbut Nbcell = Nbcell + 1; Fin Algorithme du consommateur Var Nbmess : entier initialis 0; in,out : 0..N-1 initialis 0;

consommer(m) Dbut Attendre(Nbmess > 0); m = T[out]; out = (out + 1) % N; Nbmess = Nbmess - 1; envoyer_(P,Ack); Fin sur_rception_de(P,m) Dbut T[in] = m; in = (in + 1) % N; Nbmess = Nbmess + 1; Fin Remarque : Lorsque la valeur de l'indice in est gale celle de out, ceci signifie soit que le tampon est plein soit qu'il est vide. Aussi il est ncessaire d'introduire la variable Nbmess pour tester l'existence d'un message dans le tampon. 2.1.3 Un exemple de droulement produire(m) Site P m Site C consommer(m') Ack dpt de m incrmentation

Figure 2.1 : Un extrait d'une excution du producteur / consommateur

Cours dalgorithmique rpartie Joyce El Haddad et Serge Haddad

Universit Paris-Dauphine : IUP GMI, IUP MIAGE, DESS SITN 2.1.4 Vrification de l'algorithme Nous nous limiterons ici la preuve du non dbordement du tampon. Nous allons dmontrer que pour tout tat accessible, l'galit suivante est vrifie : Nbmess+Nbcell+Nbt=N o Nbt dsigne le nombre de messages en transit (application ou acquittement). Ceci garantit qu'un message d'application arrivant ne trouve jamais le tampon plein. Nous le dmontrons par induction. L'galit est vrifie initialement. Supposons la vraie dans un tat donn et examinons l'effet de chacune des primitives : aprs un appel produire, Nbcell est dcrment et Nbt est incrment aprs un appel consommer, Nbmess est dcrment et Nbt est incrment aprs une rception d'un message, Nbmess est incrment et Nbt est dcrment aprs une rception d'un acquittement, Nbcell est incrment et Nbt est dcrment Dans tous les cas, l'galit reste vrifie. 2.1.4 Une amlioration possible L'envoi de messages d'acquittement peut se rvler coteux puisque le contenu informatif de ces messages est nul : seule leur arrive provoque une incrmentation. Une amlioration lmentaire consiste remarquer que sur une liaison bidirectionnelle, chaque site (selon le canal) joue le rle du producteur et du consommateur. Il suffit alors de retarder (selon un dlai configurer) l'envoi des acquittements. Si, avant l'expiration du dlai, un message d'application doit tre envoy, on lui adjoint le nombre d'acquittements retards et ceci moindre cot. Dans le cas contraire, on envoie un message d'aquittements multiples, ce message tant envoy sur un canal peu occup (donc sans gne pour l'application). Dans tous les cas, on rarme un nouveau "time-out" lors du prochain acquittement envoyer. 2.2 Gnralisation aux producteurs multiples On considre une gnralisation du modle producteur-consommateur dans lequel on a p sites de production P1,,Pp et toujours un seul site de consommation C. Comme dans le modle prcdent, le consommateur dispose d'un tampon de stockage de N cellules (figure 2.2).

P1,,Pi ,,Pp

C Tampon

Figure 2.2 : p producteurs et un consommateur

Les interfaces qui dfinissent le service sont inchanges : produire(m) et consommer(m). Une application vidente de ce schma est la gestion des requtes dans un modle client-serveur : les producteurs sont les clients et le consommateur est le serveur. On ne s'intresse pas ici au traitement des requtes.

Cours dalgorithmique rpartie Joyce El Haddad et Serge Haddad

Universit Paris-Dauphine : IUP GMI, IUP MIAGE, DESS SITN Le principal problme soulev par ce modle est le partage du tampon entre les diffrents producteurs. 2.2.1 Une premire solution par partage statique La solution la plus simple consiste partager a priori (do le caractre statique de la solution) les N emplacements entre les p producteurs. Le site Pi se voit attribuer Ni places avec Ni = N (ce qui implique N p). Ds lors il n' y a plus comptition entre les producteurs puisquils ne partagent plus de ressources. D' un certaine manire, cette solution consiste appliquer la solution prcdente pour p canaux de communication moyennant un multiplexage des messages lors de la consommation. Chaque site producteur ne communique quavec le consommateur : au niveau du contrle, le rseau logique est une toile dont le site C est le centre. Malheureusement cette solution conduit une sous-utilisation des ressources. Considrons la situation o seuls q (<< p) producteurs dsirent produire. Chacun de ces q sites va remplir sa partie du tampon et se trouvera ensuite momentanment bloqu jusqu ce que C consomme des messages alors quil y a de nombreuses cellules disponibles dans le tampon (celles attribues aux autres producteurs). Il est bien connu que ce type d'activit sporadique est caractristique du comportement d'une application rpartie. Il sagit donc l dun inconvnient majeur li toute solution statique.

2.2.2 Distribution d' autorisations sur un anneau logique La solution que nous allons exposer consiste faire circuler des autorisations (correspondant des cellules disponibles) sur un anneau logique constitu de la faon suivante : C,P1, P2,...,Pp ,C. Les producteurs sont placs en ligne, et cette ligne est boucle par le site de consommation. A la structure de communication quest lanneau est associ le moyen standard de l' exploiter le jeton. Il sagit dun message de contrle spcial qui parcourt : lanneau de manire unidirectionnelle; il visite donc tous les sites et ceci de faon rptitive. Dans notre cas particulier, on associe au jeton une valeur val indiquant le nombre de cellules utilisables par les producteurs qui se serviront au passage du jeton. La valeur du jeton dcrot au cours des visites chez les producteurs et crot lors de la visite chez le consommateur du nombre de cellules consommes depuis le dernier passage du jeton. Cependant, il reste un problme rsoudre : de quel nombre d' autorisations a besoin un producteur lorsque passe le jeton ? Si on en reste une gnralisation immdiate de la solution prcdente, l' application qui appelle produire se trouve bloque jusqu' au passage du jeton. Une seule autorisation est alors ncessaire. Cette solution est trs inefficace car le dbit maximum de productions est d' un message par passage de jeton ! Il faut donc dsynchroniser la production de messages du passage du jeton. Pour cela, on ajoute deux "ingrdients" chez chaque producteur : un tampon local et un processus de service appel le facteur. L' application se contente de dposer les messages dans le tampon local et ne se bloque que lorsque le tampon est plein. Le facteur envoie les messages du tampon local destination du consommateur. Pour ce faire, il se sert de deux variables indiquant le nombre de messages de son tampon et le nombre d' autorisations dont il dispose. Tant qu' il a une autorisation, il envoie un message. Lorsque le jeton arrive, le producteur cherche obtenir

Cours dalgorithmique rpartie Joyce El Haddad et Serge Haddad

Universit Paris-Dauphine : IUP GMI, IUP MIAGE, DESS SITN autant d'autorisations que de messages envoyer pour lesquels il ne dispose pas d'autorisation. Nous dtaillons maintenant l'algorithme. Algorithme du producteur Pi Chaque producteur Pi maintient les variables locales suivantes : Ti[0..Ni -1] : tableau contenant les messages produits par le producteur Pi. ini : indice d'insertion du tampon Ti, initialis 0. outi : indice d'extraction du tampon Ti, initialis 0. nbmessi : nombre de messages stocks dans Ti, initialis 0. nbauti : nombre dautorisations denvoi de messages initialis 0. Succi : identificateur du site successeur du site i. Si i < m alors Succi prend la valeur Pi+1 sinon la valeur de cette variable sera lidentificateur du site consommateur. tempi : variable de calcul temporaire. Elle prend la valeur minimale entre le nombre de cellules que le site dsire rserver et le nombre de cellules libres associ au jeton. Remarque : d'aprs la gestion de l'algorithme on aura tout instant nbmessi nbauti. produire (m) Dbut Attendre(nbmessi<Ni); Ti[ini] = m; ini = (ini + 1) % Ni; nbmessi++; Fin Lorsquun site Pi reoit le jeton de son prdcesseur sur lanneau, il calcule tempi, le minimum entre le nombre d'autorisations quil veut obtenir et la valeur associe au jeton. A partir de tempi, il met jour la variable val associe au jeton. Ensuite, il expdie ce dernier son successeur sur lanneau. sur_rception_de(j,(jeton,val)) Dbut tempi = Min((nbmessi-nbauti),val); nbauti += tempi; val -= tempi; envoyer_(succi,(jeton,val)); Fin Comme pour la plupart des processus de service, le code de Facteuri consiste en une boucle infinie o chaque tour consiste en une attente (d'autorisations) suivi d'un traitement (l'envoi d'un message). Facteuri Dbut Tant que(vrai) Attendre(nbauti>0); envoyer_(consommateur,(app,Ti[outi])); outi = (outi + 1) % Ni; nbauti--; nbmessi--; Fin tant que Fin Cours dalgorithmique rpartie Joyce El Haddad et Serge Haddad 6

Universit Paris-Dauphine : IUP GMI, IUP MIAGE, DESS SITN

Algorithme du consommateur Le site consommateur possde les variables suivantes : T[0..N -1] : un tableau contenant les messages des sites producteurs (le tampon du consommateur). in : lindice d' insertion du tampon initialis 0. T, out : lindice d' extraction du tampon initialis 0. T, nbmess : nombre de messages stocks dans T et non encore consomms initialis 0. nbcell : nombre de cellules libres entre deux passages du jeton initialis 0. sur_rception_de(j,(app,m)) Dbut T[in] = m; in = (in + 1) % N; nbmess++; Fin consommer(m) Dbut Attendre(nbmess>0); m = T[out]; out = (out+1) % N; nbmess--; nbcell++; Fin Sur_rception_de(j,(jeton,val)) Dbut val += nbcell; nbcell = 0; envoyer_(P1,(jeton,val)); Fin 2.2.3 Un scnario d' excution Soit un systme form de trois producteurs P1, P2, P3 et dun consommateur C. Chacun des sites P1 et P3 dispose un tampon de taille 4. Ceux de P2 et C sont respectivement de taille 3 et 5. Nous examinons le comportement de ce systme pendant deux phases. Chaque phase correspond un tour du jeton. Phase 1 Le consommateur envoie le jeton - avec la valeur 5 - vers le premier producteur. Ce producteur a produit le message m1 et sa variable nbmess1 vaut 1. A la rception du jeton, le site P1 obtient une autorisation d' envoi et nbaut1 passe 1 alors que la variable val passe 4. Entre temps, le site P2 produit 3 messages m2, m3 et m4 quil stocke dans son tampon local T2. et la variable nbmess2 passe 3. Le processus applicatif de P2 appelle encore une fois la Cours dalgorithmique rpartie Joyce El Haddad et Serge Haddad 7

Universit Paris-Dauphine : IUP GMI, IUP MIAGE, DESS SITN fonction produire et se bloque car son tampon est plein. A la rception du jeton, le site P2 obtient trois autorisations d'envoi et nbaut2 passe 3 alors que la variable val passe 1. Avant la rception du jeton, P3 a dj produit deux messages et sa variable nbmess3 vaut 2. Quand le jeton arrive, nbaut3 passe 1 ( =min(1,2) ) et val passe 0. A son tour P3 expdie le jeton au site C, son successeur dans lanneau (figure 2.3). m2 m3 consommer(m2)

C 5 m1

m6 m7

P3

(app, m2) (app, m3)

P1 Produire (m1)

produire (m6) produire (m7)

1 4 P2 m2 m3 m4 produire(m2) produire (m3) produire (m4) produire (m5) // blocage

Figure 2.3 : Le premier tour du jeton sur lanneau Phase 2 Pendant ce temps, C a consomm un message incrmentant nbcell. A la rception du jeton avec la valeur 0, il incrmente cette valeur avec nbcell et le jeton entame un nouveau tour avec la valeur 1. Le site P1 a dj produit m8, et donc a 2 messages dans son tampon et nbaut1 positionn 1. A la rception du jeton, P1 met jour la variable val qui passe 0. Ensuite, il expdie le jeton son successeur dans lanneau (figure 2.4).

Cours dalgorithmique rpartie Joyce El Haddad et Serge Haddad

Universit Paris-Dauphine : IUP GMI, IUP MIAGE, DESS SITN

m3 C 1 m6 m7 produire(m8) m1 m8

P3 P1 m2 m3 0

P2 m4 Figure 2.4 : Le deuxime tour du jeton sur lanneau Bien que chaque producteur voit passer le jeton une infinit de fois, il se peut que le jeton passe systmatiquement devant lui partir d' un certain tour avec la valeur nulle. Dans ce cas, le producteur restera en attente infinie d' autorisations. SeulP1 est assur de voir passer le jeton avec une valeur non nulle une infinit de fois. On pourrait bien sr changer l' ordre sur l' anneau chaque nouveau tour mais une solution plus radicale nous permettra la fois de garantir l' quit mais aussi d' accrotre l' efficaci t. 2.2.4 Une solution quitable Dans cette solution, 1. l' anneau est rduit aux sites producteurs qu' on numrote prsent de p-1. 0 2. chaque producteur voit passer le jeton avec une valeur suprieure un seuil, 3. lorsqu' un producteur s' aper qu' aprs sa mise jour, le jeton contient une valeur oit infrieure au seuil, il le renvoie au consommateur, 4. le consommateur conserve le jeton jusqu' ce que sa valeur soit suprieure un deuxime seuil (suprieur ou gal au premier) et le renvoie au producteur suivant sur l'ann eau. Ainsi l' quit est garantie puisque que le jeton est toujours reu avec une valeur suprieure au premier seuil. En rglant les deux seuils, on peut s' ajuster au comportement de l' application. Par exemple, le seuil des producteurs peut correspondre une production moyenne entre deux passages de jeton tandis que le seuil du consommateur peut prendre en compte le nombre de producteurs pour viter un retour trop rapide du jeton. Algorithme du consommateur On ajoute aux variables du consommateur, les variables suivantes : Seuil : constante entire. Elle correspond au seuil au del duquel le consommateur envoie le jeton vers un producteur. Prsent : boolen. Elle prend la valeur VRAI si le consommateur possde le jeton, FAUX dans le cas contraire. Elle est initialise FAUX. Cours dalgorithmique rpartie Joyce El Haddad et Serge Haddad 9

Universit Paris-Dauphine : IUP GMI, IUP MIAGE, DESS SITN Prochain : identificateur du prochain producteur auquel le consommateur va expdier le jeton. A chaque fois que le site C consomme un message, il incrmente nbcell. Au cas o il possde le jeton, C doit tester si cette nouvelle valeur est suprieure la valeur de sa constante Seuil. Dans ce cas, il expdie le jeton au Prochain dans lanneau. consommer(m) Dbut Attendre(nbmess>0); m = T[out]; out = (out+1) % N; nbmess--; nbcell++; Si (Prsent et nbcell > Seuil) Alors envoyer_(Prochain,(jeton,nbcell)); Prsent = Faux; nbcell = 0; Fsi Fin sur_rception_de(j,(app,m)) Dbut T[in] = m; in = (in+1) % N; nbmess++; Fin A la rception du jeton, le site C dtermine lidentit du prochain site producteur auquel il va expdier le jeton. Ensuite, il incrmente le nombre de cellules libres (nbcell) par le nombre de cellules non rserves par les producteurs durant le dernier passage du jeton. Si cette nouvelle valeur est suprieure Seuil, alors C envoie le jeton son prochain et rinitialise nbcell. Dans le cas contraire, il conserve le jeton. Sur_reception_de(j,(jeton,val)) Dbut Prochain = (j+1)%p; nbcell += val; Si (nbcell > Seuil) Alors envoyer_(Prochain,(jeton,nbcell)); nbcell = 0; Sinon Present = Vrai; Fsi Fin Algorithme du producteur Pi Pi possde une nouvelle constante entire : seuili initialise la mme valeur pour tous les producteurs (seuili Seuil) Seule la rception de jeton est diffrente de la solution prcdente. Cours dalgorithmique rpartie Joyce El Haddad et Serge Haddad 10

Universit Paris-Dauphine : IUP GMI, IUP MIAGE, DESS SITN

sur_rception_de(j,(jeton,val)) Dbut tempi = Min(nbmessi-nbauti,val); val -= tempi; nbauti += tempi; Si (val > seuili) Alors envoyer_((i+1)%p,(jeton,val)) ; Sinon envoyer_(C,(jeton,val)); Fsi Fin 2.3 Contrle de flux dans les rseaux tendus Dans les rseaux tendus, le transfert d'un paquet entre deux stations passe par des noeuds intermdiaires spcialiss : les routeurs. La principale tche des routeurs est de dterminer le prochain noeud qui envoyer un paquet en fonction de la destination finale de celui-ci. Le routage peut tre calcul de faon centralise ou distribue. De plus, il peut tre statique ou adaptatif. Dans le premier cas, le routage est tabli une fois pour toutes alors que dans le second, de nouvelles routes peuvent tre calcules en fonction du trafic ou de loprationnalit des lignes de communication ou des routeurs voisins. Hypothse gnrale Dans la suite, nous supposons qu'un routeur (ou une station pour un paquet entrant) conserve un paquet jusqu' ce qu'il soit accept par le prochain routeur. Si le paquet est arriv destination d'une station, le dernier routeur ne le conserve qu'un temps fini en l'absence de rponse de la station. Un des problmes lis la circulation des paquets travers le routeur est connu sous le nom de congestion. Supposons qu'un paquet soit reu sur un routeur dont le tampon est plein. ce routeur rejettera le paquet. Dans ce cas, le routeur qui a mis le paquet devra le conserver dans son tampon, avec son tour un risque de saturation de son tampon. Lorsqu'en une partie du rseau, ce phnomne se produit, on parle de congestion. Par analogie avec le trafic routier, on pourra imaginer que les tampons sont les routes et qu'un envoi de paquet correspond un changement de route (les liaisons tant alors les carrefours). En prsence de congestion, le rseau fonctionne au ralenti. Linterblocage est un cas extrme de congestion qui se produit lorsqu'un sous-ensemble de routeurs se retrouve avec ses tampons pleins et que le prochain noeud de n'importe quel paquet d'un ces tampons appartient ce sous-ensemble. Dans l'exemple de la figure 2.5, le routeur X tente denvoyer ces paquets aux routeurs Y et Z, qui eux aussi ont les mmes intentions. rejet rejet rejet rejet Z rejet rejet

Figure 2.5 : Une situation dinterblocage

Cours dalgorithmique rpartie Joyce El Haddad et Serge Haddad

11

Universit Paris-Dauphine : IUP GMI, IUP MIAGE, DESS SITN Deux types de stratgie sont possibles pour traiter la congestion et l'interblocage. Les stratgies dites optimistes consistent adjoindre aux rseaux un mcanisme de dtection qui reconnait de telles situations. Lorsque la congestion est dtecte, un mcanisme de gurison se met en place. Par exemple, la dtection pourrait consister calculer le taux de saturation moyen du tampon, sur un intervalle donn et de tester qu'il est au-dessus d'un certain seuil. La gurison consisterait supprimer des paquets et envoyer vers les sources des flux des demandes de ralentissement ("feedback"). Les stratgies optimistes sont adaptes des interconnexions de rseaux gres par un ensemble d'oprateurs o la possibilit d'un contrle global est illusoire. Les stratgies dites pessimistes mettent en oeuvre un mcanisme de prvention de l'interblocage qui rduit par voie de consquence les risques de congestion. Ces solutions ncessitent d'adopter la mme politique sur tous les routeurs et donc l'existence d'un unique oprateur. Nous prsentons ci-dessous deux techniques de prvention des interblocages. Ce choix ne prjuge pas d'une apprciation sur la supriorit d'un des types de stratgie sur l'autre. Il se trouve simplement que les techniques optimistes sont des heuristiques et ne prsentent donc pas un intrt algorithmique majeur. 2.3.1 Structuration des tampons Les techniques de structuration des tampons suppose que l'on exploite des informations sur le routage connues a priori (voir [MS80a] pour une approche gnrale). De manire vidente, plus un algorithme sera adaptatif moins l'on pourra s'appuyer sur le routage. La premire information que nous allons exploiter est le nombre maximum N de routeurs traverss par un paquet. Dans le cas d'un routage statique optimal, N est le diamtre du graphe; dans le cas d'un routage statique quelconque, N est born par le nombre de routeurs. Si le routage est adaptatif, l'tablissement d'une borne s'obtient par analyse de l'algorithme utilis. Certains algorithmes ne bornent pas le nombre de routeurs traverss et sont inadquats pour supporter cette technique. Le tampon d'un routeur est partionn en N sous-tampons indics de 1 N. Les rgles cidessous dfinissent des contraintes de placement lors de la rception d'un paquet en fonction de sa provenance. Ceci implique que parmi les informations de contrle d'un paquet se trouve l'indice de son paquet d'origine. R1 Un paquet entrant (c'est dire provenant d'une station connecte au rseau) est insr dans le sous-tampon dindice 1. R2 Un paquet provenant dun sous-tampon indice i est plac dans le sous-tampon dindice i+1. D'aprs l'hypothse faite sur le routage, le sous-tampon d'indice i+1 existe toujours (mme s'il est ventuellement plein). Proposition L'application des rgles prcdentes prvient l'interblocage. Preuve Nous raisonnons par l'absurde. Supposons qu'il existe un ensemble de sous-tampons se bloquant mutuellement. Autrement dit, ces sous-tampons sont pleins et tout paquet d'un de ces Cours dalgorithmique rpartie Joyce El Haddad et Serge Haddad 12

Universit Paris-Dauphine : IUP GMI, IUP MIAGE, DESS SITN sous-tampons doit tre expdi vers un autre sous-tampon de cet ensemble. Choisissons l'un de ces tampons T d'indice i. En vertu de la rgle 2, T est bloqu par des sous-tampons d'indice i+1. En appliquant le mme raisonnement ces sous-tampons, on parvient, par itration, la conclusion qu'au moins un sous-tampon T' d'indice N est en interblocage. Or par hypothse sur le routage, ces paquets sont des paquets sortants ( destination des stations). D'aprs l'hypothse gnrale, ces paquets ne sont pas conservs indfiniment et T' ne peut donc tre en interblocage. D'o la contradiction. Une amlioration Cette solution est relativement inefficace car dans la mesure o N est le nombre maximum de routeurs traverss, peu de paquets traverseront les sous-tampons dindice lev entrainant une sous-utilisation de ces ressources. On pourrait bien sr choisir de sous-dimensionner un tampon d'indice lev par rapport un tampon de plus faible indice. Le problme de la sousutilisation persisterait alors mais un degr moindre. Pour rsoudre plus radicalement le problme, nous supposons que le routage nous permet de connaitre une borne sur le nombre de routeurs traverss par paire (source,destination). Ainsi quand un paquet p pntre dans le rseau, on adjoint ses informations de contrle, cette borne Np. Trs souvent, la borne Np sera largement infrieure N. A chaque routeur travers, la borne est dcrmente. Ainsi elle indique tout moment, une borne sur le nombre de routeurs qui restent traverser (en incluant le routeur qui reoit le paquet). Nous allons relcher les contraintes des rgles R1 et R2, qui se rcrivent comme suit : R1 Un paquet entrant p qui doit traverser au plus Np routeurs est insr dans un soustampon dont l'indice appartient l'intervalle [1..N-Np+1]. R2 Un message provenant dun sous-tampon dindice i et ayant encore traverser au plus Np' routeurs est plac dans un sous-tampon dont l'indice appartient [i+1..N-Np'+1]. La rgle 2 est toujours applicable car sur le routeur prcdent l'indice i du sous-tampon vrifie i N-(Np'+1)+1 (en vertu de la rgle 1 ou 2) ce qui est quivalent i+1 NNp'+1. Proposition L'application des rgles prcdentes prvient l'interblocage. Preuve La preuve est similaire la prcdente en remarquant que la contradiction provient du fait que les paquets d'un sous-tampon sont bloqus en attente de place dans un sous-tampon d'indice suprieur. Plusieurs choix de sous-tampons sont possibles la rception d'un nouveau paquet et il est judicieux de slectionner le sous-tampon non plein d'indice le plus faible. En effet, cela laisse un intervalle plus grand pour le choix lors du prochain noeud traverser. Dans [TU81], ce type de technique est employ sans dcomposition en sous -tampons. 2.3.2 Estampillage des paquets Nous souhaitons laborer une technique de prvention ne reposant pas sur une connaissance du routage. Aussi nous ferons cette fois-ci l'hypothse que chaque routeur dispose d'une Cours dalgorithmique rpartie Joyce El Haddad et Serge Haddad 13

Universit Paris-Dauphine : IUP GMI, IUP MIAGE, DESS SITN horloge qui progresse avec le temps. Nous n'exigeons pas que les horloges soient synchronises (voir le chapitre sur le temps). Cependant, plus les horloges seront synchronises, plus le traitement des paquets en cas de congestion sera quitable. Le principe de cette solution consiste privilgier les paquets les plus gs sachant qu'un paquet demeurant dans le rseau finira par tre g et bnficiera de cette priorit. Nous devons tout d'abord dfinir un ge de telle sorte que deux paquets n'aient jamais le mme ge. Dfinition Un ge est un couple (heure,identit de site). Soient deux ges (h1,i1) et (h2,i2) alors (h1,i1)<(h2,i2)si et seulement si : 1. h1<h2 ou 2. h1=h2 et i1<i2 Lorsqu'un paquet pntre sur le rseau, le premier routeur lui ajoute une information de contrle appele estampille (qui sera son ge) constitue de son heure d'arrive et de l'identit de ce routeur. Deux messages ne peuvent jamais avoir le mme ge car si les heures sont les mmes alors les identits sont diffrentes. Nous supposons de plus que chaque routeur dispose d'une cellule (tampon rduit un lment) par ligne entrante. Cette cellule sera appele cellule d' change Nous dfinissons . maintenant le traitement d'un paquet p venant du routeur X et arrivant sur le routeur Y. R1 Si le tampon de Y nest pas plein, alors Y stocke le paquet p.

R2 Si le tampon de Y est plein et quil a un paquet p' expdier X, alors Y stocke p dans la cellule d'change associe X si celle-ci est vide et envoie p' vers X "pour change" avec p. Lorsque p' arrive, X le place dans la cellule occupe par p. A la rception de l'acquittement de p', Y place son tour p dans la cellule occupe par p' et libre la cellule d'change. Si la cellule d'change est pleine, il rejette le paquet en indiquant "cellule d'change pleine". R3 Si le tampon de Y est plein, quil n'a pas de paquets expdier X mais que le plus jeune des paquets de son tampon p' est plus jeune que p alors il procde comme indiqu la rgle 2. Ceci revient dtourner p' de sa route initiale. R4 Si aucune des rgles prcdentes n'est applicable alors Y rejette p pour cause de "tampon plein". Nous spcifions aussi la rgle du choix des paquets envoyer par un routeur sur une ligne : 1. si celui-ci a des paquets pour change, il les envoie sur la ligne en fonction de l'ordre d'arrive dans le tampon ; 2. en dehors de ces paquets, si le routeur a des paquets rejets pour cause de "cellule d'change pleine", il renvoie uniquement le paquet dont le rejet est le plus ancien jusqu' ce qu'il soit rejet pour "tampon plein" ou accept (en l'intercalant rgulirement si ncessaire entre des paquets pour change).

Cours dalgorithmique rpartie Joyce El Haddad et Serge Haddad

14

Universit Paris-Dauphine : IUP GMI, IUP MIAGE, DESS SITN Proposition L'application des rgles prcdentes prvient l'interblocage. Preuve Premirement une cellule d'change ne reste jamais indfiniment pleine puisque le paquet pour change correspondant sera envoy (rgle des envois), reu, accept et acquitt. Notons ensuite qu'un paquet rejet pour cause de "cellule d'change pleine" finira par tre accept ou rejet pour "tampon plein". Si tel n'est pas le cas, alors soit ce paquet est rmis indfiniment sur la ligne, soit un autre paquet rejet antrieurement pour la mme raison est rmis indfiniment. Ceci signifie qu'un tel paquet trouvera indfiniment la cellule pleine. En raison du premier point, cela signifie qu'elle se remplit indfiniment. Or la cellule d'change n'est pas utilise par les paquets "pour change" et ce sont les seuls autres paquets mis par le routeur. D'o la contradition. Pour dmontrer l'absence d'interblocage, nous raisonnons par labsurde. Supposons qu'il existe un scnario d'envois de paquets sur le rseau tel qu'au moins un paquet reste indfiniment dans le rseau. Puisque les horloges croissent, parmi ces paquets il en existe un plus g not p (pas ncessairement le premier entr sur le rseau). L'ensemble des paquets plus gs que p est fini toujours en raison de la croissance des horloges. Aucun de ces paquets ne reste indfiniment dans le rseau d'aprs la dfinition de p. Donc il existe un instant partir duquel p est (et restera) le plus g des paquets du rseau. Mais dans ce cas, ni la rgle R3 o il jouerait le rle de p, ni la rgle R4 ne lui sont plus applicables. De plus, il ne peut tre rejet indfiniment pour cause de "cellule d'change pleine" (voir le point prcdent) donc il sera accept au bout d'un temps fini par tout routeur. Par consquent, il sortira du rseau au bout d'un temps fini. D'o la contradiction.

Cours dalgorithmique rpartie Joyce El Haddad et Serge Haddad

15

Universit Paris-Dauphine : IUP GMI, IUP MIAGE, DESS SITN

3 Communication synchrone : le rendez-vous

3.1 - Le schma du rendez-vous Le rendez-vous est un schma de communication entre processus support par certains langages (ADA, CSP, Occam, etc.). Dans sa forme la plus simple, ce schma met en jeu deux sites. La communication se droule en deux phases. Durant la phase de synchronisation, le premier processus qui appelle la primitive de rendez-vous est bloqu jusqu' l'appel correspondant par le deuxime processus. S'engage alors la phase d'change de donnes dont les modalits sont propres au langage et qui ne prsente pas d'intrt algorithmique. Aussi dans la suite, nous nous limiterons l'tude de la phase de synchronisation. Dans une forme plus labore, un site peut souhaiter un rendez-vous avec un site choisi parmi un ensemble fix lors de l'appel la primitive. Ceci peut tre le cas quand : un service est assur par un ensemble de serveurs redondants. Dans ce cas, un client souhaite un rendez-vous avec l'un quelconque des serveurs pour soumettre sa requte. un service est assur par un serveur scuris qui n'accepte des requtes que d'un ensemble de clients identifis. Dans ce cas, le serveur souhaite un rendez-vous avec l'un quelconque de ces clients pour traiter sa requte. C'est cette forme que nous allons tudier [Bag89]. Enonons tout d'abord les proprits attendues de notre algorithme : A aucun instant, le service ne peut engager l'application dans deux rendez-vous simultanment. Ceci est un exemple de proprit de sret. Si un instant donn, un rendez-vous est possible en raison des diffrents appels en cours alors un rendez-vous doit avoir lieu au bout dun temps fini. Ceci est un exemple de proprit de vivacit. Notons que rien n'est prcis sur l'identit des participants au rendezvous. 3.2 Principes de la solution Afin de dgager les principes d'une solution au problme du rendez-vous, nous allons d'abord exhiber deux problmes que tout algorithme doit traiter. Nous illustrons ces problmes l'aide d'exemples. Exemple 1 Soit une application rpartie sur trois sites S1, S2 et S3. L'application sur chacun des sites souhaite peu prs au mme moment obtenir un rendez-vous avec l'un quelconque des deux autres sites. Sans prjuger d'une solution, on peut penser que pour obtenir un rendezvous le service de chaque site interroge le service d'un autre site pour savoir si le rendez-vous est aussi souhait. S1 RV({S1,S2}) S3 RV({S2,S3})

RV({S3,S1}) S2

Figure 2.6 : Des demandes de rendez-vous symtriques Cours dalgorithmique rpartie Joyce El Haddad et Serge Haddad 16

Universit Paris-Dauphine : IUP GMI, IUP MIAGE, DESS SITN

Ainsi sur la figure 2.6, le service de S1, suite l'appel par l'application de RV({S2,S3}) envoie une requte de rendez-vous au premier site de sa liste S2. De manire similaire, S2 a envoy sa requte S3, celui ayant fait de mme avec S1. Examinons les diffrents choix qui s'offrent S2 lors de la rception de la requte de S 1. Comportement 1 Comme S2 "est provisoirement engag" par sa requte S3, il rejette la requte du site S1. Par symtrie, chacun des autres sites S1 et S3 rejettent les requtes reues. La situation peut se reproduire avec le second lment de la liste. Ainsi bien que des messages soient continuellement changs, l'algorithme ne progresse pas vers un rendez-vous. Ce type de blocage est appel "livelock" au sens o bien que les services soient actifs, cette activit est inutile. Comportement 2 S2 accepte la requte de S1 et annule celle faite S3. Par symtrie, S1 et S3 annulent les requtes envoyes. La situation est similaire la prcdente avec un surcot en nombre de messages changs. Il s'agit ici aussi d'un "livelock". Comportement 3 De manire opportuniste, S2 attend une rponse de S3. pour rendre sa rponse S1 : si S3 rejette sa requte il accepte celle de S1 sinon il la rejette. Dans tous les cas de figure, il semble assur d'un rendez-vous. Malheureusement par symtrie, les autres sites font de mme et tous les sites restent bloqus en attente dune rponse. On affaire ici un interblocage de communication. Cette fois-ci, aucune activit n'est plus prsente. On appelle cette situation un "deadlock". On se trouve confront l'un des paradoxes de l'algorithmique rpartie. Pour simplifier la conception, on recherche la symtrie mais les solutions compltement symtriques ne garantissent pas la progression de l'algorithme. Il faut introduire faible dose l'asymtrie. Ceci peut se faire avec un code identique en s'appuyant sur ce qui distingue chaque site, leur identit. Ici selon l'identit de l'metteur d'une requte reue alors que le site attend la rponse sa propre requte, celui-ci choisira entre le comportement 1 et le comportement 3. Ainsi supposons que Si attende la rponse de Sk et qu'il recoive d'une requte venant de Sj. Dans ce cas, si j > i alors S i retarde sa rponse S j sinon il rejette cette requte.

ack req

S1 rej req req S2 rej

S3

Figure 2.7 : Asymtrie de comportement La figure 2.7 illustre l'application de cette rgle l'exemple prcdent : S1 retarde sa rponse, S3 (respectivement S2) rejette la demande de S2 (respectivement S1). S1 peut rpondre favorablement S3 et un rendez-vous aura lieu.

Cours dalgorithmique rpartie Joyce El Haddad et Serge Haddad

17

Universit Paris-Dauphine : IUP GMI, IUP MIAGE, DESS SITN Dans le cas gnral, l'absence d'interblocage se vrifie par un raisonnement similaire celui dvelopp lors de la structuration des tampons en notant qu'un site ne peut tre bloqu que par un site d'identit infrieure. Exemple 2 Soit une application rpartie sur deux sites S1 et S2. Supposons que l'application du site S1 dsire un rendez-vous avec S2. Comme prcdemment, le service met une requte de rendez-vous. A la rception, le service du site S2 dont l'application n'est pas cet instant interesse par un rendez-vous rejette la requte. Que doit faire le service du site S1 la rception de ce rejet? Il pourrait aprs un dlai, remettre sa requte. Ceci soulve le problme de la configuration du dlai : trop court, il peut engendrer un trafic inutile sur le rseau; trop long, il peut retarder le fonctionnement de l'application. On remarque que dans le contexte du rendez-vous, il est inutile de retransmettre une requte. Quand l'application du site S2 souhaitera un rendez-vous, son service enverra une requte aussitt accepte. Autrement dit, puisqu'il faut tre deux pour le rendez-vous, il suffit qu' tout instant l'un des deux ait l'initiative du rendez-vous. La mise en oeuvre de cette prise d'initiative se fait par l'intermdaire d'un jeton par paire de sites {i,j}. Le site qui possde le jeton a le droit d'envoyer une requte et il perd ce droit avec l'envoi de telle sorte qu'il n'y aura jamais de rmission et ceci sans perdre la possibilit du rendez-vous. La rpartition initiale des jetons sur les sites est arbitraire ; par commodit de programmation, on donnera un jeton associ une paire de sites au site de plus grande identit. 3.3 Graphe d'tat d'un service de rendez-vous Avant d'crire l'algorithme, nous allons en donner une reprsentation abstraite l'aide d'un graphe d'tat du service d'un site. Les tats sont reprsents par les noeuds du graphe et les arcs correspondent aux transitions d'tats. Chaque transition respecte la syntaxe : garde actions o la garde est une expression boolenne traduisant les conditions d'occurence de la transition et les actions indiquent les modifications des variables locales du service. La garde ou les actions peuvent tre omises. De plus, afin de rendre plus compacte la reprsentation, nous notons j?m la rception d'un message m venant du site j par le service et j!m l'envoi par le service au site j du message m. Lorsque l'application du site i n'a pas appel la primitive de rendez-vous, le service est au repos. A l'appel de la primitive de rendez-vous RV, la variable Ei est initialise avec le sous-ensemble des sites, possibles correspondants du rendez-vous. Le site passe l'tat encours. Dans cet tat, le site recherche un candidati c'est dire un site de Ei pour lequel il possde le jeton associ la paire {i,candidati}. La prsence des jetons est mmorise dans le tableau de boolens jetoni. Aprs l'envoi d'une requte candidati, le service passe alors l'tat attente-sans-retarder. A la rception d'un acquittement, il passe l'tat succs puis au retour de la primitive (ayant renvoy l'application le site retenu) de nouveau au repos. En cas de rejet, il retourne encours pour rechercher un autre candidati. Alors que le site est dans l'tat attente-sansretarder, celui-ci peut recevoir une requte qui lui conviendrait; il applique alors la procdure dcrite dans l'exemple 1 et passe l'tat attente-en-retardant o le site retard est indiqu par la variable retardi. Dans cet tat, quelque soit la rponse du

Cours dalgorithmique rpartie Joyce El Haddad et Serge Haddad

18

Universit Paris-Dauphine : IUP GMI, IUP MIAGE, DESS SITN candidati, le site i passera l'tat succs avec ventuellement un changement d'identit de candidati. Il devra de toutes faons envoyer une rponse retardi. Dans un tat o le site n'est pas en cours de service (repos) ou ventuellement bloqu (encours, attente-sans-retarder, attente-en-retardant), il faut prendre en compte les ventuelles rceptions de requtes. Deux cas mritent une explication. Si l'on reoit une requte dans l'tat attente-en-retardant on la rejette car, de toutes faons, on est assur d'un rendez-vous. Si l'on reoit une requte d'un site de Ei dans l'tat encours, on l'accepte et on passe directement l'tat succs.

j?reqj!rej;jetoni[j]=V repos RV(Ei)

renvoyer(candidati) j?rejretardei!ack; candidati=retardi succs j?req et j Ei j!ack;candidati=j; jetoni[j]=V

j?ack retardi!rej j?reqj!rej; jetoni[j]=V attente en retardant j?ack en cours j?req et jEi j!rej; jetoni[j]=V jEi et jetoni[j]=V j!req;candidati=j; jetoni[j]=F

j?req et jEi et j>i jetoni[j]=V;retardi=j

j?req et (j Ei ou j<i) j!rej;jetoni[j]=V

attente sans retarder j?rej

Figure 2.8 : Graphe d'tats d'un site

Cours dalgorithmique rpartie Joyce El Haddad et Serge Haddad

19

Universit Paris-Dauphine : IUP GMI, IUP MIAGE, DESS SITN 3.3 Algorithme du rendez-vous Variables du site i Ei : ensemble des identits des sites avec lesquels i dsire un rendez-vous. tati : tat du site valeur dans {repos,encours,attente,succs} initialis repos retardi : identit du site retard par i. Par convention lorsque i ne retarde aucun site, sa valeur est i (sa valeur initiale). jetoni[1..N] : tableau de boolens indiquant la prsence des jetons. Initialement, jetoni[j] = (ij). candidati : identit du site candidat courant. L'interface de service se rsume la primitive RV(Ei) qui doit renvoyer l'identit d'un site de Ei avec lequel le rendez-vous est engag. A chacun des trois types de messages est associ un traitement. Notons qu'une rception ne peut intervenir dans l'tat succs car c'est un tat dans lequel on ne se bloque pas (comme repos) et qui n'intervient que durant la primitive de service (contrairement repos). RV(Ei) Dbut tati=encours; Rpter (1) Attendre(candidati Ei et jetoni[candidati]==Vrai); Si tati==encours Alors envoyer_(candidati,req); jetoni[candidati]=Faux; tati=attente; (2) Attendre(tati!=attente); Fsi Jusqu tati==succs; tati=repos; renvoyer(candidati); Fin (1) Si l'attente ne bloque pas le site i alors un candidat a t trouv qui envoyer une requte. Dans le cas contraire, seule la rception d'une requte lui permettra de sortir de l'attente avec l'tat positionn succs. (2) L'attente est toujours bloquante et on en ressort soit dans l'tat succs, soit dans l'tat encours auquel cas i s'engage pour un tour de boucle supplmentaire. sur_rception_de(j,ack) Dbut tati=succs; Si retardi!=i Alors envoyer_(retardi,rej); retardi=i; Fsi Fin sur_rception_de(j,rej) Cours dalgorithmique rpartie Joyce El Haddad et Serge Haddad 20

Universit Paris-Dauphine : IUP GMI, IUP MIAGE, DESS SITN Dbut Si retardi=i Alors tati=encours; Sinon tati=succs; envoyer_(retardi,ack); candidati=retardi; retardi=i; Fsi Fin sur_rception_de(j,req) Dbut jetoni[j]=Vrai; Si (tati==repos) ou (j Ei) Alors envoyer_(j,rej); Sinon si tati==encours Alors tati=succs; envoyer_(j,ack); Sinon si (retardi!=i) ou (j<i) Alors envoyer_(j,rej); Sinon retardi=j; Fsi Fin

Cours dalgorithmique rpartie Joyce El Haddad et Serge Haddad

21

Universit Paris-Dauphine : IUP GMI, IUP MIAGE, DESS SITN

4 Qualit de service : le rseau fifo

4.1 Un exemple introductif Supposons qu'une base de donnes soit duplique sur trois sites afin d'assurer une tolrance aux pannes et de diminuer les temps de rponse par rpartition de la charge. Une lecture ne pose aucun problme de gestion tandis qu'une mise jour de la base ncessite un mcanisme de synchronisation pour garantir la cohrence entre les diffrentes copies. Dcrivons tout d'abord un mcanisme trs simple reposant sur la circulation d'un jeton entre les trois sites. Lorsqu'un site dsire Si effectuer une mise jour, il attend le passage du jeton. Puis Si modifie sa copie et diffuse un message de mise jour MAJ contenant les modifications (figure 2.9). Chaque site, qui reoit un message MAJ, enregistre les changements dans sa propre copie et renvoie un acquittement. Lorsque le site initiateur de la modification a reu tous les acquittements, il libre le jeton. S1 MAJ1 MAJ1 ack MAJ1 ack MAJ1 S2 S3

Jeton

Figure 2.9 : Un mcanisme de mise jour d'une base de donnes duplique Linconvnient de ce mcanisme est son manque de performances car l'initiateur doit attendre tous les acquittements et par consquent le dlai d'une mise jour est au moins celui du serveur le plus lent. Un mcanisme alternatif consisterait librer le jeton sans attendre d'acquittement. Examinons un scnario possible (figure 2.10). Le site S1 effectue sa mise jour, envoie le message de mise jour aux sites S2 et S3 et expdie ensuite le jeton au site S2. Quand ce dernier reoit le message de mise jour, il enregistre les changements. A la rception du jeton, S2 effectue une autre mise jour sur la copie locale quil maintient et diffuse aussi son message de mise jour aux sites S1 et S3. Ce dernier site reoit aussi le jeton. Supposons que la mise jour de S2 arrive S3 avant la premire mise jour. S3 appliquera les changements de S2 puis ceux de S1, ceci conduisant une incohrence de la base de donnes.

Cours dalgorithmique rpartie Joyce El Haddad et Serge Haddad

22

Universit Paris-Dauphine : IUP GMI, IUP MIAGE, DESS SITN

MAJ1

S1 MAJ1

S2 MAJ1 MAJ2 MAJ2 MAJ2

S3

Jeton

MAJ2

Jeton

MAJ2 MAJ1

Figure 2.10 : Deux transactions conduisant des copies incohrentes Si on analyse cette situation, on s'aperoit que trois messages sont l'origine de ce problme : la mise jour de S1 vers S2 qui prcde l'envoi du jeton dont la rception prcde l'envoi de la mise jour de S1 vers S3 (figure 2.11). D'aprs ces relation de prcdence, il semblerait raisonnable que le troisime message soit reu aprs le premier. Or il n'en est rien. S1 MAJ1 Jeton MAJ2 S2 S3

Figure 2.11 : Un comportement "pathologique" du rseau 4.2 L'ordre causal Nous allons maintenant formaliser les contraintes qui interdisent ces comportements pathologiques. Pour raisonner simplement sur les messages, nous dfinissons pour chaque message m quatre attributs : m.emet : identit du site metteur, m.dest : identit du site destinataire, m.hem : heure "locale" de lmission, m.hdest : heure "locale" de rception. Cours dalgorithmique rpartie Joyce El Haddad et Serge Haddad 23

Universit Paris-Dauphine : IUP GMI, IUP MIAGE, DESS SITN

Ici aussi, aucune hypothse n'est faite sur la synchronisation des horloges. D'ailleurs dans ce qui suit, seules des heures d'un mme site sont compares. A titre d'exemple, montrons comment exprimer que les canaux d'un rseau sont fifo. Considrons deux message m et m mis sur un mme canal ; leur ordre de rception doit tre le mme que leur ordre d'mission. Ce qui s'exprime par : m,m' m.emet=m'.emet et m.dest=m.dest et m.hem<m.hem m.hdest < m.hdest Nous voulons prsent introduire l'ordre causal entre deux messages [Lam78]. Cet ordre a pour signification intuitive qu' l'mission du deuxime message, le site metteur pourrait avoir connaissance du premier message et donc que ce premier message a pu avoir une influence sur le second message. Nous dbutons par l'ordre causal immdiat qui caractrise de telles situations uniquement par l'historique d'excution d'un site. Nous noterons "<i" l'ordre causal immdiat. Dfinition Soient m et m' deux messages; alors m <i m' si et seulement si : 1. m.emet = m.emet et m.hem < m.hem ou 2. m.dest = m.emet et m.hdest < m.hem Dans le cas 1, les deux messages sont mis sur le mme site, le premier avant le second. Dans le cas 2, le premier message est reu sur le site qui emettra ensuite le deuxime message. Du point de vue mathmatique, <i n'est pas un ordre. En effet il ne vrifie pas la proprit de transitivit. Ceci nous conduit directement l'ordre causal gnral. Dfinition Soient m et m' deux messages; alors m < m' si et seulement si : m1,...,mn tels que m1 = m et mn = m' 0<k<n, mk <i mk+1 Autrement dit, l'ordre causal est la fermeture transitive de l'ordre causal immdiat et cette fois-ci on a bien affaire un ordre au sens mathmatique. Notons qu'il s'agit d'un ordre partiel car par exemple deux messages mis simultanment sur deux sites diffrents ne peuvent tre en relation causale. Nous sommes maintenant en mesure de caractriser un rseau fifo : dans un tel rseau, si un message en prcde causalement un autre et qu'ils ont tous deux mme destination, alors le premier message sera reu avant le second. Dfinition Un rseau est fifo si et seulement si : m,m' m < m' et m.dest = m.dest m.hdest < m.hdest 4.3 Emulation d'un rseau fifo Comme l'a illustr l'exemple introductif, un rseau asynchrone n'est pas ncessairement fifo (bien que tous ses canaux soient fifo). Pour simplifier la construction d'applications, le service que nous allons dfinir mule un rseau fifo au dessus d'un rseau asynchrone. Cours dalgorithmique rpartie Joyce El Haddad et Serge Haddad 24

Universit Paris-Dauphine : IUP GMI, IUP MIAGE, DESS SITN

4.3.1 Une solution simple mais irraliste Une premire solution consiste envoyer avec un message, la liste des messages qui le prcdent causalement. L'ordre de la liste doit respecter l'ordre causal. Le service de chaque site maintient une liste des messages dont il a connaissance qu'il soit ou non metteur ou rcepteur de ces messages. Initialement cette liste est vide. Lorsque l'application dsire envoyer un message, le service concatne ce nouveau message la liste et envoie au service du destinataire la liste toute entire. A la rception d'une liste, le service concatne sa liste tous les messages de la liste reue absents de sa liste dans l'ordre de leur liste. Pour chaque nouveau message de sa liste, si celui-ci est destination de son application, il le dlivre celle-ci. Examinons l'application de cette solution au comportement pathologique prcdent (figure 2.12). L'application du site S1 dsire envoyer un message m1 au site S3. Le service met jour sa liste avec ce message et envoie la liste rduite ce message. Puis, l'application du site S1 dsire envoyer un message m2 au site S2. Le service complte sa liste qui devient (m1,m2) et l'envoie. Lorsque le service de S2 reoit cette liste, il complte sa liste (initialement vide) et examine les nouveaux messages : il n'est pas destinataire de m1 mais est destinaire de m2. Il le dlivre donc son application. Lorsque l'application de S2 dsire envoyer m3 au site S3 , son service complte sa liste qui devient(m1,m2,m3)et l'envoie au site S3. A la rception de cette liste, le service de S3 complte sa liste (initialement vide) et examine les nouveaux messages : il est destinataire de m1 et le dlivre, il n'est pas destinaire de m2, il est destinataire de m3 et le dlivre. Enfin lors de la rception de la liste associe au message m1, la liste ne contient aucun nouveau message. S1 m1 (m1,m2) S2 dlivrer(m2) (m1,m2,m3) S3

dlivrer(m1) dlivrer(m3)

Figure 2.12 : Elimination du comportement pathologique Le comportement du rseau (vue de l'application) est bien fifo car les messages qui prcdent causalement un message, le prcdent aussi dans toute liste o il apparat. Par consquent si l'un d'entre eux a mme destination que ce message, il sera dlivr avant lui. Cependant au fur et mesure de l'excution de l'application, la taille des listes de messages crot de manire considrable. Il nous faut donc adapter cette solution pour gnrer moins de trafic.

Cours dalgorithmique rpartie Joyce El Haddad et Serge Haddad

25

Universit Paris-Dauphine : IUP GMI, IUP MIAGE, DESS SITN 4.3.2 Une deuxime solution plus efficace La premire ide est de ne transporter qu'une seule fois chaque message et de remplacer la liste des messages qui le prcdent causalement par l'indication de leur existence. Ainsi quand un message arrive, si le service a l'information qu'un autre message destination du mme site le prcde causalement et n'est pas encore reu, alors celui-ci retarde la dlivrance du message l'application. Il reste dterminer quelle abstraction de la liste choisir. La reprsentation retenue doit permettre de dterminer s'il faut retarder la dlivrance d'un message. Compter le nombre de messages de la liste destination d'un site n'est pas suffisant car l'galit de deux compteurs ne signifierait pas ncessairement qu'il s'agit des mmes ensembles de messages. Par contre, si on compte plus finement le nombre de messages de la liste mis par un site destination d'un autre, alors l'abstraction conserve suffisamment d'informations. Ainsi chaque site i maintiendra un tableau de compteurs deux entres appel connaissancei tel que connaissancei[j,k] soit le nombre de messages mis par j destination de k qui prcderaient causalement un message qui serait mis cet instant par i. Chaque message envoy est accompagn de la valeur du tableau l'instant d'mission. A la rception d'un message m, le service du site i dtermine s'il a reu tous les messages qui prcdent causalement m en comparant lment par lment la colonne i de son tableau avec celle du tableau de m. Si c'est le cas, il le dlivre et met jour son tableau en prenant le maximum, lment par lment, des deux tableaux (ce qui est quivalent une fusion de liste) et en prenant compte le message dlivr. Interface du service Le service doit muler un rseau. Il y aura donc une primitive descendante et une primitive montante : mettre_vers(j,m) : primitive du service, appele par l'application pour envoyer un message sur le rseau mul. dlivrer_de(j,m) : primitive de l'application pour traiter les rceptions de message sur le rseau mul, appele par le service lorsqu'un message doit tre dlivr l'application. Comme nous l'avons prcis au premier chapitre, ce type de primitive est utilis par l'algorithme mais n'en fait pas partie. Variables du service connaissancei[1..N,1..N] : tableau dentiers deux dimensions. Initialement, tout les lments de ce tableau sont nuls. N est le nombre de sites. tamponi : tampon des message reus non encore dlivrs initialement vide. Chaque message est stock avec l'identit de son metteur et le tableau envoy avec lui. Le tampon dispose de trois primitives de haut niveau : 1. insrer(lment) qui ajoute un nouvel lment au tampon 2. tester(T,cond) o T est un paramtre formel de tableau et cond, une condition portant sur T et sur connaissancei qui renvoie Vrai s'il existe un lment dont le tableau jouant le rle de T vrifie la condition. 3. extraire(lment) qui extrait l'lment slectionn par la primitive prcdente

Cours dalgorithmique rpartie Joyce El Haddad et Serge Haddad

26

Universit Paris-Dauphine : IUP GMI, IUP MIAGE, DESS SITN Nous faisons le choix de faire transiter tous les messages par le tampon pour diminuer le temps d'excution des rceptions de message et de confier la dlivrance un processus de service, appel ici encore facteuri. Algorithme L'mission d'un message applicatif est prcde connaissancei . Aprs l'envoi, celui-ci est mis jour. mettre_vers(j,m) Dbut envoyer_(j,(connaissancei,m)); connaissancei[i,j]++; Fin de l'encapsulation du tableau

La rception se limite insrer le message dans le tampon du service. sur_rception_de(j,(c,m)) Dbut tamponi.insrer(<j,c,m>); Fin Le facteur, l'instar des processus de service standard, excute une boucle infinie o chaque tour de boucle, il attend de trouver dans son tampon un message qui peut tre dlivr l'application, le dlivre et met jour le tableau connaissancei en n'oubliant pas de compter le message qui vient d'tre dlivr. Facteuri Dbut Tant que(Vrai) Attendre(tamponi.tester(T, k,connaissancei[k,i]T[k,i]); Tamponi.extraire(<j,c,m>); connaissancei=Max(connaissancei,c); // maximum lment par lment connaissancei[j,i]++; dlivrer_de(j,m); Fin tant que Fin Remarquons que l'algorithme fonctionne correctement mme si on ne fait plus l'hypothse que les canaux du rseau asynchrone sont fifo. Il reste cependant un problme rsoudre : comment dimensionner les compteurs sachant qu'ils ne cessent de crotre? Une solution consiste calculer, partir d'une borne suprieure sur la dure dexcution de lapplication et d'une borne infrieure sur l'intervalle entre deux envois de messages, une borne suprieure sur le nombre de messages qui peuvent transiter dans un canal. Ce problme sera nouveau abord dans le cadre des horloges logiques au cours du chapitre sur le temps. Cours dalgorithmique rpartie Joyce El Haddad et Serge Haddad 27

Universit Paris-Dauphine : IUP GMI, IUP MIAGE, DESS SITN

5 Exercices
Sujet 1 L'algorithme de rendez-vous rparti vu en cours garantit que si au moins un rendez-vous peut avoir lieu entre les diffrents demandeurs, alors l'un de ces rendez-vous aura lieu. Il ne garantit cependant aucune proprit d'quit dans le choix du rendez-vous. Question 1 Exhibez un scnario avec trois sites, o le site 3 attend indfiniment un rendezvous avec l'un quelconque des sites 1 et 2 alors que : une infinit de rendez-vous ont lieu entre les sites 1 et 2, le site 3 apparat une infinit de fois (mais pas toutes les fois) comme partenaire possible du site 1 et du site 2 dans leurs demandes successives de rendez -vous. Pour remdier ce problme, chaque site associe un poids variable aux autres sites initialis avec l'identit du site concern. Lorsqu'un site i dsire un rendez-vous, il s'adresse au partenaire potentiel j de moindre poids pour lequel il possde le jeton (i,j). Lorsqu'un site i obtient un rendez-vous avec le site j il rvalue le poids du site j comme tant le maximum des poids des autres sites +1. Question 2 Dcrivez les variables de cette version de l'algorithme et leur initialisation. Question 3 crivez la nouvelle version de l'algorithme. Question 4 Reprenez le scnario de la question 1 et montrez qu'avec ce nouvel algorithme le site 3 finit par avoir un rendez-vous. Question 5 Quel inconvnient (dj vu en cours) soulve cette adaptation ? Comment y remdier dans ce cas particulier ?

Cours dalgorithmique rpartie Joyce El Haddad et Serge Haddad

28

Universit Paris-Dauphine : IUP GMI, IUP MIAGE, DESS SITN

6 Rfrences
[Bag89] R.L. Bagrodia "Synchronisation of asynchronous processes in CSP" ACM Toplas, vol 11,4 (Oct. 1989), pp. 585-597 [Boc79] G.V. Bochmann "Architecture of distributed computer" Springer-Verlag, LNCS 77 (1979) [Lam78] L. Lamport "Time, clocks, and the ordering of events in a distributed system" Communications of ACM 21 (1978), 558-564 [MS80a] P.P. Merlin P.J. Schweitzer "Deadlock avoidance in store-and forward networks I : Store and Forward deadlock" IEEE Transactions on Communcations COM-28 (1980), 345360 [TU81] S. Toueg J.D. Ullman "Deadlock-free packet switching networks" SIAM Journal of Computing 10,3 (1981), 594-611

Cours dalgorithmique rpartie Joyce El Haddad et Serge Haddad

29