代写data编程、java设计程序代写

日期：2023-05-24 10:08

Assignment 2:

Distributed System and Application

Cloud Computing and Distributed Systems (CLOUDS) Laboratory

School of Computing and Information Systems

The University of Melbourne, Australia

Other contributors: All Tutors

2

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

3

Shared White Board – Distributed Users

? 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.

4

Main 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)

5

Distributed 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).

6

Requirements 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

of the 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.

7

Requirements 2: Advanced Features

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

8

Guidelines 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.

9

Proposed Startup/Operational Model

? The first user creates a whiteboard and becomes the whiteboard’s

manager

? java CreateWhiteBoard <serverIPAddress> <serverPort> username

? Other users can ask to join the whiteboard application any time by

inputting server’s IP address and port number

? java JoinWhiteBoard <serverIPAddress> <serverPort> 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.

10

Guidelines/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

11

Guidelines/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

12

Guidelines – 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

13

Deliverables 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.

14

Final 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.

15

Milestone: 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.

16

Deadline 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).