►Software Development
▼Projects, Specifics
•11 — Implementing the Tournament Manager
7.1.0.8
    ← prev  up  next → 

11 — Implementing the Tournament Manager

Due Monday, November 05, midnight

Delivery For this assignment, you will still place the design documents into the Design/ folder and Santorini-specific code into the appropriate Santorini/ sub-directory.

Place xrun and the santorini.rc test directory into your 11/ folder.

Optionally your 11/ folder may contain a Makefile. If so, we will run make to build your executables. The make process may install libraries but if it downloads all of Al Gore’s Internet, we may preempt it.

Design Task The time has come to plan for the last step: running remote tournaments. That is, our Santorini company will run a Santorini tournament manager on one machine and client computers will run AI players and connect to the server via JSON messages over TCP.

Design a remote protocol for a Santorini tournament. A protocol consists of a (series of) sequence diagram(s)—like those in 4/given-server-spread.md—plus an explanation of all the JSON messages that cross from a client to the server and vice versa. You may wish to sketch a sequence diagram per phase of a tournament. As for the JSON messages, you may wish to borrow the formats from our past test specifications. Don’t forget to explain the meaning of each message.

Optional Design an observer interface for the tournament manager.

Implementation Task Implement a tournament manager, including a configuration component for starting up a Santorini tournament.

A tournament manager is your first complete software system: it is extensible (we can configure it with different kinds of players and observers); it needs to deal with faulty components (bad players); it needs to shut down gracefully, regardless of what happens over the course of execution.

The tournament manager comes with a configuration component that reads "programs" in a configuration "language" and then runs a complete round-robin, every-player-against-every-other-player sequence of meet-ups. For each meet-up, a referee supervises a best-of-3 series of games. If something goes wrong during a meet-up, the referee informs the tournament manager, which must implement a policy for failures.

Configuration The tournament manager reads a configuration file and configures the tournament according to the instructions in this file.

Note For test-fest purposes, your tournament manager reads the configuration from STDIN. ~~ In real systems, the path for the configuration file is specified as a command-line argument or is specified as a default place in the file system.

The contents of the configuration file is a single JSON object of the following shape:

  { "players"   : [[Kind, Name, PathString], ..., [Kind, Name, PathString]],

    "observers" : [[Name, PathString], ..., [Name, PathString]]}

that is, a hash table with two keys—"players" and "observers"—each mapped to an array of player and observer specification, respectively. The specifications have the following meaning:

  • Kind is one of:

    • "good", meaning a player that is intended to be well-behaved;

    • "breaker", referring to a player that terminates in a timely manner but misbehaves;

    • "infinite", denoting a player that goes into an infinite loop.

    If you haven’t implemented the three kinds of players for 9 — Implementing the Referee, do so now.

  • Name is a JSON String; and

  • PathString is a Linux Path to a dynamically loadable component that implements the respective player or observer.

Policy on Names If the tournament manager discovers that several players with the same name are to participate in a tournament, it picks a unique name for all but one of the players and informs these players of the chosen names.

Policy on Broken Players When a tournament manager is informed that a player misbehaved, it acts as follows:

  • The player is removed from all future encounters; there are no second chances.

  • All past meet-ups involving the player are counted as won by the opponent.

  • If a player breaks after winning past games due to its opponents' breakage, the game is eliminated from the tournament evaluation.

The End When the tournament is over, the tournament manager delivers two pieces of information:

  • The first is a list of names of players that misbehaved in any way. They are listed in the order of failure.

  • The second lists all completed games where each piece of game information lists the winner’s and the loser’s name. The games are listed in the order of "first plays against rest, second plays against rest, etc."

Test Harness Since we do not have a complete software system yet, we need a test harness. Produce a test harness, named xrun, that runs a complete tournament for one configuration, piped in from STDIN. Its output, the result of calling the tournament manager, is rendered to STDOUT as a JSON array of two arrays, the second of which contains one array per game.

Testing Task Develop a single system-level test to be used with your test harness, i.e., the pair of files: 1-in.json (for a configuration object) and 1-out.json (for the result). The configuration must specify three players: one that behaves well, one that goes into an infinite loop during placements, and one that goes into an infinite loop during a turn; it does not specify any observers.

Note You may wish to create additional configuration files to stress your tournament manager.

    ← prev  up  next →