CS333 Lab A-1:
Leader Election

Goal of this lab:

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.

  1. 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:

    1. passes it on around the ring, if the id received is greater than its own,
    2. discards it, if the id received is less than its own, or
    3. 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.

  2. 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:

    1. 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).
    2. 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".
    3. 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.
    4. 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:

  1. Clean up and print out your code. (Don't turn it in, but save it for your code/design review.)

  2. 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.