►Software Development
▼—The Project
•10 — Remoting
7.8.0.1
    ← prev  up  next → 

10 — Remoting

Due Thursday, 21 November 2019, midnight Monday, 25 November, midnight

Delivery Place the product of this week’s project steps into your repo as follows:

Design Task Design the server and client start-up phase. Use a sequence diagram to describe the sequence of actions and events in this phase. If you must change any code, describe the changes via pointers to git commits and their messages.

Programming Task Implement the server-and-client architecture for Tsuro.com. Do not disturb the existing business logic. If you must, describe the changes via pointers to git commits and their messages in the design task.

The five function calls from the administrative side to the player side must use the following JSON representations:

call

   

arguments

   

result

playing-as

   

["playing-as", [Color]]

   

"void"

others

   

["others", [Color, ..., Color]]

   

"void"

initial

   

["initial", initial]

   

action

take-turn

   

["take-turn", intermediate]

   

tile-pat

end-of-tournament

   

["end-of-tournament", [Boolean]]

   

"void"

true means the player is a winner, false the player is a loser. where

initial

     

=

     

[simple, tile-index, tile-index, tile-index]

simple

     

=

     

[initial-place, ..., initial-place]

intermediate

     

=

     

[complex, tile-index, tile-index]

complex

     

=

     

[state-pat, ..., state-pat]

action

     

=

     

[tile-pat, port, index, index]

Recall that the sequence diagrams in Tsuro, A Local Protocol describe the sequence of all possible interactions.

The server waits until at least six 20 (or more) players have signed up and for a minimum of at most one minute. When either of these conditions is satisfied, the server hands the players to the administrator to run a complete tournament.

The client must consume the ip address and the server port on the command line. A good name for such a client is xclient though this gets a bit too close to xclients for the test harness.

Testing Task Develop a test harness named xserver that starts up your server. The harness should consume the port on which it communicates from the command line; the default is 45678. It also consumes an input configuration for a test from STDIN. With this information it may construct a complete output for a test run.

Also develop a test harness named xclients that reads a test input from STDIN in the shape specified in from 9 — Cleaning Up and starts up as many clients as specified there, in order. The harness must ensure that a client has connected to an administrator before it starts the next one. If this task demands changes to existing code, describe the changes with git commits and messages in the design document.

Response to Peter’s astute analysis on piazza.

Addendum xclients is expected to connect the spawned players to the IP address at the given port given on the command line; if no command-line arguments are specified, xclients connects to LOCALHOST at 45678.

As for the possible results, recall the major design question of this course:

which components knows what.

Hence it must be xserver that delivers the result of the tournament (as requested above), and xclient(s) may optionally inform its “owner” of the information sent via end-of-tournament.

    ← prev  up  next →