CSCU9V5
CSCU9V5: Concurrent Distributed Systems
RESIT Assignment 2 -‐-‐ Distributed Systems
Assignment Outline
This assignment covers material presented during the lectures on distributed systems and builds
upon the work in the distributed practicals. The deadline for submitting this assignment is
Tuesday, 24th April 2020 at 12:00
A mandatory demo where you will demonstrate your solution to the given problem. A schedule
will be communicated.
For the submission you should prepare a single document which includes i) a short report
(roughly four pages plus a cover sheet with your student number) discussing the problem, any
assumptions you made, and a description of your solution; as well as ii) the code listings of your
program. Please use appropriate report headings.
The report should include appropriate diagrams of the design and screen shots of your
application. Describe the various classes, their relationships, and outline the class methods. The
report should explain how complete your solution is, and if applicable, any special cases when
your program is not functioning correctly. It is important that your program code is properly
commented, and neatly structured for readability. You will lose marks if the code is not
sufficiently commented or formatted!
In short, your assignment submission should consist of (in a single document):
• a cover sheet giving the module, title, and student number
• a document of about 4 pages discussing the problem and your solution
• a printout of your program code with comments
and
• a zip file of your source code (for reference purposes only).
You will receive marks for:
• the efficacy of the code (basic solution) 45%
• advanced features 20%
• the report 25%
• code comments and structure 10%
CSCU9V5
Assignment Problem
Basic Problem
This assignment will extend the theme of the third distributed laboratory, where you developed a
Distributed Mutual Exclusion (DME) system based on a socket-‐based token ring. In the lab you
had a class implementing a ring node and a start manager class to inject a token to start off the
system.
In this assignment you will develop a traffic light centralised controller, that works like a
centralised DME. The system will consists of two traffic lights and a coordinator. The rule is that
only one traffic light at the time can expose the green light and let the cars that it controls go. In
a word, the green light of the two traffic lights must be mutually exclusive.
In order to guarantee the correct functioning of the traffic lights, a given coordinator
passes a unique token to each one of the two traffic lights, exclusively. When granted the unique
token, a traffic light will be allowed to switch the green light on, keep it on for a while, and then
switch the light off (no car is allowed to pass) and return the token to the coordinator. A traffic
light cannot switch the green light on if it does not have the token. In a sense, switching the
green light on is a critical section that can be performed by one traffic light only at the time.
You can assume that the coordinator program runs on a JVM on one computer in the
system, and the traffic light programs, called nodes, run on a different JVM, possibly on a
different computer. The two nodes are connected to the coordinator, they use sockets to
communicate, as standard.
You will be issued with a skeleton solution, with incomplete programs for the coordinator
and the nodes, as a starting point. It is strongly recommended that you study the details of the
problem and the general functioning of the provided implementation.
Each node will be running on a specific host and port (the port must be instantiated at launch
time, e.g. by the command line). For simplicity, the two nodes and the coordinator will be
running on the same host, i.e. your computer. However, the skeleton solution proposed is
general and could work on different hosts. Each (non-‐coordinator) node will perform the
following loop:
1. request the token from the coordinator. This is done by passing node's ip and port to the
coordinator (the coordinator listens on port 7000 at a known ip).
2. wait until the token is granted by the coordinator. Granting the token can be implemented
by a simple synchronisation by the coordinator on the node's ip:port, analogously to what
done for the socket-‐based token ring that you developed in the practicals.
3. execute the critical region, simulated by printing the message "Green light ON", sleeping
for about 3-‐5 secs, and printing the message "Green light OFF", clearly marking the
beginning and end of the critical section. Important: the two nodes (and the coordinator)
will run on different windows (open more console windows or better use three
terminals/CMD in three different windows). It must be evident that only one node at the
time is executing the critical session. Adapt, if needed, (random) timings to facilitate the
understanding of programs' execution, and to test your program.
CSCU9V5
4. return the token to the coordinator. This can also be done by means of a synchronisation
message (the coordinator listens on port 7001).
The coordinator consists of two concurrent tasks that share a buffer data structure:
• a receiver that listen for requests from nodes. Requests consist of ip and port sent
through a socket (on port 7000). On connection, the receiver will spawn a thread
(C_connection_r) that receives ip and port, and store them in the buffer using a request
data structure, defined in the code.
• a mutex thread that constantly fetches requests from the buffer, if any (!), in a FIFO order.
For each request, the mutex grants the token to the requesting node, by a simple
synchronisation to the node's indicated port. Then, it waits for the token to be returned
by means of a synchronisation (on port 7001).
All sockets/servers must be suitably closed. All exceptions' catches must print appropriate
messages, declaring occurred exceptions, if any -‐ there should be none! All nodes must print
suitable messages showing their activities as suggested, e.g. star and stop of a critical section for
nodes, and granting and receiving the token back for the coordinator.
Add some suitable random sleeping times and keep them varied: the order of granting
the token to nodes should not be fixed. Please, test the case of one "very quick" traffic light that
issues requests very frequently and one "very slow" traffic light, which issues request with a
lower frequency. Verify that the fast one can switch the green light on more frequently than the
slow one.
All relevant primitives, e.g. a synchronisation communication, have been seen in labs.
Develop a socket-‐based centralised DME based on the skeleton code provided.
Advanced Features
NOTE: basic solution and advanced features must be developed in separate files in different,
clearly named directories.
You can enhance the basic solution by implementing more advanced features:
1. Traffic lights are a bit less clever: nodes do not ask for the token (we can imagine that
they do so depending on the number of waiting cars) but the coordinator grants the token
to each of them alternatively. The two nodes initially have to register with the coordinator
in order to communicate their ip and port -‐ they can use the same mechanism as in the
previous case, but the queue of pending requests is not needed anymore.
2. Describe in the report what would happen if the coordinator crashes. Be as precise as
possible and consider all the possible relevant cases.
CSCU9V5
Plagiarism
Work which is submitted for assessment must be your own work. All students should note
that the University has a formal policy on plagiarism which can be found at
http://www.stir.ac.uk/academicpolicy/handbook/assessmentincludingacademicmisconduct/#
q-‐8.
Plagiarism means presenting the work of others as though it were your own. The University
takes a very serious view of plagiarism, and the penalties can be severe.
Specific guidance in relation to Computing Science assignments may be found in the
Computing Science Student Handbook.
We check submissions carefully for evidence of plagiarism, and pursue those cases we find.
Several students received penalties on their work for plagiarism in past years. Penalties range
from a reduced mark, through to no mark for the module, to being required to withdraw
from studies.
Submission on CANVAS
Please ensure you submit your assignment on CANVAS before 12:00 on 24th April 2020. This
should be a single file with your report with the source code listings, and a zip of your source
files.
Late submission
If you cannot meet the assignment hand-‐in deadline and have good cause, please contact the
module coordinator by e-‐mail (Dr. Andrea Bracciali) before the deadline to explain your
situation, and ask for an extension through the Extension Request service on Canvas.
Coursework will be accepted up to seven calendar days after the hand-‐in deadline (or expiry
of any agreed extension), but the grade will be lowered by 3 marks per day or part thereof.
After seven days the work will be deemed a non-‐submission.