350 likes | 498 Vues
This document provides an in-depth overview of self-stabilization, a critical concept in distributed systems introduced by Dijkstra in 1974. It discusses the definitions, advantages, and drawbacks of self-stabilization, comparing it with pseudo-stabilization. Key examples include Dijkstra’s Token Ring and leader election protocols. The text also explores advanced properties like fault tolerance and communication efficiency. The implications for resource allocation, broadcasting, and routing protocols are examined, emphasizing the significance of self-stabilization in achieving system reliability and efficiency.
E N D
Introduction to Self-Stabilization StéphaneDevismes
Self-Stabilization [Dijkstra, 1974] • Example: Dijkstra’s Token Ring 0 1 2 1 0 1 0 1 0 0 1
Starting from an arbitrary state 5 4 0 2 5 1 0 4 0 5 5
Definition: Closure + Convergence Closure Illegitimate states Legitimate States Convergence States of the system
Why Self-Stabilization? Advantages Drawbacks
Protocols for: • Resources Allocation (Mutual Exclusion) • Broadcast • Routing • Overlay (Spanning trees, Routing table) • …
Around Self-Stabilization (1/2) • Weaker Properties: • K-Stabilization (no more than K faults) • Weak-Stabilization (possible convergence) • Probabilistic Stabilization (probabilistic convergence) • Pseudo-Stabilization • Aim: circumvent impossibility results • Example: alternated bit protocol
Pseudo-Stabilization ? • Self-Stabilization [Dijkstra, 1974]: Starting from any configuration, a self-stabilizing system reaches in a finite time a configuration c such that any suffix starting from c satisfies the intended specification. • Pseudo-Stabilization [Burns, Gouda, and Miller, 1993]: Starting from any configuration, any execution of a pseudo-stabilizing system has a non-empty suffix that satisfies the intended specification.
Self- vs. Pseudo- Stabilization Strong Closure vs. Ultimate Closure Illegitimate States Legitimate States
Self- vs. Pseudo- Stabilization • Example: Leader Election • Self-Stabilizing Leader Election: • Eventually there is a unique leader that cannot change • Pseudo-Stabilizing Leader Election: • We never have the guarantee that the leader no more changes but eventually it no more change • Remark: no stabilization time in pseudo-stabilization
Around Self-Stabilization (2/2) • Stronger Properties: • Fault-containment (Quick stabilization when there are few faults) • Snap-Stabilization (Safety for the tasks started after the faults) • Byzantine-Tolerant Stabilization • Fault-Tolerant Stabilization(Stabilization despite crashes) • Aim: circumvent the drawbacks
LIAFA Fault-Tolerant Stabilizing Leader Election CaroleDelporte-Gallet(LIAFA) StéphaneDevismes(CNRS, LRI) HuguesFauconnier(LIAFA)
Fault-Tolerant Stabilization • Gopal and Perry, PODC’93 • Beauquier and Kekkonen-Moneta, JSS’97 • Anagnostou and Hadzilacos, WDAG’93 In partial synchronous model ?
Leader Election Fault-Tolerant Stabilizing Leader Election with: weak reliability and synchrony assumptions
Model • Network: fully-connected • n Processes: • timely • may crash (an arbitrary number of processes may crash) • Variables: initially arbitrary assigned • Links: • Unidirectional • Initially not necessarily empty • No order on the message deliverance • Variable reliability and timeliness assumptions
Communication-Efficiency [Larrea, Fernandez, and Arevalo, 2000]: « An algorithm is communication-efficient if it eventually only uses n - 1 unidirectional links »
Self-Stabilizing Leader Electionin a full timely network? Yes + communication-efficiency
Principles of the algorithm • A process p periodically sends ALIVE to every other if Leader = p Alive,1 1 4 Leader=1 Alive,1 Alive,1 Alive,2 Alive,2 3 2 Leader=2 Leader=2 Alive,2
1 4 3 2 Principles of the algorithm • When a process p such that Leader = p receives ALIVE from q, then • Leader := qif q < p Alive,1 Leader=1 4 Alive,1 Alive,1 Alive,2 Alive,2 Leader=2 Leader=2 Leader=1 Alive,2
1 4 3 2 Principles of the algorithm • Any process q such that Leader ≠ q always chooses as leader the process from which it receives ALIVEthe most recently Alive,1 Leader=1 4 Alive,1 Alive,1 Leader=2 Leader=1 Leader=1
1 4 3 2 Principles of the algorithm • On Time out, a process p sets Leader to p Alive,1 Leader=3 Leader=1 4 Alive,1 Alive,1 Alive,2 Alive,2 Leader=2 Leader=4 Leader=2 Alive,2
Communication-EfficientSelf-StabilizingLeader Electionin a system where at most one link is asynchronous? No
Impossibility of Communication-Efficiency in a system with at most one asynchronous link • Claim: Any process p such that Leader ≠ p must periodically receive messages within a bounded time otherwise it chooses another leader The process chooses another leader
Self-Stabilizing (non communication-efficient)Leader Electionin a system where some links are asynchronous? Yes
Self-Stabilizing Leader Election in a system with a timely routing overlay • For each pair of alive processes (p,q), there exists at least two paths of timely links: • From p to q • From q to p
Principle of the algorithm • Each process computes the set of alive processes and chooses as leader the smallest process of this set • To compute the set: • Each process pperiodically sends ALIVE,p to every other process • Any ALIVE,p message is repeated n- 1 times (any other process periodically receives such a message)
Self-Stabilizing Leader Electionin a system without timely routing overlay ? No
Pseudo-Stabilizing Leader Electionin a system where Self-Stabilizing Leader Election is not possible ? • Yes + communication-efficiently • In a system having a source and fair links
Source 1 2 Algorithm for systems with Source + fair links • A process pperiodically sends ALIVE to every other if Leader = p • Each process stores in Active itsID+ the IDs of each process from which it recently receives ALIVE • Each process chooses its leader among the processes in its Active set • Problem: we cannot use the IDs to choose a leader Alive,1 <1,2> <1> <1,2> <2> Alive,2
Source 3 1 2 Accusation Counter • p stores in Counter[p] how many times it was suspected to be crashed • When a process suspects its leader: • it sends an ACCUSATION to LEADER, and • chooses as new leader the process in Active with the smallest accusation counter • p periodically sends ALIVE,Counter[p] to every other if Leader = p • Problem: the accusation counter of the source can increase infinitely often 2 <3> 3 <1,3> 3,C=2 3,C=2 Accuse 1,C=1 4 <2> <2,3> 1 <1,3> 1,C=1
Source 3 1 2 Phase Counter • Each process maintains in Phase[p] the number of times it looses the leadership • pperiodically sends ALIVE,Counter[p],Phase[p] to every other if Leader = p • p increments Counter[p] only when receiving ACCUSATION,ph with ph = Phase[p] 2 <1,3> <3> Ph=4 (previously 3) Ph=3 3,C=2 3,C=2 1,C=1 Accuse,3 1 <1,3> 4 <2,3> Ph=1 <2> Ph=2 1,C=1
Communication-Efficient Pseudo-Stabilizing Leader Electionin a system having only a source? No, but a non communication-efficient pseudo-stabilizing leader election can be done
Perspectives • Communication-efficient FTPS leader election in a system with timely routing overlay • Extend these results to other topologies and models • Fault-tolerant stabilizing decision problems ?