Leader election in a ring

 It is NON-APPLICATION (“ON-PAPER”) PROJECT Leader election in a ring As in a LAN with ring topology, we have a number of stations–entities (at least 3). They need to elect, among themselves, a single leader. This proceeds by executing a “leader election” protocol, which involves exchanging some messages. Note that the ring is unidirectional. The aim is to analyze this protocol “by hand”, by drawing a part of its reachability state space, and to point to “interesting places” within this drawing. One of such places is that in which a leader has been successfully chosen (exactly one entity is in the “I am the leader” state, while all the remaining entities are in their “I am not a leader” states). • Decide on how to model the entities. The FSM framework is strongly suggested. • Hint: The entities need to be “quasi-identical”, which also means that their behavior is the same (and thus the specification of the behavior of each of them is identical). They need, however, to differ somehow. In the original version, they differ in their address. This address is sent in the messages of a protocol. When the FSM framework is chosen, this is not possible, and the order of addresses needs to be coded into the names of signals. For you to think out the rest (the FSMs for stations may not be entirely identical, after all). • First, analyze the regular case, in which each entity (station) has a different address. This is normally the condition for the correct operation of ring networks. • Then analyze the corrupted case, in which two entities have the same address. How does the state space change? Any new faults? The result of the project – generally: the restatement of the problem in terms of a protocol, – a drawing of(a part of) the reachability state space, with annotations – marks pointing to faults and an analysis of what kind of fault that is.