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_n) |
| | | |
|< ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | % tcp connect |
| | | |
| Name | | |
|< ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | % send a name |
| | | % no reply |
| | | |
| new() rpp_1 | | |
|------->+ | | % create remote-proxy player |
| | | | |
| | | | |
. | . . |
. | . . |
. | . . |
| | | | |
| Name | | |
|< ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
| | | | |
| | | | |
| new() rpp_n | | |
|-------------------->+ | | |
| | | | | |
| | | | | |
| | | | | |
| |
| |
| |
| |
| new(rpp_1,..., rpp_n) referee % create referee to run a game |
|-------------------------------------+ % with the remote proxies |
| | |
| | |
| | |
* The server expects to receive a Name within 2s |
3s [~a SIGNUP]s 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 There is no 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
referee proxy_player (p_1) // proxy_ref (p_1) player p_1 |
| | // | | |
| | // | | |
| setup(s:State,c:Coordinate) | // | | |
| ----------------------------> | // | | |
| | (s,c):JSON // | | |
| | ~~~~~~~~~~~~ // ~~~> | | |
| | // | setup(s,c) | |
| | // | -------------> | |
| | // | void | |
| | void:JSON // | <============ | |
| void | <~~~~~~~~~~~ // ~~~~ | | |
| <============================ | // | | |
| | // | | |
| | // | | |
. . // . . |
. . // . . |
Playing Turns
|
referee // player (p_1) . . . player (p_n) |
| // | | |
| takeTurn(State) // | | % player receives: |
| -------------------------- ~~~ // ~~~ ---> | | % - current state |
// |
action 1: // |
| PASS // | | |
| <========================= ~~~ // ~~~ === | | % pass, no action |
| // | | |
// |
action 2: // |
| Choice // | | % slide, rotate, insert, move |
+-- | <========================= ~~~ // ~~~ === | | |
| | // | | % if legal: |
| | // | | % referee modifies truth (game state) |
| | // | | % otherwise: |
| | // | | % kick player out |
+-> | // | | |
| // | | |
| // | | |
|
|
|
once the player reaches the assigned treasures-target with this turn: |
|
| // | | |
| setup(NONE,Coordinate) // | | % no state; just a reminder |
| -------------------------- ~~~- // ~~~ --> | | % to go home (and its coord) |
. // . . |
. // . . % repeat according to age |
. // . . % with well-behaved players |
| takeTurn(State) // | | |
| -------------------------- ~~~ // ~~~ --------------------> | |
| ....... // | | |
| <========================= ~~~ // ~~~ ===================== | |
| // | | |
. // . . |
. // . . % repeat until the referee |
. // . . % terminates the game |
|
|
|
Ending a Game
|
referee player (p_1) . . . player (p_n) |
| // | | |
| // | | |
| win(Boolean) // | | |
| ---------------- ~~~~ // ~~~~ ------> | | % true means "winner" |
| // | | % false means "loser" |
. // . . |
. // . . % repeat according to age |
. // . . % with well-behaved players |
. // . . |
| 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
win
Boolean
"void"
where F/State is either false or State.
Note A server or a client may not assume that the JSON of remote calls is well-formed or valid.