INGI2143 – Concurrent Systems

Assignment 2
2009–2010
Charles Pecheur Sébastien Combéfis

November 21, 2010

Assignment due December 3, 2010

This assignment can be performed in groups of two students. Individual
submissions are also accepted. Interaction between students and groups is
allowed but plagiarism will not be tolerated. Contact the assistant, Sébastien
Combéfis (sebastien.combefis@uclouvain.be) for any question regarding
this assignment.

1 Subject
A Leader Election Protocol

We consider a a collection of nodes sharing access to a com-

mon resource. The nodes communicate by messages and are
connected in a ring. To ensure exclusive access to the resource,
they use a token-passing protocol: a token message is circulated
on the ring and whoever has the token may access the resource.
One well-known example is the IEEE 802.5 token ring protocol
for local area networks: in that case, the resource is the right to
transmit data over the network itself.
The protocol must be robust to communication errors and node
failures. If the token is lost, the surviving modes must coordinate
so that one of them will initiate one (and only one) new token.
This is the purpose of leader election protocols. The objective of
this mission is to model and verify a token-passing and leader-
election protocol, under different variants and failure scenarios.

1
2 Technical Requirements
System – The system to be modelled is composed of N nodes arranged
in a ring. Each node communicates with its next neighbor through an asyn-
chronous channel (see schema below). Channels will be modelled as one-slot
buffers that can each hold a single message. Each node has a unique number.
We will assume that one node has number 0 and the others are numbered
sequentially in ascending order along the ring.

node node
channel
0 1
channel

channel
ressource

node node
channel
3 2

Events – The nodes can send and receive two kinds of messages:

• A message token representing the token being passed on,

• A message claim(i), representing an attempt by node i to be elected

to initiate a new token.

Accessing the resource will be modelled as a pair of successive events

open, close. The resource itself is part of the environment and need not be
modelled.

Nodes – All nodes follow the same protocol, specified in the table below,
where i is the number of the current node. Every node has a current state,
which is either I (idle), L (leader), E (eligible) or N (not eligible). Each
row in the table describes a possible action of the node, as a quadruplet
(current, cond, action, next), to be interpreted as “if the state is current
and cond occurs, then perform action and change state to next”.

2
 When current shows several states, the action applies to all of them.
“rcv” and “snd” stand for “receive” and “send” respectively. “—” means
no condition, no action or no change of state.
current cond action next
I rcv token — L
L — access resource then I
snd token
L — snd token I
I, E, N (timeout) snd claim(i) E
E rcv claim(i) — L
I, N rcv claim(i) — I
E rcv claim(j), j < i snd claim(j) N
I, N rcv claim(j), j < i snd claim(j) —
I, E, N rcv claim(j), i < j — —
E, N rcv token — L

The first three rows describe the nominal token-passing protocol. When
it receives the token (L), the node decides whether to access the resource
and then pass the token to the next node or to pass the token right away.
The rest of the table deals with leader election. Upon a timeout, a node
sends a claim and becomes eligible (E). If the claim loops back to it before
a token is received, the nodes initiates a new token (L). In the meantime, it
discards claims with higher numbers but stops being eligible (N) if it sees
claims with lower numbers. The intended result is that if several claims are
started concurrently, only the one with the lowest number will result in a
new token.
Without leader election, one and only one node has to start in the L
state, others starting in the I state. With leader election, all nodes start in
the I state and the leader election will produce the first leader.
We consider that nodes can crash. A crashed node i becomes a bypass
except for its own claims: all received messages are re-sent, except claim(i)
which are discarded.
As we will see, this version of the leader election protocol is unsafe. One
way to fix it is to add a parity bit on claim messages. This is beyond the
scope of this assignment but constitutes a nice challenge for those who want
to probe further.

3 Tasks
1. Draw a structural diagram of the whole FSP model, in the style

3
 of those found in Magee&Kramer (see Section 3.1.6 p. 50). Identify
the components and the interfaces.
2. Build an FSP model for the nominal system with N nodes, no leader
election and no node crashes. Your model should not deadlock. Com-
pile and minimize for increasing values of N . Report statistics (num-
ber of states, computation times) for representative values of N . Use
N = 3 for the parts that follow.
3. Build an FSP property OPENCLOSE that captures correct sequences
of open and close events, with mutual exclusion between successive
accesses. Check that the property holds on your model.
4. Verify, using FSP progress statements, that all nodes can indefinitely
access the resource.
5. Re-define the progress statements of the previous point as an FLTL
property ALLFAIR. Check with and without fair choice (see Options
menu). Explain the results.
6. Build, compile and minimize an abstraction of your FSP model
that hides all communication, leaving only access to the resource vis-
ible. Compare the resulting graph with the one of your OPENCLOSE
property.
7. Extend your FSP model to include leader election. Do not model
the timeout; consider that the corresponding action can happen at any
time. Your model should not deadlock and should pass the progress
properties above. Compile and minimize for increasing values of N .
Report statistics (number of states, computation times) for represen-
tative values of N . Use N = 3 for the parts that follow.
8. Check the OPENCLOSE property again. It should fail. Report and
explain the counter-example trace.
9. Define a FLTL property MUTEX that states that two nodes can-
not access the resource at the same time. Define another FLTL
property NODUPCLAIM that states that no node i can send a sec-
ond claim(i) before it receives back the first claim(i). Check that
NODUPCLAIM -> MUTEX and NODUPCLAIM -> ALLFAIR hold.
10. Extend your FSP model so that nodes can crash. To avoid deadlocks
in your model, add an idle action that does nothing in crashed nodes.
Compile and minimize for N = 3. Report statistics.

4
 11. Check again ALLFAIR and explain the results. Define and check an
FLTL property ALLALIVEFAIR that states that all nodes can indefi-
nitely access the resource as long as they don’t crash.

Remarks:

• Follow the instructions carefully to make sure you get the intended
result: initial states are different without leader election; crashed nodes
forward everything except their own claims; timeout should not be
modelled.

• Take advantage of the richness of FSP. Use parameters and indices

on processes and properties. Build FLTL properties by composing
simpler ones. Use fluents appropriately.

• Minimization uses a lot of memory and LTSA is bound by the Java

heap space. Use command-line options to increase that space. java -Xmx2G -jar $dir/ltsa.jar
will give 2 gigabytes, which should be enough for this assignment.

4 Deliverables
Assignment results will be returned as an archive file (.zip or .gz) whose
base name is the last names of the students (e.g. Pecheur_Combefis.zip,
no accents please). Submit your deliverables using the Assignments tool of
iCampus, before the deadline stated on the first page. Late submissions will
not be accepted. The archive will at least contain an FSP model file (.lts)
and a report in PDF format. If more files are provided, their use will be
explained at the beginning of the report. The report will be no more than 10
pages long, and will address all the items of the Tasks section above. Make
sure to include proper identification (course, year, assignment nr, student
names) at the beginning of all files (report and code).