Remote Interactions
The interaction between Racket player components and the Racket 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 |
| | | |
| PlayerName | | * |
|< ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | no reply |
| | | |
| | | |
| new() rpp_1 | | |
|------->+ | | |
| | | | |
| | | | |
. | . . |
. | . . |
. | . . |
|< ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | tcp connect |
| | | | |
| PlayerName | | * |
|< ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | no reply |
| | | | |
| | | | |
| new() rpp_n | | |
|-------------------->+ | | |
| | | | | |
| | | | | |
| | | | | |
| |
| |
| |
| |
| new(rpp_1,..., rpp_n) manager |
|-------------------------------------+ |
| | |
| | |
| | |
|
* The PlayerName is a JSON string that consist of at least 1 and at most 50 alphabetical ASCII chars. |
* The server expects to receive a name 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 tournament with the manager and asks it to run a complete tournament.
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. If the administrative framework employs an observer, the server should make the names unique by adding suffixes.
Starting a Tournament
|
manager <-------------- ~~~~ -- player (p_1) . . . player (p_n) |
| | | % for n <= MAX_PLAYERS |
| | | |
| | | |
| | | |
| start(Boolean) | | % true means the tournament |
| ------------------- ~~~~ ----> | | % is about to start |
| | | |
| Map | | |
| <================== ~~~ ===== | | submit game map, m will pick one |
. . . |
. . . |
. . . |
| start(Boolean) | | |
| ------------------- ~~~~ ----------------------> | |
| | | |
| Map | | |
| <================= ~~~~ ======================== | submit game map, m will pick one |
Terminating a Tournament
|
manager player (p_1) . . . player (p_n) |
| | | |
| | | |
| end(Boolean) | | |
| ----------------- ~~~~ ------> | | % true means "winner" |
| | | % false means "loser" |
. . . |
. . . |
. . . |
. . . |
| end(Boolean) | | |
| ----------------- ~~~~ ------------------------> | |
| | | |
| | | |
Starting a Game
|
referee player (p_1) . . . player (p_n) |
| | | |
| | | |
| setup(map,r,cards) | | % the map for this game |
| -------------------------- ~~~~ ---> | | % the number of rails |
| | | |
| pick(destinations[]) | | % given these 5 destinations, |
| -------------------------- ~~~~ ---> | | % where does the player |
| destinations[] | | % want to go (return 3) |
| <========================= ~~~~ ==== | | |
| | | |
. . . |
. . . % repeat down age |
. . . |
| | | |
| setup(map,n,r) | | |
| -------------------------- ~~~~ ---------------------> | |
| <========================= ~~~~ ====================== | |
| | | |
| pick(destinations[]) | | |
| -------------------------- ~~~~ ---> | | |
| destinations[] | | |
| <========================= ~~~~ ====================== | |
| | | |
|
|
Playing Turns
|
referee player (p_1) . . . player (p_n) |
| | | |
| play(state) | | % player receives: |
| -------------------------- ~~~ ---> | | % - current state |
|
action 1: |
| more_cards | | |
| <========================= ~~~ === | | % request cards |
| more(cards[]) | | |
| -------------------------- ~~~ ---> | | % if there are cards |
| | | |
| | | % no cards available |
. . . |
action 2: |
| Connection | | % acquire connection |
+-- | <========================= ~~~ === | | |
| . . . % if legal: |
| . . . % referee modifies game state |
+-> . . . % otherwise: |
. . . % kick player out |
. . . |
| play(state) | | |
| -------------------------- ~~~ ---------------------> | |
| action | | |
| <========================= ~~~ ====================== | |
| | | |
. . . |
. . . % repeat until a player |
. . . % has less than 3 rails |
. . . % or all remaining |
. . . % players have chosen |
. . . % to ask for more cards |
. . . % when there are none |
. . . |
| | | % one last round |
| play(state) | | |
| -------------------------- ~~~ ---> | | |
| action | | |
| <========================= ~~~ === | | |
. . . |
. . . |
. . . |
. . . |
| play(state) | | |
| -------------------------- ~~~ ---------------------> | |
| action | | |
| <========================= ~~~ ====================== | |
| | | |
. . . |
. . . |
Ending a Game
|
referee player (p_1) . . . player (p_n) |
| | | |
| | | |
| win(Boolean) | | |
| ----------------- ~~~~ ------> | | % true means "winner" |
| | | % false means "loser" |
. . . |
. . . |
. . . |
. . . |
| win(Boolean) | | |
| ----------------- ~~~~ ------------------------> | |
| | | |
| | | |
Method Call Formats
The logical protocol comprises the six 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.
[ String, [Argument, ...] ] |
Name
Note
start
Boolean
setup
"void"
pick
play
more
"void"
win
Boolean
"void"
end
Boolean
"void"
Destination+ is [Destination, ..., Destination] |
Note A server or a client may not assume that the JSON of remote calls is well-formed or valid.