|
|
|
@ -0,0 +1,31 @@
|
|
|
|
|
## Step 1 – players and dialogs centralized, rooms distributed
|
|
|
|
|
All players are located on the same node. The client traffic is terminated on the same node
|
|
|
|
|
|
|
|
|
|
Rooms and their history could be located on other nodes.
|
|
|
|
|
|
|
|
|
|
The membership data:
|
|
|
|
|
- If the room and the player are located on the same node, it is on the same node and updated atomically.
|
|
|
|
|
- If the room and the player are located on different nodes, the membership data is split into two parts:
|
|
|
|
|
- The player-specific membership contains all data necessary to validate commands on the player's node side.
|
|
|
|
|
It is located on the player's node.
|
|
|
|
|
- The room-specific membership contains all data needed to respond to queries such as "list users".
|
|
|
|
|
It is located on the room's node.
|
|
|
|
|
|
|
|
|
|
Dialogs and their history are located on the same node, as all players.
|
|
|
|
|
|
|
|
|
|
The allocation is specified statically in the configuration file.
|
|
|
|
|
|
|
|
|
|
## Step 2 – players and dialogs distributed
|
|
|
|
|
Different players could be located on different nodes. The traffic is still terminated on the same node.
|
|
|
|
|
A client must connect to the node which hosts the player, otherwise the connection is terminated.
|
|
|
|
|
|
|
|
|
|
Dialogs are located on the first player's node. This depends on how the first player is decided,
|
|
|
|
|
which is implemented by sorting the players lexicographically.
|
|
|
|
|
|
|
|
|
|
The allocation is still specified statically in the configuration file.
|
|
|
|
|
|
|
|
|
|
## Step 3 – dynamic allocation and consensus
|
|
|
|
|
|
|
|
|
|
## Step 4 – all data replicated
|
|
|
|
|
|
|
|
|
|
## Step 5 – chat history fragmented
|