代写 GUI Java software network COMP2396B – Assignment 5 Due: 4th May, 2019 23:55

COMP2396B – Assignment 5 Due: 4th May, 2019 23:55
Introduction
This assignment tests your skills on writing networking and multi-threading program in Java.
You are required to write a peer-to-peer (P2P) images sharing system. A hybrid P2P structure is used in this assignment, where a server is used as the source of images as well as that of the list of peers available. In this assignment, you have to integrate the program written in Assignment 3 and Assignment 4 to complete this assignment.
You need to write two main programs. ImageServer.java is the server program, and ImagePeer.java is the client (peer) program. Notice that a server will also act as a peer to share images.
Part I. Server interface
When ImageServer.class is executed, a file chooser should be presented to ask for an image file. (Figure 1)
Figure 1: File chooser Figure 2: Server GUI
The image is then loaded and displayed as shown in Figure 2. If the image file fails to load, the program terminates. Otherwise, the server should listen to the port 9000, and load the “User.txt” which contains the user information into the program and waiting for user to login. The “User.txt” is the file that generated by the assignment 3 authentication interface and should include the following accounts for login:
Username: mqpeng Username: cjli Username: cbchan
Password: Comp2396B Password: 2396BComp Password: HelloWorld0
The image should be resized and scaled to fit into a canvas of 700*700 pixels in size. The button “Load another image” allows the user to change the current image. If the new image fails to load, the old image is retained.

Part II. Peer program and authentication
WhenImagePeer.javais executed, it should ask for the server’s IP address to be connected to. It then asks the peer user to login. (Figures 3, 4 and 5). For the user authentication, you are required to use the authentication module implemented in Assignment 3 as the interface.
The client should use the hash interface to hash the password before sending to the server and the server need to verify the user information before starts the main GUI. Hence, the server should also return the message if the user cannot login. (e.g. Account is locked)
Figure 3: Username input
Figure 4: Username input Figure 5: Password input
If the login is failed or locked, it should show an alert. (Figure 6)
Figure 6: Login alert

Figure 7: Peer GUI
Figure 7 Peer GUI
If the login is successful, an empty canvas should then be presented as shown in Figure 7. Like the server, the canvas size in the peer should also be 700*700 pixels.
Immediately after the GUI is shown, the peer should connect to the server and start to download the image from the server and other peers. Program should be terminated if it fails to connect to the server. (See details below)
Part III: Peer initialization
The server should listen to port 9000 after initialization. The server has to maintain the
following:
1. The image, separated into blocks of 70*70 pixels in size
2. A list of active peers (the peer IP address and port number)
When a peer program is started, it should connect to the server at port 9000. The server should then update the list of active peers, and each peer should collect the list of current active peers from the server. This connection can be closed afterwards.
Part IV: P2P operation
Each peer should perform the following:
1. Try to download blocks of image from the list of peers in simultaneously.
2. Accept connection from other peers and send out blocks of images other peers
needed.
Notice that the server itself is a special peer that is the source of the image to be distributed. Details about the suggested P2P operation will be introduced in the tutorial.

Part V: Update image
The image should be updated if:
1. If the user switches the image from the server program, all peers will change its image
immediately.
2. The user drags and drops the image block using the server program GUI. For such case, the
client only required to download the swapped image blocks.
Example execution
Execution result depends on how the P2P operation is implemented. Here is an example of the execution behavior.
When the first peer starts (after the server), it starts downloading blocks of image from the only peer (the server) available.
When the second peer starts, it starts downloading from the server peer (the bottom part) and the first peer (the middle part).
Notice that since the first peer is also downloading the blocks, the server is sending out blocks to the two peers in an alternating manner so that the first peer can download the other blocks from the second peer.
The first peer will also start download from the second peer.

When the user switches the image in the server, the peers which choose to update the image will download new blocks from the server and other peers.
Marking
– 85% marks are given to the functionality.
Ø You may add additional classes, instant variables and methods to the project.
Ø You may need to include and modify the classes implemented in assignment 3 for the
authentication function.
Ø You will get part of the marks if you implemented some of the features.
Ø A program that can run normally without throwing exceptions during runtime gets
higher marks.
Ø Program with compile error will get 0 mark.
– 15% marks are given to your JavaDoc. A complete JavaDoc includes documentation of every classes, member fields and methods that are not private. JavaDoc for the main method may be omitted.
Submission
Please submit all source files (all *.java file and login information file) in a single compressed file (in .zipor .7z) to Moodle. Please also include your generated ‘User.txt’ file. Late submission is not allowed. Program with compile error will get 0 mark. (Please include any code that help compile)
Program with no Javadoc will not be graded. Do not submit .class file.
Plagiarism
Do not attempt plagiarism. We will check your program with software that checks program structure. Both the source and the copying work will be penalized.
— END —