辅导案例-CSCU9V5
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.