Due Thursday, 17 November 2022, 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 Maze/Remote/, respectively;
for the Programming Task (2), place server.PP and client.PP into Maze/Server/ and Mae/ClientMaze/Client, respectively;
for the Testing Task, place xbad2 and Tests/ in a repo-level directory named 8.
Programming Task It is time to launch phase 2 of our Maze.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. So don’t touch the logical components. 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, 6) 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 2s 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.
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 protected 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 xbad2. The harness consumes its JSON input from STDIN and produces its results to STDOUT. Create five tests 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).—
Its input format is similar to the one of 7 —
The output is the same as for 7 —
and BadPS2 arrays.
CONSTRAINT The names of any two different PSs must be distinct.
INTERPRETATION Requests a test with a player actinng badly.
A bad strategy [n, s, b, k] a player named n that pursues strategy s
until method b is called. When b is called for the kth time,
the method goes into an infinite loop.
contains as many players as the BadPlayerSpec2. The order of players in
The test harness will no longer enforce the 7 x 7 board size as of
this test fest, but it will enforce the distinctness of homes.
Index is now any natural number.