1. Homepage
  2. Programming
  3. COMP90015 Distributed Systems - Assignment 2 Distributed System and Application: Distributed Shared White Board

COMP90015 Distributed Systems - Assignment 2 Distributed System and Application: Distributed Shared White Board

Engage in a Conversation
AustraliaThe University of MelbourneCOMP90015Distributed SystemsDistributed Shared White BoardJavaSocket ProgrammingTCPUDP

Assignment 2: Distributed System and Application CourseNana.COM

Project: 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/Members Size: 1 –Individual (like Assignment 1) . General help: Ask your tutor during /after tutorial session. Also use “Discussion Board” in LMS. Marks Allocated: 25 Note: We expect all students to just finish and submit only the features noted in this specification. To help you in planning, we propose: Basic Features (first complete a system with these features as they are easier to implement) Advanced Features 3Shared White Board – Distributed U sers Shared whiteboards allow multiple users to draw simultaneously on a canvas. There are multiple examples found on the Internet that support a range of features such as freehand drawing with the mouse, drawing lines and shapes such as circles and squares that can be moved and resized, and inserting text. CourseNana.COM

4Main Challenges Dealing with concurrency Regardless of the technology you use, you will have to ensure that access to shared resources is properly handled and that simultaneous actions lead to a reasonable state. Structuring your application and handling the system state For example, you can have multiple servers that communicate with each other or a single central one that manages all the system state. Dealing with networked communication You need to decide when/what messages are sent across the network. You may have to design an exchange protocol that establishes which messages are sent in which situation and the replies that they should generate. If you use RMI, then you need to design your remote interface(s) and servants Implementing the GUI. The functionality can resemble tools like MS Paint. You can use any tool/API/library you want. e.g.: Java2D drawing package (http://docs.oracle.com /javase/tutorial/2d/index.html ) 5Distributed White Board Develop a white board that can be shared between multiple users over the network. The system must be implemented in Java, but you can choose the technology (e.g., it can be even Sockets ) you want to use to build your distributed application : Sockets TCP or UDP? Message format and Exchange protocol ? can be XML-based or your own format) Client can broadcast a message with updates to all other clients, other clients reply acknowledging the message. Java RMI? Remote Objects/Remote Interface? File or Database for Storage Please Choose any technology of your choice Make sure that can achieve the goal when you are choosing “new” technology (otherwise, stick to what you already know). 6Requirements 1: Basic Features Whiteboard –Multiuser system Multiple users can draw on a shared interactive canvas. Your system will support a single whiteboard that is shared between all ofthe clients. Key Elements with GUI Shapes: at least your white board should support for line, circle, oval, and rectangle. Text inputting –allow user to type text anywhere inside the white board. User should be able choose their favourite colour to draw the above features. At least 16 colours should be available. Of course, you are most welcome to be creative/innovative. 7Requirements 2: Advanced Features CourseNana.COM

  1. Chat Window (text based): To allow users to communicate with each other by typing a text.
  2. A “File” menu with new, open, save, saveAs and close should be provided (only the manager can control this)
  3. Allow the manager to kick out a certain peer/user 8Guidelines on Usage/Operation Users must provide a username when joining the whiteboard. There should be a way of uniquely identifying users, either by enforcing unique usernames or automatically generating a unique identifier and associating it with each username. All the users should see the same image of the whiteboard and should have the privilege of doing all the drawing operations. When displaying a whiteboard, the client user interface should show the usernames of other users who are currently editing the same whiteboard. Clients may connect and disconnect at any time. When a new client joins the system, the client should obtain the current state of the whiteboard so that the same objects are always displayed to every active client . Only the manager of the whiteboard should be allowed to create a new whiteboard, open a previously saved one, save the current one, and close the application. Users should be able to work on a drawing together in real time, without appreciable delays between making and observing edits . 9Proposed Startup/Operational Model The first user creates a whiteboard and becomes the whiteboard’s manager java CreateWhiteBoard username Other users can ask to join the whiteboard application any time by inputting server’s IP address and port number java JoinWhiteBoard 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”. An 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. Online peers can choose to leave whenever they want. The manager can kick someone out at any time. When the manager quits, the application will be terminated. All the peers will get a message notifying them. 10Guidelines/Suggestions for Implementation These phases are suggestions for timely progression, you are most welcome to follow your own approach. Phase 1 (whiteboard) –(aim to finish within 2 weeks of announcement) As a starting point: Single-user standalone whiteboard ( OR) You are most welcome to implement a single user and single server. Task A: Implement a client that allows a user to draw all the expected elements. Task B: Implement a server so that client and server are able to communicate entities created in Task A 11Guidelines/Suggestions for Implementation Phase 2 (user management skeleton) Allow the manager to create a whiteboard Allow other peers to connect and join in by getting approval from the manager Allow the manager to choose whether a peer can join in join in means the peer's name will appear in the user list Allow the joined peer to choose quit Allow the manager to close the application, and all peers get notified Allow the manager to kick out a certain peer/user 12Guidelines –Suggestions (You are most welcome follow your own approach) Phases 3 (Final) Integrate the whiteboard with the user management skeleton (phases 1 and 2) Design issues: What communication mechanism will be used? Socket, RMI , or any other frameworks of your choice. How to propagate the modification from one peer to other peers? You may need an event -based mechanism How many threads do we need per peer? At least one for drawing, one for messaging 13Deliverables and Marks Report (4 marks) Code and Demo of Network- based Distributed Users, Shared Whiteboard: Basic System (16 marks) Advanced Features (5 marks) FAQ (Frequently Asked Question) Can I submit without competing Advanced Features? Yes, you can. But you will NOT get associated marks! NOTE: You are NOT allowed to use ANY code taken from any existing shared whiteboard implementation. Full design, code, report has to be Your OWN work. Copying code/content from other sources carries penalty & disciplinary action as per the University rules. 14Final Submission Report You should write a report that includes the system architecture, communication protocols and message formats, design diagrams (class and interaction), implementation details, new innovations Don’t document anything you haven’t implemented in the report. This is misconduct and will result in severe penalties. You need to submit the following via LMS: Your report in PDF format only. The executable jar files used to run your system’s clients/server(s) Your source files in a .ZIP or .TAR archive only . 15Milestone: Demonstration Demonstrations You will showcase your system and discuss your design choices during the demos. Date and venue will be announced closer to the submission date. 16Deadline and Penalties Deadline: May 25, 2023 (Thursday) at 5:00pm Assignments submitted late will be penalized in the following way: 1 day late: -1 mark 2 days late: -2 marks 3 days late: -3 marks 4 days late: -4 marks etc. (that is, -1 mark for each day delay).

Get in Touch with Our Experts

Wechat WeChat
Whatsapp Whatsapp
Australia代写,The University of Melbourne代写,COMP90015代写,Distributed Systems代写,Distributed Shared White Board代写,Java代写,Socket Programming代写,TCP代写,UDP代写,Australia代编,The University of Melbourne代编,COMP90015代编,Distributed Systems代编,Distributed Shared White Board代编,Java代编,Socket Programming代编,TCP代编,UDP代编,Australia代考,The University of Melbourne代考,COMP90015代考,Distributed Systems代考,Distributed Shared White Board代考,Java代考,Socket Programming代考,TCP代考,UDP代考,Australiahelp,The University of Melbournehelp,COMP90015help,Distributed Systemshelp,Distributed Shared White Boardhelp,Javahelp,Socket Programminghelp,TCPhelp,UDPhelp,Australia作业代写,The University of Melbourne作业代写,COMP90015作业代写,Distributed Systems作业代写,Distributed Shared White Board作业代写,Java作业代写,Socket Programming作业代写,TCP作业代写,UDP作业代写,Australia编程代写,The University of Melbourne编程代写,COMP90015编程代写,Distributed Systems编程代写,Distributed Shared White Board编程代写,Java编程代写,Socket Programming编程代写,TCP编程代写,UDP编程代写,Australiaprogramming help,The University of Melbourneprogramming help,COMP90015programming help,Distributed Systemsprogramming help,Distributed Shared White Boardprogramming help,Javaprogramming help,Socket Programmingprogramming help,TCPprogramming help,UDPprogramming help,Australiaassignment help,The University of Melbourneassignment help,COMP90015assignment help,Distributed Systemsassignment help,Distributed Shared White Boardassignment help,Javaassignment help,Socket Programmingassignment help,TCPassignment help,UDPassignment help,Australiasolution,The University of Melbournesolution,COMP90015solution,Distributed Systemssolution,Distributed Shared White Boardsolution,Javasolution,Socket Programmingsolution,TCPsolution,UDPsolution,