L’algorithme AFCtree [EWBBB13] est basée sur l’algorithme AFC-ng, effectué sur un ordre pseudo-arbre du graphe de contraintes (construit en étape de prétrai- tement). Les agents sont hiérarchisés selon l’ordre pseudo-arbre dans lequel chaque agent a un seul parent et plusieurs enfants. En utilisant cet ordre de priorité, AFC- tree effectue multiples processus AFC-ng sur les chemins de la racine aux feuilles. La racine lance la recherche en générant un cpa portant son propre affectation et l’envoi des messages CPA à ses descendants qui partage une contraintes avec lui. Parmi tous les agents qui reçoivent le CPA, les enfants déclenchent un processus AFC-ng sur le sous-problème limité à ses ancêtres (les agents qui sont affectés dans le CPA) et l’en- semble de ses descendants. Par conséquent, au lieu de donner le privilège d’attribuer à un seul agent, les agents qui sont en sous-arbres disjoints peuvent céder leurs va- riables simultanément. Ainsi, AFCtree exploite ainsi l’accélération potentielle d’une exploration parallèle par rapport au traitement de problèmes distribués. Le degré d’asynchronisme est renforcé.
Dans AFC-ng, une solution est obtenue lorsque le dernier agent dans l’ordre reçoit le cpa et parvient à instancier sa variable. Dans AFCtree, la situation est différente, car un cpa peut atteindre un agent de feuilles sans être complète. AFCtree utilise un autre type de messages appelés ACCEPT qui informe les parents de l’acceptation de leur cpa. La terminaison peut être déduite plus tôt et le nombre de messages requis pour la détection de terminaison peut être réduit.
77 IV.3 La résolution d’un problème DisCSps
ALGORITHM 12: Algorithme AFCng (2ème partie) procedure Backtrack()
21. nogood ← solve(NogoodStore) ; 22. if (nogood = empty) then 23. sendMsg : STP() 24. else
25. AgentView.clearFrom(Rhs(nogood)) ;
26. foreach (ng ∈ NogoodStore) do
27. if (¬ Compatible(ng, AgentView) ∧ Rhs(nogood) ∈ ng) then
Remove(ng,NogoodStore);
28. vi ← empty ;
29. AgentView.consistent ← false ;
30. sendMsg : NGD(nogood) to Rhs(nogood) ; procedure CheckAssign(sender)
31. if (Predecessor(Ai) = sender) then 32. Assign()
procedure Assign() 33. if (Di Ó= ∅) then
34. vi ← ChooseValue() ; 35. ti ← ti+1 ;
36. cpa ← { AgentView ∪ (xi, vi, ti) } ; Send_CPA(cpa) 37. else
38. Backtrack() procedure Revise() 39. foreach (v ∈ D0
i) do
40. if (v is inconsistent with AgentView) then 41. store the best nogood for v
procedure UpdateAgentView(cpa) 42. AgentView ← cpa ;
43. foreach ( ng ∈ NogoodStore) do
44. if (¬ Compatible(ng, AgentView)) then
45. remove(ng, NogoodStore)
feuille réussit une affectation, elle envoie un message ACCEPT à son parent. Ce message contient le cpa qui a été reçu par le parent incrémenté par la valeur affectée à la feuille. Quand un agent non-feuille Ai reçoit les messages ACCEPT de tous
ses enfants et qui sont tous compatibles avec son AgentView et la valeur de Ai, Ai
construit un message ACCEPT étant la conjonction de tous les messages reçus plus son affectation. Si Ai est la racine, une solution est trouvée et elle est diffusé à tous
les agents. Sinon, Ai envoie le message ACCEPT construit à son parent.
Nous présentons dans l’algorithme 13 seulement les procédures qui sont diffé- rentes de celle de l’algorithme AFC-ng. Tout d’abord, Une opération de prétraite-
78 IV.3 La résolution d’un problème DisCSps
ALGORITHM 13: Algorithme AFCtree procedure start()
1. foreach (xj ∈ Ancestors(Ai)) do AgentView ← AgentView ∪ {(xj, empty, 0)}; 2. foreach (child ∈ Children(Ai)) do Accept[child] ← ∅;
3. AgentView.consistent ← true ; end ← false ; 4. if (Ai = root) then Assign();
5. while (¬ end) do 6. msg ← getMsg() ; 7. switch msg.type do 8. CPA : Process_CPA(msg) ; 9. NGD : Process_NGD(msg) ; 10. ACCEPT : Process_ACCEPT(msg) ; 11. STP : end ← true procedure ProcessACCEPT(msg)
12. if (msg.cpa is greater than Accept[msg.sender]) then 13. Accept[msg.sender] ← msg.cpa ;
14. SolutionDetection() ; procedure SendCPA(cpa) 15. if (children(Ai) Ó= ∅) then
16. foreach (Aj ∈ linkedDescendants(Ai)) do sendMsg : CPA(cpa) to Aj; 17. else SolutionDetection();
procedure CheckAssign(sender)
18. if (Parent(Ai) = sender) then Assign(); procedure SolutionDetected()
19. if (Children(Ai) = ∅) then
20. sendMsg : ACCEPT(AgentView ∪ {(xi, vi, ti)}) to Parent(Ai) ; 21. else
22. PA ← BuildPA() ;
23. if (PA Ó= ∅) then
24. if (Ai = root) then sendMsg : STP(PA);
25. else sendMsg : ACCEPT(PA) to Parent(Ai);
fonction BuildPA()
26. PA ← AgentView ∪ {(xi, vi, ti)} ; 27. foreach (Aj ∈ Children(Ai)) do
28. if (Accept[Aj] = ∅ ∨ ¬ Compatible(PA, Accept[Aj]) then return ∅; 29. else PA ← PA ∪ Accept[Aj];
30. return PA ;
ment pour convertir le graphe de contraintes en un pseudo-arbre de contraintes est lancée avant le commencement de l’algorithme AFCtree. Étant donné l’agent Ai,
nous employons les notations suivantes : Children(Ai) est l’ensemble des enfants de
l’agent Ai, Descendants(Ai) est l’ensemble de ses descendants et linkedDescendant(Ai)est
79 IV.3 La résolution d’un problème DisCSps Parent(Ai) est le parent de l’agent Ai et Ancestors(Ai) l’ensemble de ses ancêtres
(incluant son parent).
Dans la procédure AFCtree(), l’AgentView de Ai est initialisé par l’ensemble
Ancestors(Ai) et le compteur tj pour chaque agent Aj dans Ancestors(Ai) est initia-
lisé à 0 (ligne 1). La nouvelle structure de données stockant les messages ACCEPT reçus est initialisée à l’ensemble vide (ligne 2). Dans la procédure SendCPA(cpa), au lieu d’envoyer des copies de cpa à tous les agents non encore instanciées, Ai envoie ces
copies seulement à ses descendants liés (lignes 14-15). Si le linkedDescendants(Ai)
est vide (c.-à-d. , Ai est une feuille), Ai appelle la procédure SolutionDetection()
pour construire et envoyer un message ACCEPT. Dans CheckAssign(sender), Ai
attribue sa valeur si le cpa a été reçu de son parent (ligne 17) (c.-à-d. sender est le parent de Ai).
Dans ProcessAccept(msg), lorsque Ai reçoit un message ACCEPT de son enfant
pour la première fois, ou le cpa contenue dans le message ACCEPT reçu est plus récent que celui reçu avant, Ai sauvegarde le contenu de ce message et appelle la
procédure de SolutionDetection() (lignes 12-13).
Dans la procédure SolutionDetection(), si Ai est une feuille (Children(Ai) est
vide, ligne 18), il envoie un message ACCEPT à son parent. Ce message contient son AgentView incrémenté par l’affectation de Ai(lignes 19). Si Ai n’est pas une
feuille, il lance la fonction BuildAccept() pour construire une solution partielle PA (ligne 21). Si la solution partielle retourné PA n’est pas vide et Ai est la racine,
PA est une solution complète du problème et qui sera diffusée par Ai aux autres
agents, y compris l’agent système (ligne 23). Sinon, Ai envoie un message ACCEPT
contenant PA à son parent (ligne 24).
Dans la fonction BuildAccept(), si une solution partielle acceptée PA est atteinte,
Ai génère une nouvelle solution partielle en incrémentant son AgentView avec son
affectation courante (ligne 25). Ensuite, Aivérifie l’ensemble des messages ACCEPT
reçus de ses enfants. Si au moins un enfant n’a jamais envoyé un message ACCEPT ou le message ACCEPT est incompatible avec PA, alors la solution partielle n’a pas encore été atteinte et la fonction ne retourne rien (ligne 27). Sinon, la solution partielle PA est incrémentée par le message ACCEPT de l’enfant (ligne 28). Enfin, une solution partielle est retournée (ligne 29).
80 IV.4 Conclusion
4
Conclusion
Dans ce chapitre, Nous avons présenté les notions fondamentales de problèmes de satisfaction de contraintes distribués (DisCSP). Après avoir défini le formalisme de DisCSP et de présenter quelques exemples de problèmes combinatoires réels qui peuvent être modélisés sous forme de DisCSP, nous avons présenté les principaux algorithmes existants pour résoudre les problèmes de satisfaction de contraintes dis- tribués. Nous avons décrit en détails les procédures fondamentales de l’algorithme ABT, le protocole le plus étudié dans la littérature et qui se caractérise par la re- cherche asynchrone. L’algorithme ABT a connu plusieurs extensions comme ABT- uac et ABT-dac qui ne diffèrent que dans la manière dont ils maintiennent la consis- tance d’arc au cours de la recherche. Nous avons aussi détaillé l’approche AFC-ng, un mécanisme élégant pour le filtrage asynchrone durant la recherche séquentielle. Cet algorithme a conduit à une extension, l’algorithme AFCtree, qui consiste à exploiter la structure de graphe de contraintes à travers un schéma de recherche parallèle pour diminuer le temps de la résolution. C’est deux dernières approches vont nous servir dans les chapitres suivants comme des algorithmes de base pour proposer d’autres méthodes de résolution.
Chapitre
V
Maintenance Asynchrone de la consistance
d’arc
La combinaison d’une méthode de résolution avec la consistance d’arc est une des techniques les plus puissantes pour résoudre les problèmes de satisfaction de contrainte distribués (DisCSPs). Récemment, il a été démontré que la meilleure manière pour introduire plus d’asynchronisme dans la recherche distribuée est le mécanisme forward checking [ZM07]. Cependant, dans les approches centralisées [BR97, BR01], il a été montré que le maintien de la consistance d’arc lors de la recherche, surpasse le forward checking sur les réseaux de contraintes larges et durs. Dans ce chapitre, nous allons proposer un nouvel algorithme de propagation de contrainte distribué, appelé Asynchronous Maintenance of Arc Consistency (AMAC), qui est largement basé sur l’algorithme based-nogood AFC (AFC-ng) [EWBBB09, EWBBB13]. L’algorithme AMAC exploite simultanément le maintien de la consis- tance, d’une manière qui permet aux inconsistances potentielles causées par les sup- pressions de valeur d’être propagées. Les questions de mise en œuvre associées à l’algorithme sont décrites en détail et sa correction est prouvée. Les évaluations ex- périmentales effectuées sur des problèmes de benchmarks montrent l’efficacité de notre approche.
1
Introduction
L’algorithme based-nogood AFC (AFC-ng) [EWBBB09, EWBBB13] est une technique performante de résolution des problèmes de satisfaction de contraintes distribués, et qui tire profit du mécanisme de forward checking. Cependant ce mode de filtrage ne suit pas à la trace les incohérences du réseau jusqu’à ce qu’il n’y a aucune valeur inconsistante.
82 V.2 Travaux effectués [BM08], la suppression inconditionnelle, c’est quand la valeur considérée est éliminée une fois pour toutes (essentiellement dans l’étape de pré-traitement). Le deuxième type est la suppression conditionnelle, c’est lorsque une valeur est rejetée tant que l’affectation en conflits est toujours pertinente.
L’objectif principal de ce travail est de proposer un nouvel algorithme de pro- pagation de contraintes distribué pour la résolution des problèmes DisCSP s, ap- pelé Asynchronous Maintenance of Arc Consistency (AMAC), qui relie l’algorithme AFC-ng proposé dans [EWBBB09] avec la consistance d’arc. Dans notre approche, chaque agent garde le triplet : variables assignées, ses domaines et son stock des no- goods. Lors de la réception d’une nouvelle affectation ou un nogood pertinent, une meilleure explication est alors prévue pour chaque valeur supprimée. L’utilisation de NogoodStore pour stoker les affectations en conflit ayant une priorité plus éle- vée permet une meilleure approche d’apprentissage pour élaguer les sous-problèmes irréalisables. Ces suppressions sont ensuite propagées à tous les agents moins priori- taires dans la liste des conflits (nogood), produisant de nouvelles suppressions dans les domaines des autres variables, et ainsi de suite.
Ce chapitre est organisé comme suit : D’abord, nous allons rappeler les tra- vaux réalisés dans ce domaine. Ensuite, nous présentons l’idée de la propagation de contraintes dans le nouvel algorithme AMAC. Puis, nous illustrons les résul- tats expérimentaux pour cette approche sur des cas DisCSP aléatoires. Enfin, nous extrayons quelques conclusions et directions pour des recherches plus approfondies.
2
Travaux effectués
Bien que son succès pour la résolution de CSP centralisés ait été empiriquement démontré, le maintien de la consistance d’arc (MAC) n’a pas été suffisamment bien étudié dans les CSP distribués. [SSF01] a présenté l’algorithme Distributed Maintai- ning Asynchronously Consistency pour ABT, DMAC-ABT, le premier algorithme capable de maintenir la consistance d’arc dans les CSP distribués. DMAC-ABT considère la maintenance de la consistance comme une inférence hiérarchique basée sur les nogoods. Cependant, l’amélioration obtenue sur ABT était mineure.
Dans [BM08], les auteurs ont proposé ABT-uac et ABT-dac, deux algorithmes qui relient ABT avec la consistance d’arc. Le premier algorithme qu’ils proposent, ABT-uac, propage les valeurs supprimées d’une manière inconditionnelle (les va- leurs retirées par un nogood ayant un côté gauche vide) pour l’établissement de la consistance d’arc complète. L’idée intuitive derrière ABT-uac est que puisque les
83 V.3 Asynchronous Maintenance of AC valeurs supprimées inconditionnellement sont éliminées une fois pour toutes, leur propagation peut provoquer de nouvelles suppressions dans les domaines des autres variables. Ainsi, l’effort de recherche nécessaire pour résoudre le DisCSP peut être réduite. Le second algorithme qu’ils proposent, ABT-dac, étend le premier afin de propager les valeurs supprimées d’une manière conditionnelle et inconditionnelle à l’aide de la consistance d’arc directionnelle. ABT-uac montre une amélioration mi- neure en charge de la communication et ABT-dac est nocif dans de nombreux cas.
3
Asynchronous Maintenance of AC
La contribution principale de ce chapitre est la proposition d’une combinaison entre AFC-ng et la consistance d’arc, à savoir, l’algorithme Asynchronous Mainte-
nance of Arc Consistency (AMAC). La détection d’un événement de backtrack est
parmi les buts importants dans les algorithmes de recherches DisCSP, ce qui permet d’accélérer la recherche et d’élaguer les sous-problèmes irréalisable.
L’algorithme AMAC, qui maintient une consistance d’arc complète, est une grande amélioration du protocole AFC-ng. L’idée clé de cette approche est de suivre les inconsistance jusqu’à il n’y a aucune valeur incompatible dans le réseau, en en- voyant en avant le CPA. Dans l’algorithme AMAC, chaque nouvelle affectation est vérifiée d’une manière asynchrone par des variables non assignées et la consistance d’arc est alors propagée simultanément dans les deux sens selon la partie gauche du nogood résolu.
L’une des caractéristiques principales de l’algorithme AMAC est qu’il a besoin seulement d’un espace polynômial pour stocker les nogoods. Chaque agent dans AMAC garde un stock de nogood, NogoodStore, pour tous ses voisins (c.-à-d. il représente les domaines des agents en contraints). Si le nogood qui lance la propa- gation n’est plus actif, la propagation doit être défaite, mais si Lhs(Nogood) = ∅, le Nogood est toujours actif, donc les effets de propagation restent pour toujours. Pour assurer ce mécanisme, l’algorithme AMAC exige seulement un message sup- plémentaire quant à l’algorithme AFC-ng, à savoir le message DEL :
— DEL : C’est un Message qui contient la valeur retirée et son explication (nogood). L’agent Ai informe ses voisins Aj que la valeur vi a été supprimée
de di. Les agents Aj portent une priorité inférieure par rapport aux agents
dans le nogood. Lors de la réception de ce message, Aj supprime la valeur
vi de sa copie du domaine di et stocke son nogood correspondant, ensuite il
84 V.3 Asynchronous Maintenance of AC
Aj est supprimé suite de l’application de l’AC, ceci sera propagée de la même
manière.
L’algorithme AMAC est largement basé sur l’algorithme AFC-ng. Chaque agent envoie le CPA aux agents suivants dont les affectations ne sont pas encore incluses dans le CPA. Les agents qui reçoivent le CPA se comportent comme dans l’algo- rithme AFC-ng, mettent à jour leurs domaines en supprimant toutes les valeurs incompatibles avec le CPA, ensuite envoient un message DEL afin de renforcer la consistance d’arc avec les agents en contraints. La propagation de contraintes per- met aux agents de détecter l’affectation partielle incohérente pour lancer le back- track le plus tôt possible. Un agent qui produit un dead-end initialise un backtrack en envoyant un message BACK aux agents concernés. Afin d’introduire la fonction
revise − 2001 dans l’agent d’AMAC, il est important de noter que nous devons
inclure quelques changements mineurs par rapport à l’algorithme AFC-ng. Nous as- sumons que l’agent Ai connaît à priori ses voisins, le domaine de chaque variable
contrainte avec Ai est aussi représenté dans Ai, ainsi le calcul de domaine peut
être fait en projetant les contraintes des variables en liaison. Ces contraintes seront arc-consistant après le pré-traitement .
3.1
Description de l’algorithme
Regardons maintenant ce qui se passe dans un agent AMAC (figure 14 et 15). Tout d’abord, avant de commencer l’affectation par l’agent initializer, chaque agent initialise la consistance d’arc avec ses voisins à travers la fonction initP ropagation() (ligne 1), la propagation de contraintes est alors appliquée continuellement, même pendant la phase de recherche. Si cet examen initial génère un dead-end, par la fonction propagateAC(), l’agent envoie un message d’arrêt à travers la réseau (ligne 46). Si la valeur de Ai est supprimé dans ce processus, la procédure assign() est
appelée pour la recherche d’une nouvelle valeur compatible, si aucun n’existe, un backtrack est exécuté (lignes 49-50). Puis l’agent envoie un nogood dans le mes- sage DEL à tout agent moins prioritaire à la dernière variable dans Lhs du nogood
LastAg(Lhs(nogood)) (lignes 51-52).
Le CPA dans AMAC est envoyé en avant comme dans AFC-ng, quand un agent
Ai reçoit le CPA, au lieu d’appeler la procédure F ilterInitialDomain(), il appelle
la procédure filterPropagate() (ligne 16), par conséquent Ai révise son domaine
initial. La Révisions du domaine initial permet aux agents de stocker pour chaque valeur enlevée le meilleur nogood en utilisant l’heuristique HPLV (lignes 40-41). Les messages DEL sont alors envoyés pour chaque valeur enlevée avec le nogood rendue
85 V.3 Asynchronous Maintenance of AC
ALGORITHM 14: Algorithme AMAC (Part 1) procedure start()
1. initPropagation() ;
2. muAgentView ← {(Aj, ∅, 0)| Aj ≺ Ai} ; 3. myAgentView.consistent ← true ; end ← false ; 4. if (Ai = IA) then Assign();
5. while (¬ end) do 6. msg ← getMsg() ;
7. switch (msg.type) do
8. CPA : ProcessCPA(msg.cpa, msg.next) ; 9. BACK : ProcessBACK(msg.cpa, msg.nogood) ; 10. DEL : ProcessDEL(msg.nogood, msg.sender) ; 11. STP : end ← true ;
procedure ProcessCPA(cpa, next)
12. if (¬ myAgentView.consistent & myAgentView ⊂ cpa) then return; 13. level ← CompareTimeStamp(cpa) ;
14. if (level > 0) then
15. UpdateMyAgentView(cpa, level) ; myAgentView.consistent ← true ; 16. FilterPropagate()
17. if (myDomain = ∅) then Bachtrack(); 18. else if (Ai = next) then Assign();
procedure ProcessBACK(cpa, nogood, Aj)
19. if (Lhs(nogood) = ∅) then DeleteValue(getRhsValue(nogood), BACK.sender); 20. if (getRhsValue(nogood) = myValue) then Assign();
21. else
22. if (¬ myAgentView.consistent & myAgentView ⊂ cpa) then return; 23. level ← compareTimeStamp(cpa) ;
24. if (level = 0 & myValue = getRhsValue(nogood)) then 25. myValue ← empty ; add(nogood, NogoodStore[Ai]) ;
26. SendMsg : DEL(nogood, Ai) to agents ≻ LastAg(Lhs(nogood)) except Aj; 27. Assign()
procedure ProcessDEL(nogood, Aj)
28. if (Lhs(Nogood) ⊂ myAgentView) then
29. if (Rhs(Nogood) ⊂ myAgentView) then
30. foreach (Ai ∈ myAgentView & Ai ≻ getRhsVar(Nogood)) do
31. myAgentView[i] ← null ; UpdateNogoodStore() ; 32. myAgentView.consistent ← false ;
33. return
34. if (Lhs(nogood) = ∅) then Domains[j] ← Domains[j] - getRhsValue(nogood); 35. else add(nogood, nogoodStore[j]);
36. propagateAC(Ai, Aj)
par la fonction nogoodOf(v) (lignes 43-44).
86 V.3 Asynchronous Maintenance of AC compatible est retirée inconditionnellement si la partie gauche du nogood est vide (ligne 19), ou conditionnellement quand un nogood avec un Lhs non-vide est accepté (ligne 25). Afin de renforcer la consistance d’arc, lorsque un message DEL est reçu, le Nogood est accepté s’il est cohérent avec l’AgentView de l’agent Ai (ligne 28),
sinon, le message est considéré comme obsolète.
ALGORITHM 15: Algorithme AMAC (Part 2) procedure initPropagation()
37. myneighbours ← getNeighbours() ;
38. foreach (Aj ∈ myneighbours do PropagateAC(Ai, Aj); procedure FilterPropagate()
39. foreach (v ∈ Ai.InitialDomain) do
40. if (¬ Consistent(v,myAgentView)) then
41. store the best nogood for v in nogoodStore[Ai] 42. del ← the newest removed values ;
43. foreach (v ∈ del) do
44. SendMsg : DEL(NogoodOf(v), Ai) to agents ≻ LastAg(Lhs(NogoodOf(v))) procedure PropagateAC(Ai, Aj)
45. if (Revise2001(Ai, Aj)) then
46. if (myDomains is empty unconditionly) then BroadcastMsg : STP(); 47. else
48. del ← the newest removed values in Domain[Ai] by revise-2001 ;
49. if (myValue Ó= empty ∧ myValue /∈ myDomain) then
50. myValue ← empty ; Assign()
51. foreach (v ∈ del) do
52. SendMsg : DEL (nogoodOf(v), Ai) to Aj ≻ LastAg(Lhs(nogoodOf(v)))
except Aj
procedure DeleteValue(v, Aj)
53. myDomains ← myDomains - {v} ;
54. if (myDomains is empty unconditionly) then 55. BroadcastMsg : STP()
56. else
57. SendMsg : DEL(NogoodOf(v), Ai) to Ak ≻ LastAg(Lhs(NogoodOf(v))) except Aj
Ensuite, l’agent Ai vérifie si l’affectation coupable Rhs(Nogood) est un sous-
ensemble de l’AgentView (ligne 29), cela signifie que Rhs(Nogood) a déjà ou fera sans doute un backtrack, donc, Aimet à jour son AgentView, met son drapeau à faux
(lignes 30-33) et ne fait rien. Si Lhs(Nogood) est vide (ligne 34), la valeur correspon- dante est supprimée inconditionnellement de domains[j], sinon, le Lhs(Nogood) est ajouté au NogoodStore (ligne 35). la consistance d’arc est appliquée par la procédure
propagateAC(), qui est basée essentiellement sur revise-2001 [BR01].
87 V.4 Preuve de correction initialement compatibles avec v dans le domaine d’une variable contrainte, un mes- sage DEL est envoyé à tous les agents moins prioritaires que le dernier agent dans le Lhs de nogoods produit, sauf l’agent qui envoie le DEL.
La procédure DeleteV alue() a le rôle d’enlever inconditionnellement la valeur
v et propager cette suppression via le message DEL aux autres agents contraints
(lignes 56-57). Si le domaine de Ai est vide inconditionnellement (ligne 54), un
message d’arrêt est alors émis pour informer tous les agents que le problème n’a aucune solution
FilterPropagate() a pour tâche de filtrer le domaine de Ai et stocker les meilleurs
nogoods pour chaque valeur récemment enlevée. De la même façon, un message DEL est envoyé à tous les agents moins prioritaires que le dernier agent dans le Lhs du nogoods produit (lignes 43-44).
Comme dans le protocole AFC-ng, un agent utilise la procédure Assign() si le CPA était le plus récent reçu par le message CPA_MSG ou BAKC_MSG. Si l’agent peut instancier sa variable en respectant les contraintes, une solution est trouvée si Ai A la priorité la plus basse, sinon, l’agent incrémente son compteur et
envoie ensuite le CPA à l’agent suivant et une copie aux agents non encore instan- ciés. Autrement, l’agent change le contenu de son AgentView mettant en évidence l’affectation partielle inconsistante la plus courte et commencer ensuite le processus du backtrack.
4
Preuve de correction
Dans cette section, nous nous concentrons à prouver la correction de l’algorithme AMAC. Il est évident qu’on peut établir immédiatement la correction d’AMAC à partir de l’algorithme AFC-ng. Cette correction inclut la sûreté, la complétude et la terminaison.
Theorem 4.1 AMAC est sûr, complet et se termine.
Les agents dans AMAC envoient en avant seulement des instantiations partielles cohérentes et l’extension de CPA reste le même comme dans AFC-ng, donc le lemma