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:

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.

Here are the relevant data definitions:

    A BadPlayerSpec2 is a JSON array of PS, BadPS,

    and BadPS2 arrays.


    A BadPS2 is a JSON array of four (4) elements:

      [Name, Strategy, BadFM, Count]


    CONSTRAINT The names of any two different PSs must be distinct.


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


    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.


    GLOBAL CONSTRAINT The array of RefereePlayers (in RefereeState)

      contains as many players as the BadPlayerSpec2. The order of players in

      BadPlayerSpec2 is the same as the order in RefereeState.


      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.