[SOLVED] SER321 Assignment 4 -Threads and Serialization Activity 1 and 2

Prerequisites

1. The assigned readings in module 4 on Canvas
2. Lecture videos from Canvas (or in person)
3. Running and understanding the examples listed on the Canvas page
4. Setup of a second device (second computer, AWS EC2) – see Canvas for details (should already be done)

Learning outcomes of this assignment are:

1. Apply sockets in an efficient way
2. Understand how to use threads
3. Understand how to work with shared states when using threads
4. Use different protocols to serialize data

Preliminary things

I strongly advise you to work on Git and GitHub, to version control and also to practice. Commit whenever something works so you are not losing anything.

Structure: you will have to create two programs one for each Activity. So your assignment 4 folder should have two sub directories (activity1, activity2). Each project needs a README.md and a build.gradle file.

Submit your code and all documents via your GitHub Assignment 4 folder and as a zip on Canvas as usual.

1      Activity: Threads (30 points)

Background

For this activity you will convert a simple single-threaded server to a multi-threaded server. You will create 2 versions, one that allows threads to grow unbounded, and one that sets the number of allowed clients at a time to a fixed number. This is just a toy example to get started.

You are given starting code of a single-threaded server. There is a Client provided, which you should use for your implementation. The Readme specifies a protocol which you should implement.

Given Code

You are given starter code for this assignment on Canvas:

• java – a main program that accepts incoming client connections
• java – a program that does the “business logic” of what the client requests • StringList.java – a simple wrapper class for a list of strings
• java – a client which has the main functions and user interaction part which you should implement on the Server/Performer side
• A build.gradle file which can run the base Client and Server, see Readme

You can have any package structure you want and add new classes etc. Important, you should only have 1 Readme and 1 build.gradle file for all 3 tasks. Each task (server) can be started separately and work only with the features described. You can make any changes in the given files you like, BUT the protocol should work as described in the README.

Task 1: Make Performer more interesting (8 points)

Presently, all the Performer does is add strings to the list. Make it more interesting by implementing the protocol described in the Readme. The Client does not have to verify user input, you can assume that when it asks for an int, we will provide an int, etc. The Server however should handle wrong requests and include some error handling, but we will not be mean when testing. You do not have to handle all errors in detail this is more about simple requests and threads. With using things correctly with your Client, things should not crash though! You have some things given but you can make adjustments and add-ons.

Task 2: Make the server multi-threaded (10 points)

Create a new Server threaded class “ThreadedServer”. Task 1 should still run as is! So now many Clients should be able to connect to this server and manipulate the list safely.

1. Name this server class “ThreadedServer”
2. Allow unbounded incoming connections to the server.
3. No client should block.
4. The shared state of the string list should be properly managed. Keep the data thread safe.

Task 3: Make the multi-threaded server bounded (4 points) You can add new classes here of course. Task 1 and 2 should still run as is.

1. Name this server class “ThreadPoolServer”.
2. Only allow a set number of incoming connections at any given time. How many threads should be specified when calling the program through Gradle.

Gradle (8 points)

1. (3 points) In your ONE Gradle file there should be 3 Gradle tasks to run the different servers
2. (1 point) Gradle should use default values for each task, per default host=localhost, port=8000
3. (1 points) We should be able to run “gradle runClient” and it should use the default values.
4. Running your different servers with default valued:
   1. One for running Task 1: gradle runTask1
   2. One for running Task 2: gradle runTask2
   3. One for running Task 3: gradle runTask3
5. (1 point) Provide a detailed Readme.md file in your project, which tells us how to run each task and a description of which parts you accomplished of the requirements.
6. (2 points) Make sure you include your screencast here as well, one screencast for all 3 parts not longer than 4 minutes.

2      Activity: Threads and Protobuf (70 points)

A simple ’multi-player’ game using Protobuf as protocol.

The Game

We want to design and implement a simple modified “version” of the strategy guessing game Battleship. The server will be responsible for handling everything related to the game state and logic. This includes things such as setting and knowing the location of ships on the game board in addition to tracking hits and misses. In this version of the game, players (clients) will be working together to find all of the ships instead of playing against each other.

The server also keeps track of a leaderboard and a log file.

The server and clients communicate through a given Protobuf protocol. See protobuf files and the PROTOCOL.md file in the given code.

YOU HAVE TO implement the given protocol as described in the PROTOCOL.md with the given proto file!!

Your code needs to work with our protocol exactly as defined in the .proto file. If you change it, then our client would not work with our server. Theoretically, everyones client should work with everyones server if you impement the given protocol.

See the video on how the game might look like for more detailed information, the video has slight differences and is just to give a general idea, please go by the requirements specified here.

The points in the constraints section add up to more than 70 points. The extra points will be extra credit.

Include a 4min screencast of your game running in your submission and add the link to your README.

Readme:

1. (0.5 point) A description of your project and a detailed description of what it does
2. (0.5 points) An explanation of how we can run the program
3. (3 points) A short video for each activity (2-4min) showing how you run the program, showing what works and briefly show your code.
4. (3 points) Name the requirements that you think you fulfilled

Constraints (63 points)

Server and client should not crash. They should be well implemented, readable, and use good coding practices. If you do not do the above, you might loose points even if the functionality is fulfilled.

Hint: place your project so that there are no whitespaces in the file path. The way files are read right now will not work with whitespaces in the path – you can change that if you like but don’t have to.

1. The project needs to run through Gradle (nothing really to do here, just keep the Gradle file as is)
2. (6 points) You need to implement the given protocol (Protobuf) see the Protobuf files, the PROTOCOL.md and the Protobuf example in the examples repo (this is NOT an optional requirement). If you do not do this you will loose 15 points (instead of getting the 6 points) since then our client will not run your server for testing and thus basically your interface is wrong and not what the customer asked for.
3. The basic start is given with the client sending over a name to the server and the server responding with a greeting. You continue from there.
4. (3 points) The main menu gives the user 3 options: 1: leaderboard, 2 play game, 3 quit. After a game is done the menu should pop up again. Implement the menu on the Server side (not optional). So the menu options are send by the Server to the Client (you should include that in the greeting response).
5. (3 points) Design your calls and user interaction in a way that they are easy. Remember we have many assignments to grade, design it so it is easy for us. There will be some requirements later you should fulfill.
6. (2 points) When the user chooses the option 1, a leader board will be shown (does not have to be sorted) or especially pretty when it is shown on the Client terminal.
7. (2 points) The leaderboard is the same for all clients, take care of multiple clients not overwriting it (keep it thread safe).
8. (3 points) The leaderboard persists even if the server crashes.
9. (2 points) The leaderboard keeps track of how many points/wins each player has, in the login field you store how often they logged into the server (so they might show up, even if they did not play). We assume same name equals same player, so you overwrite high scores.
10. (4 points) Client chooses option 2 (starting a game), then the client sends a start request to the server. The server will respond with a battleship board (either from a running game if one is in progress or a new game) and a flag specifying if it is a new or joined game.
11. (2 points) The Client should display the board and information if it was a new or running game.
12. (2 points) The Client should also let the player know in which format the row and column should be entered into the terminal. The error check of input type should be on Client side, the Client will then send the row/column to the server.
13. (5 points) During the game the Server waits for the Client to send a row and column (in one request). The Server will then check if the values are on the board (so inside the board dimension) and if it was a hit or miss or an already opened tile. The new board and the hit/miss/old info will be sent to the client and should be displayed in a user friendly way. Or of course an error message if out of bounds.
14. (5 points) Multiple clients can enter the SAME game if one is already in progress and will thus find the ships faster. Make sure that this is thread safe as well.
15. (5 points) Clients win when finding all ships (always 12 ’x’ on a 7×7 board) and get back to main menu, multiple clients can win together (see video). They will all get 1 point when they are in the game together (no matter if they participated or not) and find all the ships. So basically one win is one point. This will be the “DONE” response.
16. (3 points) Clients can also lose together, if both Clients together made more than 42 guesses they lose. Yes, this is especially mean since one Client can spam and the other one not do anything about it but just go with it. This is also the DONE response.
17. (2 points) Give points in some way based on the fewer overall guesses were needed, you can decide on any way you want. Return the points when sending the DONE response on a win.
18. (2 point) Game quits gracefully when option 3 is chosen in main menu.
19. (3 points) If user types “exit” while in the game (instead of row or column), the client will exit gracefully after sending a QUIT request to the server and receiving a BYE.
20. (3 points) Server does not crash when the client just disconnects (without choosing option 3 or exit)
21. (3 points) Your server/client should not crash even when receiving wrong input and wrong requests/responses. Make sure everything is as robust as possible.
22. (3 points) You need to run and keep your server running on your AWS instance (or somewhere others can reach it and test it) – if you used the protocol correctly everyone should be able to connect with their Client. You will need to post your exact gradle command we can use (including ip and port) on the #servers channel on Slack. If at least one person commented on your server you can take it offline if you like.
23. (2 points) You test at least 2 other servers, can be done up to 2 days after the due date. Make a meaningful comment on Slack about it. In case you find an error let the other person know, so they still have a chance to fix it.

NEEDED: On your server always print the non hidden version of the board, so we can grade faster. Make sure your program is robust with all possible inputs, we should not be able to break it and crash it. We will not be mean when running it but with using it to our best ability and basic “gaming” it should not crash. If we can crash it easily you will loose points for it no matter if the main functionality is there.

Hints:

These are some tips you can take them or leave them.

• Spend some time on the given code, make small changes to it, even if they are stupid. Just to get a feel of Protobuf. Especially with the repeated fields. Get the feel for protobuf before even continuing.
• Start with the base functionality, e.g. just test sending one row/col to check for a hit/miss
• Setup with threads first and not when the rest is done (I did it the other way and it was more painful to change)
• Work incrementally step by step. I usually add one new request with dummy data, check if I receive it on the server. Then add the real data, check if I receive it. Then I parse it on server, check if that works. Then create response and send it to client, check if I receive it. I usually go a couple lines at a time, especially if it is a new concept.

Submission

On Canvas submit your link to your Assignment 4 folder on GitHub.