9 — Remote 🔗

Due Thursday, 16 November 2023, 11:59:59pm with an automatic extension until Thursday, 23 November, 11:59:59pm

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

Programming Task It is time to launch phase 2 of our Q.Com, a Plan. Your software architect has derived a specification for the Remote Interactions from the Logical Interactions. The new specification includes a sign-up step.

Your task is to implement this server-client architecture as a layer atop of the existing software. At this moment, your code base contains almost all the components needed for completing this task. If you were to touch your complex software for the logical part of the game, you would likely enbug it. The OOD patterns community teaches us that remote proxies are your friends here. They allow developers to add a remote-communication layer to a software system while leaving the logical parts of a software system undisturbed.

The client TCP-connects a player (or several players) to a server.

The server waits for TCP sign-ups for some time 20s for a minimum number (here, 2) of remote clients to connect and sign up. As long as there isn’t this minimum number of clients signed up at the end of a waiting period, the server re-enters the waiting state (just once) and for the same amount of time. Either waiting period also ends when the server has accepted a maximal number (here, 4) of client sign ups. If at most one player signs up by the end of the second waiting period, the server doesn’t run a game and instead delivers a simple default result:  [ [], [] ].

A server-client sign-up is finished after the client has supplied the player’s name. The server waits for at most 3s for the submission of the name.

If a sufficient number of clients sign up, the server hands them to the referee. When the referee’s work is done, it returns its results to the server.

Take a look at JSON Crashes Windows 11 to see how a developer did not consider all the bad things that can happen to a software system when a JSON message is ill-formed and/or invalid.

Communication In a distributed setting, it is not realistic to assume well-formed and valid JSON messages. Here, it is arguably only the relevant server-side components that must protect themselves against this problem—to eliminate misbehaving player-clients. But, you may also wish to protect the relevant client-side components, just in case a server doesn’t send well-formed, valid message. Why?

Note From this perspective, the use of JSON for integration tests is merely a way to supply a system configuration. By contrast, the JSON messages among server.PP and client.PP is about data exchange between (non-trusting, distributed) components.

Testing Task Create a test harness named xbaddies. The harness consumes its JSON input from STDIN and produces its results to STDOUT. Create ten tests ([0-9]-{in,out}.json) and place them in the specified Tests/ folder.

A test case always consists of given inputs and expected outputs. For this course, a test consists of a pair of files: n-in.json, the input file, and n-out.json, the expected output file, 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.

The inputs of xbaddies are similar to the one of 7 — The Clean Up; they consist of a JState followed by a aJActorsB array of JActorsB. The test harness creates a series of players that are going to use the specified strategies. It then hands these players and the given state to the referee, which runs the game to the end and computes the names of the winner(s) and drop-out(s). (The details will depend on your referee interface and data representations.)

The output format is the same as for 7 — The Clean Up.

Here are the relevant data definitions:

    A JActorsB is a JSON array of JActorSpecBs.


     CONSTRAINT A JActorsB contains at least 2 and at most 4 players.


    A JActorSpecB is one of:

      - a JSON array of two elements: [JName, JStrategy]

      - a JSON array of three elements: [JName, JStrategy, JExn]

      - a JSON array of three four elements: [JName, JStrategy, "a cheat", JCheat]

      - a JSON array of four elements: [JName, JStrategy, JExn, Count]


    A Count is a natural number between 1 and 5/4 7 (inclusive).


    INTERPRETATION Requests a test with a player acting badly.


      A strategy [n, s, b, k] denotes a player named n that pursues

      strategy s until method b is called for the kth time. At

      that point, the method goes into an infinite loop.

For this milestone the Q bonus is 8 and the finish bonus is 4. The time-out-limit is 6s.