9 —
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:
for the Programming Task, place player.PP and referee.PP into Q/Server/ and Q/Client, respectively;
for the Programming Task (2), place server.PP and client.PP into Q/Server/ and Q/Client, respectively;
for the Testing Task, place xbaddies and Tests/ in a repo-level directory named 9.
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—
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).—
The inputs of xbaddies are similar to the one of 7 —
The output format is the same as for 7 —
A JActorsB is a JSON array of JActorSpecBs. |
|
CONSTRAINT A JActorsB contains at least 2 and at most 4 players. |
|
- 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.