CS333 Lab A-1:
Leader Election
Goal of this lab:
- Learn about the leader election problem.
- Understand and implement two algorithms for
electing a leader in a ring.
Introduction:
In the course of a distributed computation, it is often useful to
be able to designate one and only one process
as the coordinator of some activity.
This selection of a coordinator is known as the "leader election problem"
and it has been studied in many contexts.
In this lab, you will consider the problem of electing a leader among
a group of processes whose communication pattern is arranged in a ring,
where each process can receive messages only from its left neighbor and
may send messages only to its right neighbor. We assume that each
process starts out with a unique identifier (an integer).
Directions:
Implement and test the following two leader election algorithms.
Read over the entire assignment before starting.
- Le Lann-Chang-Roberts Leader Election:
This is perhaps the simplest of all distributed algorithms. However, it
has lousy message complexity. It sends around n squared messages in the
worst case. Try to construct an execution (on paper) in which you would
get this worst case behavior.
The idea of this algorithm is that each process starts by passing its
own identifier to its neighbor. Whenever a process receives an identifier
from its neighbor, it either:
- passes it on around the ring, if the id received is greater than its own,
- discards it, if the id received is less than its own, or
- declares itself the leader, if the id received matches its own.
Notice that the process with the greatest identifier is elected.
Create a single Playground module that implements this algorithm.
Then, instantiate it many times and arrange the communication pattern
in a ring in order to test that it works. You'll need to make some
provision for initially assigning each instance a unique identifier.
- Peterson Leader Election Algorithm:
This algorithm for leader election in a ring is a bit more involved,
but its worst case message complexity is much better. See if you can
figure out (on paper) the message complexity of this algorithm.
(Hint: notice that at least half of the processors become relays after
each round of communication.)
The algorithm works as follows:
- In the first phase, each process sends its identifier two steps clockwise
(so each process sees the identifiers of its neighbor and its
next-to-last neighbor).
- Each process P makes a decision based on its own identifier and
the identifiers it has recieved. If P's immediate neighbor's identifier
is the greatest of the three, then P remains "active" in the algorithm
and adopts its neighbor's identifier as its own. Otherwise, P becomes
a "relay".
- Now, each active process sends its identifier to its next two
active neighbors, clockwise around the ring. Relay processes simply
pass along each message they receive.
- Steps 2 and 3 continue repeatedly, with more and more processes
dropping out as "relays" until a process finds that its own immediate
neighbor is itself, in which case everyone else has dropped out and
it declares itself the leader.
Implement this algorithm as a Playground module. Be sure to think about
how you will manage sending a message two steps around the ring of
active processes. Also, be sure to print out useful messages from
the modules in order to demonstrate that your algorithm is working
properly. For example, at each round, active modules should print out
the round number, the messages received from the two neighbors, and
the decision of whether to remain active or become a relay.
To receive credit for this lab, you should:
- Clean up and print out your code. (Don't turn it in, but
save it for your code/design review.)
- Turn in a
Project Evaluation Form near the beginning of
class on the day you want to do your demonstration and code/design
review. You should be
prepared to demonstrate your working application, explain your
design and code, and answer questions. Also, be prepared to discuss
the message complexities of the two algorithms.