10 — Revised!🔗

Due Thursday, 28 November 2024, 11:59:59pm with an automatic extension until Monday, 02 December, 11:59:59pm

Purpose This milestone has three learning goals:

• T to create scripts that enable devops to launch the server and several clients, which of course enables a thorough test of the integrated distributed system.

• T to modify the system in a way that cuts across several layers. The experience will simulate the life span of a product, which really is a message from 10 weeks ago – and different developers – to you at this point in time.

• S to reflect on the programming experience in an honest manner.

Delivery Place the product of this week’s milestone into your git repo as follows:

• for the Programming Task, modify the necessary components in your code and document the changes in modifications.md, which goes into Bazaar/Planning/;

• for the Runnables Task, place xserver and xclients and Tests/ in a repo-level directory named 10.

Programming Task Modify your server-side software so that certain players are rewarded with bonus points while the winners are determined, not during the game.

The referee awards every player some bonus points for having bought cards that jointly display the following colors:

• red, white, and blue.

  For this case, a player gets 10 extra points.

• blue, yellow, red, white, and green.

  For this case, a player gets 5 x 10 extra points.

Whether the player owns a single card that happens to display these colors or several does not matter.

Hint This change concerns the logic not the communication layer, so it is critical to start the work at this presumably well-tested layer. So, get the logical change correct first. Adjust any unit tests for which you know up front that the results change. Then re-run the integration tests, once the server-side components can award the bonus points. Adjust and use your observer to double check that the awards are handed out correctly. After that, tackle the “runnables” task.

Both programs are launched with one command-line argument, the localhost port on which to connect to the counterpart.

Turn the input files for the full-game tests for 9 — Remote (and below) by hand or script into pairs of input files. Put them into the two distinct folders—ForServer (inputs for xserver) and ForClients (inputs for xclients)—to cleanly separate concerns.

It spawns the server program, which turns these two values into internal data representations. Then the server waits for the players to sign up. Once the server has registered players according to the policy specified in 7 — The Clean Up, it hands them in descendantdescending-age order to the referee’s testing method, together with the given equations and game state to the referee’s testing method. The latter runs a game and hands the result of running the game back to the server, which renders it as a JSON value to STDOUT.

The xclients program consumes just one JSON value:

• *ActorsB, representing the actual players;

It turns these actor specifications into independently running processes. The actors are specified in the exact order in which the referee’s knowledge about them resides in the game state.

If these processes are launched without precaution, the test is going to run in a non-deterministic fashion and will yield non-deterministic – and therefore irreproducible – results. To reduce the likelihood of a non-deterministic outcome, the xclients script should wait for a couple of seconds between launching clients.

The test bed ensures that the server program runs independently of the client programs. The idea is to spawn the server and the clients as parallel programs to mimic a distributed setting as much as possible using a single machine.

The test bed compares this actual output to the expected output of the test case; it ignores the output of xclients.