Leader Election

Download Report

Transcript Leader Election

Leader Election
Ch. 3, 4.1, 15.1, 15.2
Chien-Liang Fok
7/17/2015
CS 673 Fall 2003
1
Leader Election
process
connection



Numerous processes are connected in a digraph
One process eventually declares itself leader
Motivation:
 token
ring networks
 efficient communication (e.g., lighthouse routing)
7/17/2015
CS 673 Fall 2003
2
Impossibility Result for Identical
processes

Cannot solve leader election problem with
identical processes
 Proof
by induction on the sequence of states
 Every process will declare self as leader
simultaneously

Solution: Assume identical processes
distinguished by a unique identifier (UID)
 UID
7/17/2015
is a positive integer
CS 673 Fall 2003
3
Synchronous Network
All processing done in lock-step formation
 There are rounds of computation
 Message-passing is done between rounds

7/17/2015
CS 673 Fall 2003
4
Model 1: Synchronous Ring
1
5
2
4
3
n processes connected in a ring
 Processes can distinguish clockwise from
counterclockwise neighbor

7/17/2015
CS 673 Fall 2003
5
Variations on the Theme
Non-leaders may have to declare
themselves as such
 Ring may be unidirectional or bidirectional
 Each node may or may not know n, the
size of the ring

7/17/2015
CS 673 Fall 2003
6
1
LCR Algorithm
5



Developed by Le Lann, Chang,
and Roberts (1978)
Unknown n, unidirectional ring,
only leader outputs
General idea:
2
4
3
 Every
process passes its UID around the ring
 Upon reception, compare to own UID



7/17/2015
If larger: Pass to next process
If smaller: Discard
If equal: Declare self as leader
CS 673 Fall 2003
7
LCR Algorithm Proof
1
5
2
4


3
r
UIDmax
r is the number of rounds
Proof by induction on r
 After
r rounds, the node r away from the Pmax will be
sending UIDmax
 When r = n, UIDmax will have traveled around the ring
7/17/2015
CS 673 Fall 2003
8
Halting LCR

LCR algorithm never halts
 Non-leaders
continuously listen for incoming
messages

Have leader pass a report message around the
ring
 This
is the general way to transform a non-halting
algorithm into a halting one
 Transformation Cost:


7/17/2015
n additional rounds
n additional messages
CS 673 Fall 2003
9
LCR Complexity Analysis

Time Complexity:
Non-Halting
Halting
7/17/2015
Time
Communication
n
2n
O(n2)
O(n2)
CS 673 Fall 2003
10
HS Algorithm
Developed by Hirshberg and Sinclair
 Achieves O(n log n) communication
complexity, O(n) time complexity
 Assumptions:
1

 Unknown
n
 Bidirectional ring
5
2
4
7/17/2015
CS 673 Fall 2003
3
11
1
HS Algorithm (Cont.)
5

2
General idea:
4
 Operate
3
in phases 0, 1, 2, . . .
 During phase p, send UID in both directions
for a distance of 2p
Processing of received UID same as LCR
 If its UID comes back, continue to next round
 If it receives its outbound UID, declare self as
leader

7/17/2015
CS 673 Fall 2003
12
Comparison-based Algorithms

LCS and HS are comparison-based
algorithms
 Only

The communication lower-bound is:
Ω(n log n)
 See

compare UIDs
Lynch section 3.6 for proof
Is this the lower bound in general?
7/17/2015
CS 673 Fall 2003
13
TimeSlice Algorithm
Non-comparison-based algorithm
 Achieves O(n) communication complexity
 Assumptions:

n
is known to all processes
 Unidirectional communication
7/17/2015
CS 673 Fall 2003
14
TimeSlice Algorithm (Cont.)

1
5
General idea:
2
 Have
phases 1, 2, 3, . . .
 Phase p


4
3
Contains n rounds, rounds (p-1)n + 1, …, pn
If a node with UID p exists, it is circulated around the ring
 If
we reach round (p-1)n + 1 and the node with UID =
p has not received any UID before, declare self as
leader

Process with minimum UID becomes the leader
7/17/2015
CS 673 Fall 2003
15
TimeSlice Algorithm (Cont.)

Proof foundation:
 No
messages are sent except between
rounds (UIDmin-1) ·n + 1 and UIDmin·n
Only n messages are sent
 Problem:

 Time
complexity is n · UIDmin
 Unbounded!
7/17/2015
CS 673 Fall 2003
16
VariableSpeeds Algorithm




Another non-comparison-based algorithm
Does not require knowledge of n
Unidirectional links
General idea:
 Each
process sends its UID around the ring
 The UID travels one hop every 2UID rounds
 Each process keeps track of lowest UID seen and
discards anything higher
 If token returns, declare self as leader
7/17/2015
CS 673 Fall 2003
17
VariableSpeeds Algorithm (Cont.)

Complexity Analysis
 Message:
2·n
 Time: O(n · 2Umin)
Outrageous unbounded time complexity
 This algorithm serves as a counterexample
algorithm

Impractical
 Shows that impossibility result cannot be proved

7/17/2015
CS 673 Fall 2003
18
Non-Comparison-based algorithms
Can achieve message costs of less than
Ω(n log n), but at the cost of unbounded
time complexity
 With bounded time complexity, the
message lower bound for noncomparison-based algorithms is Ω(n log n)

 See
7/17/2015
Lynch section 3.7 for proof
CS 673 Fall 2003
19
Model 2: General Synch. Network
2
3
1
4
6
5
n processes each with UID
 Random connectivity
 Strongly connected graph

7/17/2015
CS 673 Fall 2003
20
Variations on the theme
Non-leaders may have to declare
themselves as such
 n may or may not be known
 diam may or may not be known

7/17/2015
CS 673 Fall 2003
21
FloodMax Algorithm
Assume diam is known
 General idea:

 Each
process remembers the largest UID it
has seen
 For each round, propagate UIDmax on all
outgoing links
 After diam rounds, if UIDmax is own UID,
declare self as leader
7/17/2015
CS 673 Fall 2003
22
FloodMax Algorithm (Cont.)
Basically a generalization of LCR
 Communication complexity is diam · |E|

 |E|

is the number of outgoing edges
Also works if only the upper-bound of diam
is known
7/17/2015
CS 673 Fall 2003
23
FloodMax Algorithm Proof Outline
Show that after r rounds, UIDmax has
reached all nodes within diameter r of the
node with the maximum UID
 Claim that when r = diam, all nodes will
2
have received UIDmax
3

1
4
6
5
7/17/2015
CS 673 Fall 2003
24
OptFloodMax Algorithm
A trivial optimization of FloodMax
 Only broadcast the UIDmax if it changed in
the current round
 Correctness is obvious, but the proof is not

7/17/2015
CS 673 Fall 2003
25
OptFloodMax Algorithm Proof

Use the simulation proof method
 Formally

Append a new-info flag to each node
 Only

relate OptFloodMax to FloodMax
broadcast UIDmax if new-info is true
First prove:
UIDmax,i > UIDmax,j for any j out-nbrsi, newinfoj must be true
 Proof by induction on r
 If
7/17/2015
CS 673 Fall 2003
26
OptFloodMax Proof (Cont.)

To complete the proof, relate the states of
OptFloodMax to FloodMax
 Assuming
both are started simultaneously,
after round r, the states of the two algorithms
are the same
 Proof by induction on r

See Lynch 4.1 for proof details
7/17/2015
CS 673 Fall 2003
27
Asynchronous Networks




n processes connected via reliable FIFO
channels
Each process distinguished by UID
Processes do not operate in lock-step formation
Use I/O Automata to model processes and
channels
 Action
7/17/2015
of Pi include sendi, receivei, and leaderi
CS 673 Fall 2003
28
Model 3: Asynchronous Ring
1
n processes arranged in a ring
5
 May be bidirectional or
unidirectional
4
3
 n may or may not be known
 Clockwise neighbor can be distinguished
from counterclockwise neighbor

7/17/2015
CS 673 Fall 2003
2
29
Asynchronous LCR algorithm

Same as synchronous LCR algorithm
except:
 Send
buffer of each process must be able to
hold up to n messages

This algorithm is intuitively correct, but the
proof is complex
 Do
not know where UIDmax is
 Cannot relate location of UIDmax to the round
7/17/2015
CS 673 Fall 2003
30
Asynchronous LCR Proof

Proof outline
 Show
that for 0 ≤ r ≤ n-1, eventually UIDmax
appears in the buffer sendimax+r

Proof by induction on r
 Show
that UIDmax will eventually appear on
channel connecting to the input of imax
7/17/2015
CS 673 Fall 2003
31
Asynchronous HS Algorithm

The synchronous HS algorithm can also
be trivially modified to work in
asynchronous rings
 Just
make sure all channels can handle
message pileups
7/17/2015
CS 673 Fall 2003
32
Peterson Algorithm
Requires O(n log n) messages
 Unidirectional links
 Unknown n
 Relies on asynchronously determined
phases
 Elects an arbitrary process as the leader

7/17/2015
CS 673 Fall 2003
33
Peterson Algorithm (Cont.)


Process can be in active or relay mode
In the first phase, all nodes send their UID two hops
clockwise




If UID of immediate counter-clockwise neighbor is highest of the
three, adopt it as its new UID and remain active
Otherwise, enter relay mode
In the following phases, active node sends their new UID
to their two clock-wise active neighbors and repeat
If an active node sees that its immediate
counterclockwise active neighbor has the same UID,
declare self as leader
7/17/2015
CS 673 Fall 2003
34
Peterson Algorithm Examples
Leader
!
1
2
4
3
7
9
8
5
7/17/2015
4
Leader
!
8
9
9
CS 673 Fall 2003
35
Peterson Algorithm Time Cost

In each phase, the number of active
processes is decreased by two
 O(log

n) phases
For each phase p, the first p phases
complete in O(pn(l+d))
l
= upperbound on time to process message
 d = upperbound on output queue delay

Thus, the time cost is O(n log n (l+d))
7/17/2015
CS 673 Fall 2003
36
Peterson Algorithm Message Cost
There are at most log n  + 1 phases
 During each phase, each process sends at
most two messages (2n messages)
 Message cost = O(n log n)

7/17/2015
CS 673 Fall 2003
37
Communication Lower Bound

The communication lower bound of
asynchronous comparison-based
algorithms is Ω(n log n)
 Synchronous
rings is a restriction on
asynchronous rings
 See Lynch section 15.1.4 for proof
7/17/2015
CS 673 Fall 2003
38
Model 4: Asynchronous General

2
Assumptions:
3
 Bidirectional
1
links
 Random links
6
 Strongly connected graph
 Identical processes except UID
7/17/2015
CS 673 Fall 2003
4
5
39
Asynchronous FloodMax
Since there are no rounds, FloodMax
cannot be trivially extended to asynch.
Networks
 Workaround:

 Append
round number to each message
 Each node collects all incoming round
messages before processing them
7/17/2015
CS 673 Fall 2003
40
Alternative techniques

There are many other general asynch.
network protocols that use:
 Spanning
Tree, Convergecast, and Broadcast
 Synchronizers to simulate synchronous
networks
 Consistent snapshots for termination
detection
7/17/2015
CS 673 Fall 2003
41
Conclusions
There are many leader election protocols
 Special protocols exist for ring networks
 Algorithms for asynchronous networks are
more complicated

7/17/2015
CS 673 Fall 2003
42