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 |
| | | |
| ActorName n_1 | | |
|< ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | % send a name |
| | | % no reply |
| | | |
| new(n_1) rpp_1 | | |
|------->+ | | % create remote-proxy player |
| | | | |
| | | | |
. | . . |
. | . . |
. | . . |
| | | | |
| ActorName 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 ActorName 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:equations) | // | | |
| ----------------------------> | // | | |
| | (s):JSON // | | |
| | ~~~~~~~~~~~~ // ~~~> | | |
| | // | setup(s) | |
| | // | -------------> | |
| | // | void | |
| | void:JSON // | <============ | |
| void | <~~~~~~~~~~~ // ~~~~ | | |
| <============================ | // | | |
| | // | | |
| | // | | |
. . // . . |
. . // . . |
Playing Turns
|
server side proxies clients |
----------------------------------------------------------------------------------- |
|
referee // player (p_1) . . . player (p_n) |
| // | | |
| // | | % call only if game |
| // | | % is not finished |
| requestPebbleortrades( // | | % player receives: |
| ------------------------ // ---> | | % - turn state |
| TurnState) // | | |
| // | | |
| // | | |
| EitherPebbleOrExchang//es | | % requests a pebble |
| <======================= // === | | % or |
| // | | % an exchange of pebbles |
| // | | |
| // | | |
| // | | |
|--+ // | | |
. | // . . % if legal: |
. | // . . % referee modifies game state |
. | // . . % completes turn |
. | // . . % otherwise: |
. | // . . % kick player out |
.<-+ // . . % completes turn |
// |
IF LEGAL: // |
| requestCards(TurnState) // | | % player receives: |
| ------------------------ // ---> | | % - turn state |
| // | | % with a revised |
| // | | % wallet of pebbles |
| // | | |
| // | | |
| SequenceOf<Card> // | | |
| <========================//===== | | % purchases cards |
|--+ // | | |
. | // . . % if legal: |
. | // . . % referee modifies game state |
. | // . . % completes turn |
. | // . . % otherwise: |
. | // . . % kick player out |
.<-+ // . . % completes turn |
// |
|
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"
request-pebble-or-trades
request-cards
win
"void"
where
- False false |
INTERPRETATION Denotes a request for a pebble from the bank |
- *Rules |
INTERPRETATION Denotes a request for exchanges of pebbles in the order specified |
Note A server or a client may not assume that the JSON of remote calls is well-formed or valid.