Assignment 2 – Team Project: Distributed System and Application

1. Assignment 2 – Team Project:Distributed System and Application Dr. Rajkumar Buyya Cloud Computing and Distributed Systems (CLOUDS) Laboratory Department of Computing and Information Systems The University of Melbourne, Australia

2. Two Team Projects: Pick your favorite • (1) Distributed Race Car • (2) Distributed, Shared White Board • In these slides, we are offering mainly guidelines for satisfactory work, but be innovative and creative, which will be valued a lot. • Team Size: 4 (Strongly recommended) • You choose your own team members. • A small variation in group size is permissible, but it is important to note that we look at the total system irrespective of group size. • Note: Each member contribution will be evaluated and marked accordingly. • General help: Ask Lecturer/TA during/after lectures in person. Also use “Discussion Board” in LMS. • Marks Allocated: 30

3. Distributed Race Car

4. Distributed Car Racing • The ultimate goal of the project is to allow one person to drive his or her car on one workstation and the other person drive his or her car on a second workstation while both individuals can view both cars on their screens. Support min. 2 participants in racing, but scalable design and implementation supporting larger number of participants will be well regarded.

5. Phase I: Design your car • Using a tool such as xpaint, your team should create a GIF image of a race car viewed from the top (suggested size: 50X50 pixel). You should create 16 versions of the image rotated around its center, i. e., one for every 22.5 degrees around the circle • You will need two racing cars with the same 16 views. Make sure you can distinguish the two cars. Be creative in the design of your cars! • Write a Java application that spins your two cars. You can see my solution by running: • java Spin 50 (here 50 is the time in milliseconds for the animation delay)

6. Cars Spinning

7. Phase 2: Start the race track • Create a Java application for a race track where you can "drive" your two cars on one workstation • To see the track, run the following: • java Track • Sample codes for making a track Color c1 = Color.green;g.setColor( c1 );g.fillRect( 150, 200, 550, 300 ); Color c2 = Color.black; g.setColor( c2 ); g.drawRect(50, 100, 750, 500); // outer edge g.drawRect(150, 200, 550, 300); // inner edge Color c3 = Color.yellow; g.setColor( c3 ); g.drawRect( 100, 150, 650, 400 ); Color c4 = Color.white; g.setColor( c4 ); g.drawLine( 425, 500, 425, 600 );

8. Phase 3: Setup runtime environment • Select four keys for each of the two players • Two keys are used to change the direction of their car. A key press turns the car 22.5 degrees left or right. • The other two keys are to change the speed of their car. The speed is an integer value from 0 to 100. One press of a key either increases the speed by 10 or decreases the speed by 10. • Write a Java application that allows two persons to drive their own cars around the racetrack. • You may add additional graphical features to the track to make it visually more interesting. • Your team should add collision detection between a car and the walls of the racetrack and between the two cars. • In the event of a collision of a wall, the car crashes and its speed becomes 0. The other car can proceed. • In the event that both cars collide, both cars crash and there is no winner. • Add a Restart option as a menu item to allow the race to start over.

9. Phase 4: Race cars on two workstations • The idea here is to have a server and two clients to allow each player to drive his or her race car on different computers. • Design issues: • What functionally is performed on the server? Does the server need to interact with a database or legacy software? Does it provide centralized services? • In this phase your team is to use as much of Phase 2 as possible. Therefore, the two clients perform most of the functionality. The server only provides the communication pipe between the two clients. • What functionally is performed on the client? What user interface needs to be provided? • A user can only control his or her own car with four keys. When one person drives his or her car, the motion of the car should appear on both workstation's screens. If the two cars collide, the game is over and both clients need to be notified. Allow either player to restart or exit the game from a menu. • How many clients? And what categories of clients? • In this phase we have two clients.

10. Phase 4: Race cars on two workstations • Design issues: (contd.) • What message protocols are needed? What does each type of message look like? What events cause a message? Does the application need a secure channel? • Your team will need to give careful thought on how to do this. • How to get the application started? Is authentication of clients/users needed? • You will need to start the server first. Allow either client to connect first. After both clients have connected and the GIFs of the cars are loaded, you will need a way to start the race. • How to close the application down? • If a user exits in the middle of a race, the client should inform the server then the server can inform the other client to exit as well. • How many applications can run simultaneously? • Here we assume only one game (2 cars racing) at a time. • How to coordinate the server and the clients? • You can't have a client send a request and the server not respond. If you do, the application will lockup.

11. Hand in/Discuss/Email as appropriate (Each phase will contribute to overall outcome) • Phase 0: Team finalized – today OR by the next class (Sept 11). • Phase 1 – Sept 25 • Team should email the working Java code and a snap shot of the output. • Phase 2 – Oct 9 • Due: just discussion in the class on progress • Team should hand in a print of the working Java code and snap shots of the output. • Phase 3 – Oct 16 • Due: discuss health of project • Team should email the working Java code and snap shots of the output. • Phase 4: Execution and Project Closing – Oct 30 • Your team should hand in a print of the working Java code and snap shots of the output. • A demonstration is required • A report should include: system architecture, communication protocols, design diagrams, and a section on contribution of each member. • Timely submission and progress/presentation in class: 4 marks (1 mark for each phase).

12. Distributed, Shared white board

13. Shared White board • Shared whiteboards are another form of collaboration of the Internet. If two or more people are connected to the Internet at the same time, they can communicate through graphic images on a shared whiteboard. Simple drawing tools are provided that allow them to draw arrows, circles, and other simple symbols in the shared space. In addition, one or both of them can paste in images or text that was copied from another source. Shared whiteboards require special software (such as CU-See Me or Net Meeting). Some of the more advanced software even allows users at remote sites to share applications. For example, an instructor may have Excel on his or her computer and be able to display it on a remote student's computer. The student and teacher will both be able to input data and make revisions. (http://fcit.coedu.usf.edu/distance/chap8.htm)

14. Distributed white board • Develop a white board that can be shared between arbitrary number (generally <10) of peers • Behaviors • The first people create a white board and start to draw herself. She then becomes the manager • java CreateWhiteBoard 1234 username • Other peoples can ask for joining the white board application on any time by inputting the first people’s IP address and port number • java JoinWhiteBoard manjra.cs.mu.oz.au 1234 username • A notification will be delivered to the manager if any peer wants to join. The peer can join in only after the manager approves • A dialog showing “someone wants to share your whiteboard”. • A online peer list should be maintained and displayed • All the peers will see the identical image of the whiteboard, as well as have the privilege of doing all the operations (draw and erase) • Online peers can choose to leave whenever they want. The manager can kick someone out whenever she wants. • When the manager herself quits, the application will be terminated. All the peers will get a message about that.

15. Phase 1: A white board for single user • Make a electronic white board application for single user • You may learn the basic behaviors from MS paint • Functionality • Shapes: at least your white board should support for line, circle, rectangle and oval. More shapes are expected. User should be able to switch between filled and un-filled mode. • Free draw and erase must be implemented (it will be more convenient if there are several sizes of eraser) • Text inputting must be implemented – allow user to type text everywhere inside the white board • User can choose their favorite color to draw the above features. At least 16 colors should be available • The new drawing should be always on the top (override the old ones) • A “File” menu with new, open, save, saveAs and close should be provided (in the distributed version, only the manager can control this)

16. Phase 2: Online user management skeleton • Functionality • Allows the manager to start up the application on a given port • Allows other peers to connect in and join in when she’s got approved by the manager • Allows the manager to choose whether a peer can join in • In this phase, join in means the peer name will appear in the user list • Allows the joined peer to choose quit • Allows the manager to kick out certain peer • Allows the manager to close the application, and all peers get notified

17. Phase 3/4: Integrate the white board with the user management skeleton • Design issues: • What communication mechanism will be used? • Socket, RMI, CORBA or Web service, whatever you like • How to propagate the modification from one peer to other peers? • May need an event-based mechanism • How many threads do we need per peer? • At least one for drawing, one for messaging • Must I use Java as the programming language? • Strongly preferred

18. Hand in/Discuss/Email as appropriate (Each phase will contribute to overall outcome) • Phase 0: Team finalized – today OR by the next class (Sept 11). • Phase 1 – Sept 25 • Team should email the working Java code and a snap shot of the output. • Phase 2 – Oct 9 • Due: just discussion in the class on progress • Team should hand in a print of the working Java code and snap shots of the output. • Phase 3 – Oct 16 • Due: discuss health of project • Team should email the working Java code and snap shots of the output. • Phase 4: Execution and Project Closing – Oct 30 • Your team should hand in a print of the working Java code and snap shots of the output. • A demonstration is required • A report should include: system architecture, communication protocols, design diagrams, and a section on contribution of each member. • Timely submission and progress/presentation in class: 4 marks (1 mark for each phase).

19. Phase 0 • Decide your team today (4 persons) • Email team details: • Name, Std no. of each member • to TA "Rodrigo N. Calheiros" <rnc@unimelb.edu.au>

20. Additional References • Fundamental Concepts learned in this subject. • David Brackeen, Developing Games in Java, ISBN: 1592730051; Published: Aug 21, 2003, InfomIT Press. http://www.brackeen.com/javagamebook/