8 — Remote

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—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 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).—Constraint No test file may exceed the size limit of 20Kb.

Its input format is similar to the one of 7 — The Clean Up. It consists of a BadPlayerSpec2 followed by a RefereeState. 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 winner(s). (The details will depend on your referee interface and data representations.)

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