10 —
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 components in your code as necessary and document the changes in modifications.md, ideally with perma-urls; deposit modifications.md 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.
xserver, which starts your server, and
xclients, which launches a number of clients and points them to a running server.
Both programs are launched with one command-line argument, the localhost port on which to connect to the counterpart.
$ ./xserver PortNumber < ForServer/n-in.json & |
$ ./xclients PortNumber < ForClient/n-in.json & |
Turn the input files for the full-game tests for 9 —
the (maximally useful) *Equations; and
a Game state.
Note this revised definition of Player as of this milestone.
A Player is an object with 3 fields:
{ "cards" : *Cards,
"wallet" : *Pebbles,
"score" : Natural }
INTERPRETATION A Player instance specifies the pebbles that
the player owns, the cards it has acquired so far, and its score.
an optional Bonus specification. If it is missing, no player gets a bonus. Otherwise it is one of the two specified variants.
-- "RWB" (short for United States of America |
INTERPRETfATION a player whose collective cards display red, white, and |
blue pebbles receive 10 points when the referee determines winners |
|
-- "SEY" (short for Seychelles |
INTERPRETfATION a player whose collective cards display green, yellow, |
red, white, and blue pebbles receive 5 x 10 points |
when the referee determines winners |
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 timeout per call to a player is set 4.0s. The time out for an entire test suite is set 200s.
The xclients program consumes just one JSON value:
*ActorsB, representing the actual players;
It turns these actor specifications into independently running processes clients. The actors are specified in the exact order in which the referee’s knowledge about them resides in the game state.
If these processes clients are launched without precaution, the test is going to run in a non-deterministic fashion and will yield non-deterministic – and therefore unpredictable and irreproducible – results. To reduce the likelihood of a non-deterministic outcome, the xclients script should ensure that each client completes the sign-up step before it launches the next one wait for a couple of seconds between launching clients.
The test bed ensures that the server program runs independently of the clients 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.