►Software Development
▼Projects, Specifics
►13 — Implementing Remote Proxies
On this page:
The Remote Protocol for Santironi
7.1.0.8
    ← prev  up  next → 

13 — Implementing Remote Proxies

Due Monday, November 26, midnight

Delivery For this assignment, place all Santorini-specific code into a new Santorini/ sub-directory called Remote/.

Ideally you do not need to touch the existing code at all.

Place xclients, xserver and the santorini.rc server-tests/ and client-tests/ test directories into your 13/ folder.

Implementation Task We are now ready to turn our Santorini game framework into a server-client framework. A game server allows remote clients to sign up for a tournament. After waiting for a limited amount of time and signing up a certain minimal number of players, the server creates a tournament manager from the players and runs a complete tournament.

The description calls for a configuration system again. This time the server component reads the configuration and then runs tournament(s). A configuration looks like this:

  { "min players" : Natural,

    "port"        : Natural,

    "waiting for" : PositiveNumberOfSeconds,

    "repeat"      : 0or1

  }

The last field specifies whether the server runs a single tournament (0) or an indefinite series (1). In the latter case, it disconnects from all players and then accepts new ones; the server is under no obligation to accept connections while a tournament is in progress.

Note In the real world, the server would provide some other means for shutting down gracefully.

To implement the server-client framework, including a complete test bed, use the remote-proxy protocol. This calls for the creation of at least two proxies:

  • a remote-proxy for the server side components.

    This component exist on the client side and proxies the interaction between the player on one side and the tournament manager and referee on the other. By linking this proxy with the player implementation, it becomes straightforward to establish a TCP-based communication link between the client side and the server side at the appropriate level (individual games, best-of game series, tournament).

  • a remote-proxy player, implementing the player interface

    This proxy lives on the server side. It allows your server to create player "objects" that plug into your tournament manager and referee as if they were local pieces of software. Running a tournament proceeds as before.

For the precise protocol, see below.

Testing and Test Harness

Implement xserver, which spins up a server from configurations such as the following:

  { "min players" : 3,

    "port"        : 56789,

    "waiting for" : 10,

    "repeat"      : 0

  }

As always, xserver reads this configuration from STDIN.

Produce a test harness, named xclients, that runs the client side of a complete server-client tournament for a configuration. That is, the remote harness reads a tournament configuration file and connects the specified players to the a remote server. The configuration file for xclients is like the one in 11 — Implementing the Tournament Manager but also specifies the "ip" address and the "port" to which the client connects:

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

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

    "ip"        : String,

    "port"      : Number

  }

The "ip" string can be either in numeric or symbolic format. The "port" number will be between 50000 and 60000.

Copy your test from @tt{11/santorini.rc} to @tt{13/santorini.rc}.

Testing Task We will run all students’ client configurations on the staff’s xserver and the staff’s player configurations on your xserver. Failures in the first test run will expose weaknesses in your stress testing procedure; failures in the second run will expose weaknesses in your server.

Create two directories in 13/:

  • server-tests/, which is where you deploy the server configuration.

    Your server configuration called 1-in.json, should specify a minimum of 3 players, a 10s wait, and a non-repetitive tournament arrangement:

      { "min players" : 3,

        "port"        : TBD,

        "waiting for" : 10,

        "repeat"      : 0

      }

  • client-tests/, which is where you deploy the client configuration.

    Adapt and improve your 11/santorini.rc configuration to the new format. That is, use the same kind of three players to run a tournament. For now use "localhost" as the ip address. The expected output remains the same of course, unless it was wrong last time.

You will find out on Monday, 17 December 26 November, what the actual ip address and port will be for playing the distributed Santorini.

The Remote Protocol for Santironi

Clients sign up with the Santorini server by connecting via TCP and sending their player’s name. No other action is required. The server does not send any acknowledgment.

                server

                                  ||

                 |                ||          client a

                 |                ||            |

                 |<-----------------------------| tcp connect

                 |                ||            |

                 |                ||            |

                 |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| register:

                 |                ||            |   by name

                 |                ||            |

    [[ optional:

                 |                ||            |

                 |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| playing-as: ]]

                 |                ||            |   name

                 |                ||            |

message

   

format

   

interpretation

registration

   

Name

   

the name of this player

playing as

   

PA

   

a tuple with a modified name for this player

A PA is a JSON array with two elements: ["playing-as" Name].

The Santorini server sends an "other" message to the Client when a new "best of" series starts. Each new game starts with a "placement" message, which requests that the player picks a place for the next worker. After that, clients receive "take turn" messages until they either win or lose the game.

The server closes the TCP connection to any client that violates the protocol.

    remote proxy players                  clients

          .  .         ||            .   .     .

          .  .         ||            .   .     .

          .  .         ||            .   .     .

          .  .         ||            .   .     .

          |  |         ||            |   |     |

          |  |         ||            |   |     |

          |  |         ||            |   |     |

          |  |         ||            |   |     |

          |  |         ||            |   |     |

          |  |         ||            |   |     |

          |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| other

          |  |         ||            |   |     |

          .  .         ||            .   .     .

          .  .         ||            .   .     .

          |  |         ||            |   |     |

          |  |         ||            |   |     |

          |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| placement

          |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| return place

          |  |         ||            |   |     | [alternating, per policy]

          |  |         ||            |   |     |

          .  .         ||            .   .     .

          .  .         ||            .   .     .

          .  .         ||            .   .     .

          |  |         ||            |   |     |

          |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| take-turn

          |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| return action

          |  |         ||            |   |     | [alternating, per policy]

message

   

format

   

interpretation

   

response

other

   

Name

   

the name of the opponent for the next game

   

none

.

   

   

   

worker placement

   

Placement

   

the list of workers placed

   

place

   

Place

   

the next worker position for this player

   

.

   

   

   

take turn

   

Board

   

the current state of the board

   

action

   

Action

   

the action that this player wishes to take

   

A Placement is a JSON array of the following shape [WorkerPlace, ...]. It consists of maximally three WorkerPlaces.

A WorkerPlace is a JSON array: [Worker,Coordinate,Coordinate].

A Coordinate is a natural number between 0 and 5 (inclusive).

A Place is a JSON array: [Coordinate, Coordinate].

At the end of a tournament, the server sends to all live clients an "end of tournament" message, informing them of the outcome of games that at least one rule-abiding and protocol-abiding client finished.

     remote proxy players       clients

     .  .         ||            .   .     .

     .  .         ||            .   .     .

     .  .         ||            .   .     .

     |  |         ||            |   |     |

     |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| inform

    ======        ||            |         | of end of tournament

                  ||            |   |    ===

message

   

format

   

interpretation

   

response

informing players

   

Results

   

the results of a tournament

   

none

A Results is a JSON array of EncounterOutcomes.

    ← prev  up  next →