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.
