Remote Interactions
The interaction between remote player components and the remote admin framework is governed by the set of following interaction diagrams. Straight line denote logical calls, squiggly lines remote messages or calls. Unless otherwise noted, the diagrams use the same conventions as Logical Interactions.
Connecting to the Server
server client (c_1) ... client (c_i) |
| | | |
|< ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | % tcp connect |
| | | |
| JName n_1 | | |
|< ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | % send a name |
| | | % no reply |
| | | |
| new(n_1) rpp_1 | | |
|------->+ | | % create remote-proxy player |
| | | | |
| | | | |
. | . . |
. | . . |
. | . . |
| | | | |
| JName n_i | | |
|< ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
| | | | |
| | | | |
| new(n_i) rpp_i | | |
|-------------------->+ | | |
| | | | | |
| | | | | |
| | | | | |
| |
| |
| |
| |
| new(rpp_1,..., rpp_n) referee % create referee to run a game |
|-------------------------------------+ % with the remote proxies |
| | |
| | |
| | |
* The server expects to receive a JName within 3s |
after the connection is established. |
The server accepts TCP connections and represents each as a remote player once the client has submitted a name. In real-world settings, the server may put players that arrive after the waiting period into a "waiting room." Once a sufficient number of players have connected to the server and the waiting period is over, the server signs up these players for a game with a referee.
The order in which the server accepts the players determines their age. The first player accepted is the oldest, the last one is the youngest.
Note Our tests will guarantee that distinct clients sign up with distinct names.
Sequence Diagrams The // indicate the “language-machine” boundary between the software components, and the squiggly lines are suggestive of RPCs.
Starting a Game
|
server side many client sides (*) |
----------------------------------------------------------------------------------- |
referee proxy_player (p_*) // proxy_ref (p_*) player p_* |
| | // | | |
| | // | | |
| setup(s:State,t:bagOTiles) | // | | |
| ----------------------------> | // | | |
| | (s,t):JSON // | | |
| | ~~~~~~~~~~~~ // ~~~> | | |
| | // | setup(s,t) | |
| | // | -------------> | |
| | // | void | |
| | void:JSON // | <============ | |
| void | <~~~~~~~~~~~ // ~~~~ | | |
| <============================ | // | | |
| | // | | |
| | // | | |
. . // . . |
. . // . . |
Playing Turns
|
server side proxies clients |
----------------------------------------------------------------------------------- |
referee // player (p_1) . . . player (p_n) |
| // | | |
| take-turn(PublicState) // | | |
| ---------------------------- ~~~ // ~~~ ---> -> | | |
// |
ACTION 1: // |
| PASS // | | |
| <=========================== ~~~ // ~~~ === = | | |
| // | | |
// |
|
ACTION 2: // |
| REPLACE // | | |
| <=========================== ~~~ // ~~~ === = | | |
| // | | |
|--+ // | | |
. | // . . |
. | // . . |
. | // . . |
.<-+ // . . |
// |
|
ACTION 3: // |
| EXTENSION // | | |
| <============================ ~~ // ~~~ === = | | |
| // | | |
|--+ // | | |
. | // . . |
. | // . . |
. | // . . |
. | // . . |
. | // . . |
.<-+ // . . |
|
|
IF: the player asks for REPLACE or EXTENSIONS, the referee completes the turn: |
|
| // | | |
| new-tiles(bagOfTiles) // | | |
| -----------------------------> ~ // ~~~~ === > | | |
// | | |
Ending a Game
server side proxies clients |
----------------------------------------------------------------------------------- |
referee player (p_1) . . . player (p_n) |
| // | | |
| // | | |
| win(Boolean) // | | |
| ---------------- ~~~~ // ~~~~ ------> | | |
| // | | |
. // . . |
. // . . |
. // . . |
. // . . |
| win(Boolean) // | | |
| ---------------- ~~~~ // ~~~~ ------------------------> | |
| // | | |
| // | | |
Method Call Formats
The logical protocol comprises the three function calls and all we have to do is describe the JSON format so that logical calls can be realized as remote calls between components in different languages.
Note
setup
"void"
take-turn
new-tiles
"void"
win
Boolean
"void"
where
|
A JChoice is one of: "pass", "replace", or a JPlacements. |
INTERPRETATION Denotes the request that a player may send to the referee. |
Note A server or a client may not assume that the JSON of remote calls is well-formed or valid.