ECE419S: Distributed Systems Assignment 3 solution

$29.99

Original Work ?
Category: You will Instantly receive a download link for .ZIP solution file upon Payment

Description

5/5 - (4 votes)

Introduction In the second assignment, you implemented a client-server version of the multiplayer game, Mazewar. You were provided with the single player version of Mazewar where you could play against simple computer controlled opponents, and you were asked to extend it by adding network communication support and making it distributed according to the specified client-server design. Now that you have a better understanding of the game codebase, more experience in the tools necessary for building distributed systems, as well as the knowledge of the concepts from the lectures, you will design and implement a decentralized distributed game system on your own. That is, you will have the freedom to reason about the design of a decentralized distributed game solution, to pick the design choices that you think are best and to produce a specification and implementation showing your creativity. 2 Assignment Requirements In this assignment, you are to design and implement a decentralized distributed version of the multiplayer game, Mazewar. Unlike Assignment 2, all processes in this distributed version will be more or less identical. That is, there will be no central server that receives events from any client/player process and broadcasts them back to all processes in the system. You are required to use the ug computers in the GB 243 lab to implement and run your game in a distributed fashion, e.g., by playing against your team member or other classmates. The source code for the MAZEWAR single player version that was provided to you for Assignment 2 is placed on the ug machines, under ${ECE419_HOME}/labs/lab2/mazewar/. ${ECE419_HOME} is /cad2/ece419s/. NOTE: If you plan to run the code on your home machine, you will have to update the path to Java (i.e. ${ECE419_HOME} and ${JAVA_HOME}). 2.1 How to Work on the Lab This assignment consist of two parts: design and implementation. You are required to fully design and implement a decentralized version of the distributed game. At this point, you should be part of a programming team. The programming team should have two people. In addition, your programming team should be part of a design team. A design team should consist of up to 3 programming teams i.e., up to 6 people. In the worst case, the design team can be the same as the programming team. The design teams are for the purpose of discussing the given codebase, designing and specifying a protocol for the game, not for jointly writing code. You may not share code with other programming teams. For this assignment, all members of a design team should interact, discuss design choices, tradeoffs, and devise a common design to be implemented by each programming team separately. Each design team should produce a final design document of about 2, 3 pages, where you describe your design choices and answer the questions in the Design section below. All members of a design team can discuss a common design, have the same design choices and produce the same design document. A preliminary version of this design document (one per design team – please write the names of your full team in the design document) needs to be handed in to the instructor, in class, by March 1st. This is just to make sure that you start early on this assignment. The main intent of the design teams is to restrict wide discussion of design, hence ensure variety between different projects (we don’t want to be bored during the demos). It also allows you to spread the load of producing the design document across more people. More theoretical uses of design teams, that may apply only to industrial environments, are compatibility tests of different game players, with potentially different code, implemented by different people, but written to a common, known, design specification. If the specification is respected to the letter, in theory, two programming teams can play the game simultaneously with each other – for the purposes of this class this is not a strict requirement, however. Each programming team should implement the distributed game independently based on the design. The final version of the design document, design.pdf, should be submitted together with the code by each programming 2 team by the assignment deadline. In the design document, include the names and student IDs of the submitting programming team members (as well as the names and student IDs of the larger design team members). I suggest that you stick to the rules provided in the Mazewar game description, but you are free to make any additions that you think improve the game, as long as you document them clearly. Your game should not allow inconsistent states to be seen by different players. Specifically, all player moves should be displayed in a consistent order on all player displays. Assuming there are only two players, e.g., the players of your team, you should not allow that the display of one player shows that the local player has made a move before its opponent, while the other display shows the reverse. You can choose any algorithm introduced in class to implement a total ordering of events across all processes in your distributed system or a new algorithm of your own design. Furthermore, you can use any distributed system structure including, but not limited to, organizations of the distributed system in a ring, where each node communicates only with a predefined neighbour or a symmetric structure where a node communicates with all other nodes. You can also assign special roles to processes in your distributed system, as long as the role functionality is minimal and lightweight. 2.2 Design Your design team is to jointly design the specification of the protocol used by the game components as well as the overall distributed algorithm. The design description should be thorough enough so that all programming units of the design team can independently implement a Mazewar program to the specification and, if needed, have it interoperate with each of the other programs. The description should be submitted in the design.pdf document along with the code. The description should have the information in an easy to understand format such that someone else can duplicate your design. For instance, the design description should include: • Overall distributed algorithm functionality, components, interactions • Communication protocol – packet types and formats • How a player locates, joins and leaves a game of Mazewar • If you handle failures: what happens when a process loses contact with another process? • Timings of protocol events, and how they provide sufficient consistency for the game state • Pseudo-code or an abstract description of process behaviour • Anything else you think of that’s relevant to your system Questions to be Answered in the Design Document Answer each of the following questions in the final design.pdf document. Point form answers are encouraged. • Evaluate the portion of your design that deals with starting, maintaining, and exiting a game – what are its strengths and weaknesses? • Evaluate your design with respect to its performance on the current platform (i.e. ug machines in a small LAN). If applicable, you can use the robot clients in Mazewar to measure the number of packets sent for various time intervals and number of players. Analyze your results. • How does your current design scale for an increased number of players? What if it is played across a higherlatency, lower-bandwidth wireless network – high packet loss rates? What if played on a mix of mobile devices, laptops, computers, wired/wireless? • Evaluate your design for consistency. What inconsistencies can occur? How are they dealt with? 3 3 Grading This lab assignment represents 8% of your final grade for the course and is due by Thursday March 21st 2013 11:59 PM. You must implement your solution to: 1. Be a consistent game 2. Be playable, i.e. the game must respond quickly to player moves 3. Handle up to 4 players 4. Optional: Handle RobotClients (5% bonus) 5. Optional: Dynamic behaviour – dynamic joins&departures of players (5% bonus) 6. Optional: Some notion of fault tolerance – handle failures of components (5% bonus) You also need to provide a live demonstration of your distributed game during a Lab session (date to be determined). The lab will be graded according to the following scheme: • 20% for the design document based on the criteria described below • 10% for a successful demo to a TA or instructor • Full credit (70% of total assignment grade) for an implementation having all components working according to the objectives – game is decentralized, consistent, fast/playable. • 50% if your game is playable, but has a minor functional or logical mistake, e.g., inconsistencies or visible delays. • 20% if your program is partly working but has several or major functional or logical mistakes. • Otherwise, 10% if the code compiles successfully. To receive this credit, your code has to show “reasonable effort” towards the objective of the lab part and any compilable code will not award you this credit 🙂 • If you do not hand in a preliminary version of your Design document by Tuesday, March 1st, you lose 10% The design document will be graded for the design team as a whole (i.e., a single grade will be given to all members of the design team), based on the following criteria: • Correctness Does the design support a distributed game of Mazewar that conforms to the specification in the game description? • Clarity/Simplicity/Thoroughness Is it clear enough for independent software engineers to implement it consistently? Is it also detailed enough without being too verbose? (e.g., Lack of clarity and extraneous complexity can increase development time and can further detract from programs in the group interoperating) • Efficiency Does the protocol minimize the network packet traffic and also avoid extraneous processing load on each node? Does your design introduce potential bottlenecks, such as a single coordinator that handles complex tasks? (We are interested in designs avoiding unnecessary overhead. Extreme optimization is not important.) • Analysis Are the questions regarding the required design analysis complete and accurate? 4 4 Submission Only one team member needs to submit the assignment. Include the names and student numbers for your programming team members in a README file. Your submission should consist of the design.pdf document, source files, Makefile, and the README. Your submission must be in the form of one compressed archive named Lastname1.Lastname2.tar.gz. The directory structure of the archive should be as follows: Lastname1.Lastname2.Lab3/ design.pdf (don’t forget to include names, student IDs for all your design team members) README (short description of how to run your code and other aspects you feel worth mentioning) Makefile scripts Once you have a compressed archive in the .tar.gz format, you may submit your solution by the deadline using the submitece419s command, located under /local/bin on the ug machines: /local/bin/submitece419s 3 Lastname1.Lastname2.tar.gz 5