Communication Optimalement Stabilisante sur Canaux non Fiables et non FIFO
Shlomi Dolev, Swan Dubois, Maria Potop-Butucaru, Sébastien Tixeuil
aa r X i v : . [ c s . D C ] A p r Communication Optimalement Stabilisante surCanaux non Fiables et non FIFO
Shlomi Dolev , Swan Dubois , Maria Potop-Butucaru et S´ebastien Tixeuil Universit´e de Ben-Gurion (Isra¨el), [email protected] UPMC Sorbonne Universit´es & INRIA (France), { swan.dubois,maria.potop-butucaru } @lip6.fr UPMC Sorbonne Universit´es & IUF (France), [email protected]
Un protocole auto-stabilisant a la capacit´e de converger vers un comportement correct quel que soit son ´etat initial. Lagrande majorit´e des travaux en auto-stabilisation supposent une communication par m´emoire partag´ee ou bien `a traversdes canaux de communication fiables et FIFO. Dans cet article, nous nous int´eressons aux syst`emes auto-stabilisants `apassage de messages `a travers des canaux de capacit´e born´ee mais non fiables et non FIFO. Nous proposons un protocolede communication (entre voisins) stabilisant et offrant une tol´erance optimale. Plus pr´ecis`ement, ce protocole simuleun canal de communication fiable et FIFO garantissant un nombre minimal de pertes, de duplications, de cr´eations etde r´e-ordonnancements de messages.
Keywords:
Canaux non fiables, canaux non FIFO, auto-stabilisation L’ auto-stabilisation [Dij74] est une propri´et´e des syst`emes distribu´es permettant de tol´erer des fautestransitoires ( i.e. de dur´ee finie) de type arbitraire. Plus pr´ecis`ement, un syst`eme est dit auto-stabilisant s’ilgarantit que toute ex´ecution issue d’une configuration arbitraire retrouve en un temps fini un comportementconforme `a la sp´ecification du syst`eme et ceci sans aide ext´erieure (humaine ou autre). Motivations ´Etant donn´e que l’auto-stabilisation est une propri´et´e non triviale `a satisfaire, une large partdes travaux traitant de ce domaine se placent dans un mod`ele de communication tr`es simple dans lequel tousles processeurs peuvent d´eterminer de mani`ere atomique l’´etat de tous leurs voisins (ce mod`ele de calculest connu sous le nom de mod`ele `a ´etats). Il est cependant ´evident que ce mod`ele n’est pas r´ealiste et qu’unmod`ele plus classique comme le mod`ele asynchrone `a passage de messages est plus proche d’un syst`emer´eel. Dans un tel mod`ele, les processeurs voisins communiquent par envoi et r´eception de messages `a traversle canal de communication qui les s´epare. Il existe des transformateurs permettant de passer de mani`ereautomatique du premier mod`ele au second [Dol00, DIM93] ainsi que des algorithmes ´ecrits directementpour le mod`ele `a passage de messages [DT06, BKM97] mais ceux-ci supposent l’existence d’un protocolede communication entre processeurs voisins. Le protocole de communication (entre voisins) le plus connuest le protocole du bit altern´e (PBA). Il a ´et´e prouv´e que ce protocole fournit des propri´et´es de stabilisation[AB93, DIM93]. En effet, pour toute ex´ecution du PBA, il existe un suffixe qui satisfait la sp´ecification( i.e. le PBA est pseudo-stabilisant [BGM93]). Apr`es les r´esultats de [GM91, DIM93] qui montrent qu’ilest impossible de fournir un protocole de communication avec une m´emoire born´ee si les canaux sont decapacit´e non born´ee, les travaux r´ecents se sont concentr´es sur des syst`emes avec des canaux de capacit´eborn´ee. Il existe diff´erents protocoles de communication stabilisants `a travers des canaux de capacit´e born´eequi diff´erent par les hypoth`eses faites sur le syst`eme (m´emoire born´ee, canaux, etc.) mais toutes les solutionsconnues [BGM93, HNM99, Var00] consid`erent des canaux FIFO.Un d´efaut commun `a tous les protocoles de communication pr´ec´edents est qu’ils ne fournissent aucunemesure de l’impact quantitatif des fautes transitoires sur les messages transmis. Partant d’une configurationinitiale arbitraire, le contenu initial des canaux est lui aussi arbitraire, ce qui peut conduire le protocole `aperdre, dupliquer des messages ou bien d´elivrer de faux messages (qui n’ont pas ´et´e envoy´es mais r´esultentdes fautes initiales). Du point de vue de l’application qui utilise le protocole de communication, il est hlomi Dolev, Swan Dubois, Maria Potop-Butucaru et S´ebastien Tixeuil primordial de connaˆıtre des bornes sur le nombre de messages pouvant subir de tels al´eas. `A notre connais-sance, seuls [DDNT10, DT06] traitent de ce probl`eme dans une certaine mesure. En effet, ils peuventˆetre adapt´es pour obtenir des protocoles de communication instantan´enement stabilisants. La stabilisationinstantan´ee assure que tout message envoy´e sera d´elivr´e en un temps fini, mais le nombre de messagesdupliqu´es ou de faux messages cr´ees n’est pas ´etudi´e.
Contributions
Notre contribution dans cet article est double. Dans un premier temps, nous d´efinissons unensemble de m´etriques pour mesurer la performance d’un protocole de communication stabilisant et nousdonnons des bornes inf´erieures pour plusieurs d’entre elles. En particulier, nous montrons que tout protocolede communication stabilisant `a travers des canaux de capacit´e born´ee non fiables et non FIFO peut ˆetrecontraint `a dupliquer un message, `a d´elivrer un faux message ou `a r´e-ordonner un message. Dans un secondtemps, nous proposons un protocole optimal par rapport aux bornes inf´erieures ´evoqu´ees pr´ec`edement.
Sp´ecification
Nous consid´erons ici un syst`eme distribu´e `a passage de messages r´eduit `a deux processeurs : p i qui sera consid´er´e comme ´emetteur de messages et p j qui sera consid´er´e comme r´ecepteur de messages.Le canal de communication s´eparant p i et p j est constitu´e de deux canaux virtuels de directions oppos´ees.Le premier, ( i , j ) , permet `a p i d’envoyer des messages `a p j tandis que le second, ( j , i ) , permet `a p j d’envoyerdes acquittements `a p i . Chacun de ces canaux virtuels est asynchrone (le temps de livraison de tout messageest fini mais non born´e), a une capacit´e born´ee de c messages (tout envoi de messages lorsque cette borneest atteinte conduit `a la perte d’un message arbitraire), non fiable (tout message peut ˆetre perdu `a un momentarbitraire) mais ´equitable (tout message envoy´e infiniment souvent est rec¸u infiniment souvent) et non-FIFO(l’ordre d’arriv´ee des messages est ind´ependant de l’ordre d’envoi). Il faut noter que, en raison du contexteauto-stabilisant, chaque canal virtuel contient initialement jusqu’`a c messages de contenu arbitraire.La sp´ecification que nous pr´esentons `a pr´esent est inspir´ee de celle de [Lyn96] mais elle est adapt´ee aucontexte auto-stabilisant. Supposons que nous avons une application distribu´ee qui souhaite envoyer desmessages de p i `a p j . Notre objectif est de fournir un protocole de communication `a cette application quiremplit cette tˆache de mani`ere transparente malgr´e les caract´eristiques du canal de communication. Cetteapplication envoit un message lorsqu’elle demande au protocole de communication de faire parvenir unmessage depuis p i vers p j . Un message est d´elivr´e `a p j lorsque le protocole de communication fournit cemessage `a l’application s’ex´ecutant sur p j . Un message fantˆome est un message d´elivr´e `a p j alors qu’il n’apas ´et´e envoy´e par p i . Un message dupliqu´e est un message d´elivr´e plusieurs fois `a p j alors qu’il n’a ´et´eenvoy´e qu’une fois par p i . Un message perdu est un message envoy´e par p i mais jamais d´elivr´e `a p j . Unmessage m est r´e-ordonn´e lorsqu’il d´elivr´e `a p j avant un message m ′ alors que m a ´et´e envoy´e apr`es m ′ par p i . Le but d’un protocole de communication stabilisant est alors de fournir des propri´et´es sur le nombre demessages perdus, dupliqu´es, fantˆomes et r´e-ordonn´es. Nous sp´ecifions notre probl`eme comme suit : D´efinition 1
Un protocole de communication est ( a , b , g , d ) -stabilisant sur des canaux c-born´es s’il remplitles conditions suivantes pour toute ex´ecution issue d’une configuration arbitraire :- Dans le pire cas, seuls les a premiers messages envoy´es par p i peuvent ˆetre perdus.- Dans le pire cas, seuls les b premiers messages d´elivr´es `a p j peuvent ˆetre des messages dupliqu´es.- Dans le pire cas, seuls les g premiers messages d´elivr´es `a p j peuvent ˆetre des messages fantˆomes.- Dans le pire cas, seuls les d premiers messages d´elivr´es `a p j peuvent ˆetre des messages r´e-ordonn´es. ´Etant donn´e que tout protocole de communication doit avoir dans son code une instruction pour d´elivrerles messages `a l’application et que, dans un contexte auto-stabilisant, le compteur ordinal peut ˆetre arbitrai-rement corrompu dans la configuration initiale, il est possible que la premi`ere instruction execut´ee par leprocesseur r´ecepteur soit la livraison d’un message qui n’a jamais ´et´e envoy´e, i.e. un message fantˆome. Si,de plus, ce message fantˆome est identique `a un autre message envoy´e par p i dans l’ex´ecution consid´er´ee, cemessage peut devenir un message dupliqu´e ou r´e-ordonn´e. Nous obtenons les r´esultats suivants. Th´eor`eme 1
Il n’existe pas de protocole de communication ( a , b , g , d ) -stabilisant sur des canaux c-born´esavec b = , g = ou d = .ommunication Optimalement Stabilisante sur Canaux non Fiables et non FIFO ( , , , ) -stabilisant Nous sommes maintenant en mesure de pr´esenter notre protocole de communication. Celui-ci est com-pos´e de deux fonctions :
Send( m ) qui est ex´ecut´ee par p i `a chaque fois qu’il souhaite envoyer un message m ( Send est bloquant, i.e. p i doit attendre la fin de son ex´ecution avant de commencer `a envoyer le messagesuivant) et Receive() qui est ex´ecut´ee par p j en continu. Id´ee g´en´erale
L’id´ee de base de notre protocole est de modifier le PBA de mani`ere `a am´eliorer ses pro-pri´et´es de tol´erance. Si le processeur p i souhaite envoyer un message m , il envoie celui-ci de mani`erep´eriodique et p j acquitte chaque copie de m qu’il rec¸oit. Le processeur p j n’est autoris´e `a d´elivrer le mes-sage m que lorsqu’il en a rec¸u c + p i ). De plus, m n’est d´elivr´e que si la valeur du bit altern´e qui lui est associ´ee est diff´erente de celle dudernier message d´elivr´e par p j (de mani`ere `a assurer que le message ne soit pas dupliqu´e car p i continued’envoyer m tant qu’il n’a pas rec¸u suffisament d’acquittements). Afin d’assurer que p j a rec¸u au moins c + p i attend d’avoir rec¸u 3 c + m (en effet,au plus c + c sont dˆus `a la pr´esenceinitiale de messages erronn´es dans le canal ( i , j ) ). `A ce stade, notre protocole ne garantit pas encore l’ab-sence de pertes de messages `a cause de l’utilisation du bit altern´e (en effet, si le bit altern´e du messageet du r´ecepteur ne sont pas initialement synchronis´es, le premier message envoy´e par p i peut ˆetre perdu).Pour ´eviter cela, p i alterne entre l’envoi de messages de synchronisation et de m . Plus pr´ecis`ement, pourenvoyer un message m , p i commence par envoyer un message de synchronisation (not´e < SY NCHRO > )jusqu’`a recevoir 3 c + m lui-mˆeme jusqu’`a en recevoir 3 c + Pr´esentation d´etaill´ee
Notre protocole est pr´esent´e en Figure 1. La proc´edure
Send se contente d’en-voyer un message de synchronisation puis le message rec¸u en param`etre (`a l’aide de la fonction auxilliaire
SendMessage ) apr`es avoir altern´e la valeur du bit associ´e. Finalement, elle d´elivre un acquittement `a l’ap-plication `a l’aide de la fonction
DeliverAck . La fonction auxilliaire
SendMessage envoit p´eriodiquementle message `a l’aide de la fonction
SendPacket (qui permet d’envoyer un paquet sur le canal ( i , j ) ) et comptele nombre d’acquittement rec¸us en faisant appel `a la fonction ReceivePacket (qui permet de r´ecup´erer unmessage dans le canal ( j , i ) ). Celle-ci s’arrˆete lorsqu’elle a compt´e 3 c + Sendentr´ee : m : message `a envoyer variable : ab : bool´een donnant la valeur du bit altern´e actuelle01 : ab : = ¬ ab
02 :
SendMessage ( < SYNCHRO >, ab )
03 : ab : = ¬ ab
04 :
SendMessage ( m , ab )
05 :
DeliverAck ( m ) SendMessageentr´ee : m ′ : message `a envoyer ab : bool´een donnant la valeur du bit altern´e associ´e `a m variable : ack : entier donnant le nombre d’acquittements rec¸u pourla valeur actuelle de ab
01 : ack : =
002 : while ack < c +
203 :
SendPacket ( m ′ , ab )
04 : if ReceivePacket ( ack , ( m ′ , ab ))
05 : ack : = ack + Receivevariables : last delivered : bool´een donnant la valeur du bit altern´e dudernier message d´elivr´e Q : file de taille c + ( m , ab , count ) , o`u m est un message, ab est une valeur du bit altern´e, et count est un entier donnant lenombre de paquets ( m , ab ) rec¸us pour m et ab depuis le dernier DeliverMessage ou DropMessage . L’op´erateur [] renvoit unpointeur sur le count associ´e `a son param`etre et place ce 3-tupleen tˆete de liste01 : upon ReceivePacket ( m , ab )
02 : Q [ m , ab ] : = min ( Q [ m , ab ]+ , c + )
03 : if Q [ m , ab ] ≥ c + then
04 : if last delivered = ab then
05 : if m = < SY NCHRO > then
06 :
DeliverMessage ( m )07 : else
08 :
DropMessage ( m )09 : last delivered : = ab
10 : Q : = ⊥
11 :
SendPacket ( ack , ( m , ab )) F IGURE S DL , un protocole de communication ( , , , ) -stabilisant. `A chaque r´eception de message (r´ealis´ee grˆace `a la fonction ReceivePacket ), la proc´edure
Receive incr´emente le compteur associ´e au message qu’elle vient de recevoir. Dans le cas o`u le message a ´et´erec¸u c + c + hlomi Dolev, Swan Dubois, Maria Potop-Butucaru et S´ebastien Tixeuil cation `a l’aide de DeliverMessage (s’il s’agit d’un message normal) ou bien d´etruit `a l’aide de la fonction
DropMessage (s’il s’agit d’un message de synchronisation qui est donc sans int´erˆet pour l’application).Dans les deux cas, le bit du r´ecepteur est altern´e. Tout message rec¸u est acquitt´e (`a l’aide de la fonction
SendPacket ) avant de traiter le suivant.
Propri´et´es
Nous avons vu pr´ec´edement que p i attend de recevoir 3 c + p j a rec¸u au moins 2 c + c + p i ) et donc que ce message a bien ´et´e d´elivr´e `a p j si ab = last delivered . Sice n’est pas le cas, l’usage du message de synchronisation nous garantit que notre protocole ne perd aucunmessage envoy´e par p i . L’usage du bit altern´e nous garantit l’absence de duplication apr`es la premi`erer´eception (si le premier message rec¸u est un message fantˆome, celui-ci peut ˆetre la copie d’un messagevalide ult´erieur, ce qui cause au pire une duplication). Le fait d’attendre de recevoir c + m soit d´elivr´e `a p j entre le d´ebut et la fin de l’ex´ecution de Send(m) par p i etque les appels `a cette fonction soient bloquants pour p i implique que seul le premier message peut ˆetre r´e-ordonn´e (si le premier message rec¸u est un message fantˆome, celui-ci peut ˆetre la copie d’un message valideult´erieur, ce qui cause au pire un r´e-ordonnancement). En conclusion, nous avons le r´esultat suivant † : Th´eor`eme 2
S DL est un protocole de communication ( , , , ) -stabilisant `a travers des canaux de com-munication de capacit´e born´ee mais non fiables et non FIFO. Dans cet article, nous avons introduit des mesures de l’effet de fautes transitoires sur les performancesdes protocoles de communication entre voisins dans un syst`eme `a passage de messages. Nous avons ensuitefourni un protocole optimal par rapport `a ces mesures dans le cas o`u les canaux de communications ont unecapacit´e born´ee, sont non fiables et non FIFO. Toutefois, notre protocole induit un surcoˆut de communica-tion ; la question de savoir s’il est possible de conserver cette tol´erance optimale aux fautes transitoires enbaissant ce surcoˆut de communication de mani`ere significative est toujours ouverte.
R ´ef ´erences [AB93] Y. Afek and G. Brown. Self-stabilization over unreliable communication media.
Dist. Comp. , 7(1) :27–34,1993.[BGM93] J. Burns, M. Gouda, and R. Miller. Stabilization and pseudo-stabilization.
Dist. Comp. , 7(1) :35–42,1993.[BKM97] J. Beauquier and S. Kekkonen-Moneta. Fault-tolerance and self stabilization : impossibility results andsolutions using self-stabilizing failure detectors.
Int. J. Systems Science , 28(11) :1177–1187, 1997.[DDNT10] S. Dela¨et, S. Devismes, M. Nesterenko, and S. Tixeuil. Snap-stabilization in message-passing systems.
Journal of Parallel and Distributed Computing , 2010.[DDPBT10] Shlomi Dolev, Swan Dubois, Maria Potop-Butucaru, and S´ebastien Tixeuil. Stabilizing data-link overnon-fifo channels with optimal fault-resilience.
CoRR , abs/1011.3632, 2010.[Dij74] E. Dijkstra. Self-stabilizing systems in spite of distributed control.
Comm. ACM , 17(11) :643–644, 1974.[DIM93] S. Dolev, A. Israeli, and S. Moran. Self-stabilization of dynamic systems assuming only read/write ato-micity.
Distributed Computing , 7(1) :3–16, 1993.[Dol00] S. Dolev.
Self-stabilization . MIT Press, 2000.[DT06] S. Dolev and N. Tzachar. Empire of colonies : Self-stabilizing and self-organizing distributed algorithms.In
OPODIS , pages 230–243, 2006.[GM91] M. Gouda and N. Multari. Stabilizing communication protocols.
Trans. Comput. , 40(4) :448–458, 1991.[HNM99] R. Howell, M. Nesterenko, and M. Mizuno. Finite-state self-stabilizing protocols in message-passingsystems. In
WSS , pages 62–69, 1999.[Lyn96] N. Lynch.
Distributed Algorithms . Morgan Kaufmann Publishers Inc., 1996.[Var00] G. Varghese. Self-stabilization by counter flushing.
SIAM J. Comput. , 30(2) :486–510, 2000., 30(2) :486–510, 2000.