Design and develop the Cluster Server, which hosts the actual game.

[Makosai]

The Cluster Server is hosts the game and handles most of the networking functionality.

Accepting connections

• The first thing that should be done is a connection to the master server should be established. Connect cluster server to master server #24
• In parallel with connecting to the master server, the cluster server should accept connections from clients. If the server has reached the max connections, it should send a Connection::Disconnect back to the client with a DisconnectReason::Full. Handle client connections in parallel with the master server connection #25

Handling connections

• When a connection is created, a ClusterClient should hold this connection. It should be in a tokio spawn. It may be more beneficial to figure out a way to do it in a thread so the work doesn't have to be scheduled. But a spawn is fine as a start. Handle client connections in parallel with the master server connection #25

Registering this cluster

• Send a ClusterSetup::Init to the Master Server with the length + version number as a string and the length + key name as a string as well. Register the cluster server with the master server #26
• Send a ClusterSetup::AnswerSecret when receiving a ClusterSetup::Init from the Master Server. It should send back the decrypted passphrase. No length is required because it should be a fixed length anyways (20 characters). IP, port, max connections, and length + name also required. Register the cluster server with the master server #26
• If the cluster receives the AnswerSecret command back, that means its a success. Otherwise it fails and the server should not try again. Maintain a connection with the Master Server afterwards if successful. Register the cluster server with the master server #26
• If successful, it should try reconnecting to the Master Server on a lost connection. Register the cluster server with the master server #26

Get other servers

• Request a list of clusters from the master server with Connection::RequestClusters and then Connection::RefreshClusters every 3 seconds. Get a list of other servers for the cluster server #27
• Run Connection::RequestClusters again if the version number sent for the list of clusters doesn't match. Meaning the list was updated recently. Get a list of other servers for the cluster server #27

Authentication

• This should only work on official servers. The user should encrypt their password with a pubkey from the pub key that comes with the game. It should encrypt a very small piece of data with their pub key version number. If it matches, the client encrypt their credentials and send it to the server. Then the server checks it. These credentials can be a username and password or an OpenID token. Handle authentication on the cluster server #28

• TODO what to do afterwards? How to store the data, hash, refresh, what number to start ids at? 2FA when using username login? And more common sense changes. Handle authentication on the cluster server #28

Extra commands

Social commands

• Low bandwidth users can opt to not receive any messages. This is done by indexing guild, local, direct, and party message IDs. Each of the message types will try to find it in their respective HashMap first.

• Global messages should loop through all users on the server and send them a message then send that message to all other servers to relay it as well. This is only for admins. It's for system messages.

• Guild messages should loop through all users on the server that are in a guild. Then it should send it to all servers and do the same. This means there has to be a struct that contains guilds. When the last guild member logs off, the guild should vanish. Any guild member that joins or leaves the server should be added or removed from this guild struct. And any message going through it should send to all of the IDs that match in the indexed guild HashMap.

• Local messages should loop through all nearby players if they have it on. No need to track the players. The client should send the command with the message and then the server will find all of the nearby players on their message. So the only time to check would be when a message is sent.

• Direct messages should send it directly to a user with an ID. But it will check if they've blocked, friends only, dnd, etc. Various statuses for the recipient before delivering the message. If there's anything blocking this, send the command back with a 0 for false. If there's nothing blocking it, send the command back with a 1 for success.

• Party messages sends a message to all users in their party. A party is tracked with an index as well.

Movement commands

• User sends a velocity and a new position. Server checks if it's valid. If it checks out, send the command back. If it's wayyyy off, then send an updated position back with the command. If it's off by a little bit, warn them then try to snap them to the correct position more often until their connection stabilizes. This should be represented as a "tolerance_level".

Action commands

• Skills, inventory, etc... These are handled on the engine using gdext. When a client performs an action, it sends that action to the server to try and replicate. So skills will cast client-side but will validate it server-side and send it to all nearby users too. Inventory will open a cached version of the inventory but will check the version number in case it was edited externally by a companion app. if it was, then it would reload it, fading in/out the missing item. This is a bit too specific as it's only specific to Reia's use case. But it shows an example of how those two would work. And it could come in handy for someone else.