首页 > > 详细

辅导CSCU9V5 辅导data structure编程

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.  
 

联系我们 - QQ: 99515681 微信:codinghelp
程序辅导网!