Cluster Support
This article describes a future concept. It may still have some open issues and it was not decided, yet, whether to implement it in this way.
This article is going to collect some ideas, issues and possible approaches. The scenario is about splitting a Stendhal Server across multiple cluster nodes, so this article does not draw a strict line between Marauroa and Stendhal in the beginning.
Communication
The idea is to do the split on a zone level. So every cluster node is responsible for a number of zones. The client connects directly to the node responsible for its zone. This way we avoid a load balancing server as single point of failure and possible bottle neck.
Communication Client - Node
As the clients connect directly to the nodes, there needs to be some mechanism to tell a client to which node to connect.
- MessageS2CLoginACK
- will be extended to contain a session id, it needs to be encrypted similar to the password transmission
- MessageS2CForward
- The current node tells the client to disconnect and reconnect to the node specified in the message
- MessageC2SReconnect
- A quick way to login. Assuming that all nodes use the same key, the key exchange can be shortened. The selection of character step can be skipped, too, because the sessionid is bound to a character.
Communication Node - Node
Tasks
Authentication
When the client connects to a different cluster node, it has to authenticate it self. In order to support the inital web based login with a one time secret, the username/password cannot be used. There are two alternatives:
- The login secret can be part of MessageS2CForward, This approach has the advantage that code for the login is already there for the web based login.
- Use a sessionid that is generated on login and valid until the player logs off (or 5 minutes after he is last seen). This sessionid has to be maintained the server side and a new login message is required. On the positive side this sessionid can be used for reconnecting after the connection was lost.
Cross node zone change
Cross node zone change require the client to connect to another server:
Problems:
- Client may disappear during zone change
- Target zone server may be unavailable
- See Cluster_Support#Online.2FOffline_notifications online/offline section.
Cross node teleports
- Target allowed to teleport into?
Online/Offline notifications
Cross node actions
- /tellall
- /msg
- /who
- /where
Cross node admin actions
- /inspect
- /script DeepInspect.class