Teaching
6515 S '11
 
Projects
Presentations
 
Ingenious
Project 1
Project 2
Project 3
Project 4
Project 5
Project 6
Project 7
Project 8
Project 9
Project 10
Project 11
Project 12
Project 13

Project 12

Due date: 4/08 : 09:00AM

Objective: (1) to implement a distributed version of Ingenious to the given communication protocol and (2) to design a communication protocol for a different distributed version of Ingenious


Task 1: Implement a distributed version of Ingenious based on the following communication protocol:

  1. registration Remote clients have to sign up with the game server through a TCP registration process. Once the TCP connection is established, the client puts its proxy administrator in charge and the server connects to it via a proxy player connected to the client.
  2. ready to start When the server's administrator is ready to play, the server tells it to play one round of Ingenious with the remote players. The administrator signals each of the players that the game is about to start with a message that enumerates the names of all other players, i.e., each player in an N-player game receives a message with (N-1) names.
  3. take turn After the administrator has sent the "ready to start" message, it starts handing players the rights to play turns.
  4. information calls Once a player has completed a turn, the administrator sends out messages with two pieces of information: (1) the name of the player who just completed a turn and (2) the series of placements that the player executed. If the player was terminated for any reason, the series of placements is empty.
Players that send bad or out-of-turn messages are eliminated as if they had broken a rule. Similarly, the server should eliminate players that close their TCP connections or players that cannot complete a turn in 10 seconds or that do not send a registration message with 10 seconds of opening a TCP connection.

Your server may not assume that clients send well-formed XML messages. Clients that do so are immediately terminated.

Task 2: Design at most 15 external test cases for a test fest for remote turns. As you may have realized by now, the remote turn is the most critical piece of software in your distributed Ingenious. I have therefore decided to cut to the chase and run the test fest for remote turns only.

The input specifications describe the turn, the actions taken by the player, and the administrator's responses:

Input
TurnTestis
<turntest> 
    Turn 
    <administrator> AdminResponse ... </administrator>
    <actions> Action ... </actions>
</turntest>
Actionis:

 -- Placement
 -- Rerack? 
 -- RackPlease 
AdminResponseis:

 -- Tile of false 
 -- Boolean 
 -- Tiles  
All unspecified elements (e.g., Tiles or Rerack?) are understood as in the accompanying interactions diagram. The interleaving of "actions" and "responses" must satisfy the interaction diagrams for remote turns.

Your test harness creates a remote turn, runs through the specified actions, and interprets them as interactions with the remote turns. At the same time, I sets up a fake connection so that your remote turn can read the simulated responses from the administrator. The test harness records the turn's responses as XML:

Output
Resultsis
<results> 
  Result ... 
</results> 
Resultis:

 -- AdminResponse 
 -- [<bad reason=FreeShapedString />]
If the actions trigger a contract violation or any other error, record it with a bad record. If not the actions are in sync with the administrator's responses and satisfy the rules of Ingenious, the sequence of result responses is identical to the sequence of administrator responses.

Your test harnesses may assume that the XML inputs are well-formed (and better should produce well-formed XML outputs under all circumstances).

Task 3: Design and specify a communication protocol for implementing a distributed version of Ingenious. Use the following "software story" for this step:

Your company wishes to sell a framework for running software competitions. Your framework will run an Ingenious game server that includes an administrator component and between two and six player modules parameterized over remote strategies. Participants -- college clubs and high school AP classes--will write strategy components. Your players will communicate with these contributed strategies when the time comes to place a tile on the board or to decide on re-racking a players tiles. The participants will write the strategy components according to your protocol and interface specifications.
Your protocol specification should come with detailed interaction diagrams that cover all network-based communication scenarios and typed textual specifications of XML messages that must flow back and forth per scenario. Your Ingenious game should be based on the rules as established in project 11.

Deliverables: Your SVN directory must contain a subdirectory labeled "12" with the following pieces:

 Source/               ... source files for revised implementation ...
 Protocol/in*.xml      ... up to 15 input specifications for remote turn tests
 Protocol/ex*.xml      ... up to 15 corresponding, expected results
 xbuild                ... builds an executable ...
 xrun                  ... runs a test for the remote turn...
 Protocol/protocol.txt ... a rigorous specification of XML diagrams 
 Protocol/*.*          ... hand-drawn interaction diagrams ...
As in the past, the xrun script consumes test inputs from STDIN and produces test results to STDOUT.


last updated on Tue Apr 12 15:14:46 EDT 2011generated with Racket