CS157B: Spring 2021 HW #2: Embedded Static & Dynamic SQL

This coursework is individual. While discussion among students about the coursework is encouraged each student should have a unique submission and be able to explain their code. If plagarism is suspected students will receive zero for the coursework. There are two options for the coursework.

Option 1:

The goal of this option is to add some functionality to handle networking and consistency issues in existing multiplayer games. You may select the game and language of your choice but please include the source of your game in your submission.

If you would like to use java as your language I would recommend using https://github.com/apetenchea/SpaceInvaders as your multiplayer game.

If you would like to use javascript. I would recommend using https://github.com/geckosio/phaser3-multiplayer-game-example as your multiplayer game.

Please feel free to share sources on the forum if you find something you think other students may find useful.

The additional functionality which should be added to the are as follows:

Introduce an artificial network delay to simulate some of the challenges which take place in networked games. This should vary over time to simulate real network conditions. Static network delay will be given partial marks.

Implement bucket sychronization so that all clients have the same frame. rate so the game can be considered “fair”

Implement interest management so that a large map exists on the primary copy of the game while information on objects which are sent to secondary copies should only contain information relavent to that client

Implement dead reckoning so that players continue to update in the event that network problems cause delays in updates received about player position

Implement smooth corrections so that players move towards the correct position after drops in network communication to prevent jerky animation

Introduce some form. of cheat which allows one client to perform. a game action that cannot be done by other clients. This can take multiple forms. One example would be to increase the movement speed of one player

Introduce some checking on the server side which allows the cheating to be detected. This cheating detection should be general rather than specific to how you implemented the cheat. E.g. If you implement a move cheat you should check for unrealistic movements in player position rather than looking for a specific function call.

There is a video on how to get started with the Java option that can be found at https://qmplus.qmul.ac.uk/mod/kalvidres/view.php?id=1560995. The deliverable is concerned with the design of the game. You are expected to upload one zip file containing all the source files for your coursework by 10am the 20th of April. You are also expected to upload a 5-10 minutes video of your code running and explain the features you implemented. This could be demonstrated in the application e.g. showing only some of the game sprites for Interest Management or via the code e.g. explaining the code that creates an artificial delay. There is a seperate link for video uploads that can be found at https://qmplus.qmul.ac.uk/mod/assign/view.php?id=1892626. Information on submitting a video assignment can be found at https://elearning.qmul.ac.uk/guide/submitting-a-video-assignment/. Please note that the submission of a demonstration video is mandatory and failure to submit will result in zero marks. Both the code and video are required for the project.

The marks for this option are as follows:

Artificial Network Delay (4 marks)

Bucket Sychronization (6 marks)

Interest Management (6 marks)

Dead Reckoning (6 marks)

Smooth Corrections (6 marks)

Cheating (4 marks)

Cheating Detection (4 Marks)

Code Style. and Readability (4 marks)

(total 40 marks)

Option 2:

The goal of this option is to expand the work you have done in lab 1 and 2 to create a system which will allow the distributed processing of matrix calculations. The system should have the following features:

A REST interface that allows matricies to be uploaded as files. The files can be any format but I would recommend using the space character to seperate elements and new lines to seperate rows for simplicity. A guide on uploading files can be found at https://spring.io/guides/gs/uploading-files/. The component should be able to accept matricies of arbitrary size but you can assume they are square matricies whose dimensions are powers of 2 so you can use the divide and conquer approach utilized in lab 1. If a matrix is not this size the REST interface should throw an error. The REST interface should also have functionality to trigger the matrix multiplication and present the results. The gRPC client code should be integrated into the REST interface to call the addBlock and multBlock functions on the gRPC server. Partial marks will be awarded for matrix multiplication which does not allow matricies of an arbitrary size.

A gRPC server which provides access to the addBlock and multBlock functions. These functions should be able to accept any square matrix whose dimensions are powers of 2.

There should be multiple instantiations of the gRPC server. You should have at least eight gRPC servers threads. There are two ways to go about this. You could use a large instance with 8 cores e.g. a e2-standard-8 and configure the gRPC threading model to access each of these cores or you could have 8 small instances e.g. e2-micro and configure the gRPC client to spread the load among these servers. I would recommend the later. Please note that you should have sufficient credit for the module to implement the proposed system if you manage it correctly e.g. stop instances if you are not using them. Managing your credit is part of the challenge so requests for additional credit will not be entertained. The performance improvement via scaling is not quite linear (Adding needs to be done after multiplication) but you should see a signficant performance improvement as you add more gRPC servers.

Frequently large scale workloads use the notion of a deadline to determine how many servers should be assigned to a workload. Your system should have a deadline based scaling function. A footprinting function should be implemented to determine the time required for multiplying one block and this should be used to determine the minimal number of servers required to achieve the deadline. You can ignore the adding time for this component (this may lead to a workload exceeded the deadline which is fine).

The marks for this option are as follows:

REST Interface (10 marks)

gRPC Server (6 marks)

gRPC Scaling (10 marks)

gRPC Deadline Footprinting and Scaling (10 marks)

Code Style. and Readability (4 marks)

The deliverable is all the code used for your system. You are expected to upload one zip file containing all the source files for your coursework by the 10am the 20th of April. You are also expected to upload a 5-10 minutes video of your code running and explain the features you implemented. This could be demonstrated in the application e.g. showing a speedup when multiple gRPC server thread are used or via the code e.g. explaining the code that handles footprinting. There is a seperate link for video uploads that can be found at https://qmplus.qmul.ac.uk/mod/assign/view.php?id=1892626. Information on submitting a video assignment can be found at https://elearning.qmul.ac.uk/guide/submitting-a-video-assignment/. Please note that the submission of a demonstration video is mandatory and failure to submit will result in zero marks. Both the code and video are required for the project.

Guidance for deadline based scaling

Last year a number of students had questions about how to implement deadline based scaling so I am including my advice here for clarity.

You will have multiple gRPC stubs which represent the server on the client side. In terms of code it will look something like this:

ManagedChannel channel1 = ManagedChannelBuilder.forAddress(“IP_ADDRESS_1”, 8080) .usePlaintext().build();

ManagedChannel channel2 = ManagedChannelBuilder.forAddress(“IP_ADDRESS_2”, 8080) .usePlaintext().build();

ManagedChannel channel3 = ManagedChannelBuilder.forAddress(“IP_ADDRESS_3”, 8080) .usePlaintext().build();

…

MatrixServiceGrpc.MatrixServiceBlockingStub stub1 =MatrixServiceGrpc.newBlockingStub(channel1);

MatrixServiceGrpc.MatrixServiceBlockingStub stub2 = MatrixServiceGrpc.newBlockingStub(channel2);

MatrixServiceGrpc.MatrixServiceBlockingStub stub3 = MatrixServiceGrpc.newBlockingStub(channel3);

…

You then need to do the footprinting e.g. find out how long one function call will take. You can use System.nanoTime() or System.currentTimeMillis() for this e.g.

long startTime = System.nanoTime();

//gRPC function call

long endTime = System.nanoTime();

long footprint= endTime-startTime;

Please be aware that gRPC supports asynchronous calls so make sure that the server has responded before you mark the endTime. In lab one we use a blocking stub so this is not an issue but to scale effectively you will need a non blocking stub so be careful when you are using different types. More information can be found at https://grpc.io/docs/languages/java/basics/.

After we have the footprint we need to calculate the number of multiply block calls we need and divide to get the number of servers required to meet the deadline which is supplied by the user. It will be something like the following:

int numberServer=(footprint*numBlockCalls)/deadline

You will then need to split the blocks among the different stubs. You could do this with if/else/switch statements or use something like ArrayList https://docs.oracle.com/javase/8/docs/api/java/util/ArrayList.html to keep a queue of blocks which need to processed for each server.