代做program编程、代写Java程序设计

日期：2024-05-11 08:39

Assignment 2:

Distributed System and Application

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.

◼ Free draw and erase must be implemented (it will be more convenient if there are

several sizes of eraser)

◼ 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 17, 2024 (Friday) 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).