8.11.1.5

10 — Revised! 🔗

Due Wednesday, 30 November 2023, 11:59:59pm with an automatic extension until Sunday, 03 December, 11:59:59pm

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

Programming Task The co-CEOs received a request from their investors to make the software system configurable. Specifically, they would like the sample server, referee, and scoring functionality to be configurable for a number of properties. Specifically,

  • The server configuration specifies the port to listen to, for how many rounds the server waits, for how long each waiting period lasts, for how long it waits for a player’s name, and a referee configuration.

  • A referee configuration contains a state, the per-turn time for a calls to players, and optionally an observer.

  • A scoring configuration determines the bonus values for finishing a game or completing a Q during a turn.

The configurations may also come with a boolean-valued flag that turns on/off debugging output on the standard error port.

Design and implement a data representation for configurations that can specify a fixed set of properties. Note that the configuration for one component may contain a configuration for another.

Abstract the server, the referee, and the scoring functionality over their respective configurations.

Runnables Task for the Last and Final Integration Test Construct two executable programs:
  • xserver, which starts your server from a JSON configuration, and

  • xclients, which launches a number of clients from a JSON configuration and points them to a server.

Also create ten tests ([0-9]-{in client-config, server-config, out}.json) and place them in the specified Tests/ folder.

Both programs are launched with one command-line argument and a JSON object coming in from STDIN. The first specifies the port on which servers and clients connect; the configuration is an object with fields that approximately correspond to the requested internal configurations. The port fields in the configuration are populated with randomly chosen numbers; your scripts must use the PortNumber from the command line.

The test harness will run the programs roughly like this:

    $ ./xserver PortNumber < FileNameForServerConfig &

    $ ./xclients PortNumber < FileNameForClientConfig &

Well-formed and Valid You may assume that all configuration inputs to your test harnesses from STDIN are well-formed and valid. A well-formed piece of JSON satisfies the grammar; such a piece is valid if it also satisfies all the side constraints of a schema specification.

Keep in mind though that the JSON sent from clients to servers should not be trusted and for that matter clients may not wish to trust servers either.

The test harness ensures that the server program runs independently of the client programs. You may to wish write xclients as a short TAHBPL program that spins up threads or as a shell (bash) script that spawns Linux processes. In either case, 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.

Accordingly, a test consists of three files for this last milestone:
  • n-client-config.json, a client configuration;

  • n-server-config.json, a server configuration; and

  • n-out.json, the expected output

where n is an integer between 0 and the requested number of tests (exclusive).—Constraint No test file may exceed the size limit of 40Kb.}

    A ClientConfig is an object with 5 fields:,

       { "port"___ : Natural (between 10000 and 60000),

       { "host"___ : String (either an IP address or a domain name),

       { "wait"___ : Natural (less than 10s),

       { "quiet"__ : Boolean,

       { "players" : JActorsB }

    INTERPRETATION The xclients script is expected to launch the specified

     players as independent threads or processes that communicate with the

     specified host on the given port, in the order listed. Between launches

     the script pauses for the number of seconds specified in the "wait"

     field. Recall that the value of the "port" field is irrelevant; the

     port number is specified on the command line. (The "quiet" exists

     for controlling any debug output the same purpose as the "quiet" fields mentioned above.)

    A ServerConfig is an object with 6 fields:,

       { "port"___________ : Natural (between 10000 and 60000),

       { "server-tries"___ : Natural (less than 10),

       { "server-wait"____ : Natural (less than 30[s]),

       { "wait-for-signup" : Natural (less than 10),

       { "quiet"__________ : Boolean,

       { "ref-spec"_______ : RefereeConfig }

    INTERPRETATION The xserver script listens on the specified port for the

     given number of waiting periods as described in 9 — Remote. Once a

     sufficient number of players are signed up, it hands the referee the

     included configuration and the proxy players. Recall that the value of

     the "port" field is irrelevant; the port number is specified

     on the command line.

    A RefereeConfig is an object with 5 fields:,

       { "state0"__ : JState,

       { "quiet"___ : Boolean,

       { "config-s" : RefereeStateConfig,

       { "per-turn" : Natural (less than or equal to 6),

       { "observe"_ : Boolean }

    INTERPRETATION The xserver script will turn this JSON configuration object

     into the chosen internal data representation for referee configurations and

     include it with the server configuration.

    A RefereeStateConfig is an object with 2 fields:,

       { "qbo" : Natural (less or equal to 10),

       { "fbo" : Natural (less or equal to 10) }

    INTERPRETATION The xserver script will turn this JSON configuration object

     into the chosen internal data representation for scoring configurations and

     include it with the referee configuration.

    Natural is 0, 1, 2, ...

    Boolean is true or false.

    String is "127.0.0.1" (and usually a sequence of ASCII chars).

The state's players in the server configuration and the player specs in the client configuration match up just like in the preceding milestones.