9 —
Due Thursday, 14 November 2024, 11:59:59pm with an automatic extension until Thursday, 21 November, 11:59:59pm
Purpose This milestone has two distinct learning goals:
T to use a complex design pattern so that the addition of functionality does not interfere with well-tested components.
When developers must add functionality—
here communication functionality— to a well-tested and well-working system, they should try not to touch the existing code. Because if they do, they are likely to enbug it. People have come up with design patterns to address just such situations. This milestone is about practice with just one of these design patterns. T to ensure that the core system can cope with components that hog resources (time).
When a single connected component keeps the core functionality from running, it denies others the services of the core. To prevent such service denials, the core system must “discover” such time-consuming components, disconnect from them, and make sure it never interacts with them again.
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 Bazaar/Server/ and Bazaar/Client/, respectively;
for the Programming Task (2), place server.PP and client.PP into Bazaar/Server/ and Bazaar/Client/, respectively;
for the Design Task, place bonus.md into Planning/
for the Testing Task, place xgames-resources and Tests/ in a repo-level directory named 9.
Programming Task It is time to launch phase 2 of our Bazaar.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.
Look into the Remote Proxy design pattern.
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. 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 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 flowing back and forth between server.PP and client.PP is about data exchange between (non-trusting) components.
Design Task The co-CEOs have decided to change the game just a bit. In
addition to scoring each turn, the referee is going to award a bonus of 10
points at the end of the game. Concretely, a player receives the bonus points it
manages to collect three cards with one displaying a red pebble, the second one
a white one, and the third one a blue one. The pebbles must be on three distinct
cards.—
One CEO considered a slightly different change. His idea was to introduce a
second kind of pebble—
If your code base uses an untyped language such as Python, how does this proposed change break data representations and how might the lack of types affect your work?
If your code base uses a typed language such as Java, how are typed language constructs (un)helpful in this context?
Organize bonus.md as a two-part memo, clearly dedicating one part to each proposed change. Each part should address which data representation must change, which piece of functionality must change, and which component (folder) is affected. You may wish to include perma-links into your code base to justify the proposed changes.
Testing Task Create a test harness named xgames-resources. 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).—
*ActorsB, representing the actual players;
the (maximally useful) *Equations; and
a Game state.
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 —
CONSTRAINT A *ActorsB array contains at most 6 items. |
CONSTRAINT The names of any two different ActorBs must be distinct. |
|
- a JSON array of four elements: [ActorName, Policy, "a cheat", Cheat] |
- a JSON array of four elements: [ActorName, Policy, Exn, Count] |
|
INTERPRETATION Requests a test with a player acting badly. |
|
A player strategy [n, s, b, k] with k a Count 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. |
|
|
As of this milestone forward: |
A Score is a Natural less than 20. |
INTERPRETATION Score replaces Natural in 4 — |
|
The timeout per call to a player is set 1.0s. The time out for an entire test suite is set 120s.