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

• jgroups looks good with a nice API, but the .jar file is huge (3 MB).

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

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?

Cross node actions

• /tellall
• /msg
• /who
• /where

Cross node admin actions

• /inspect
• /script DeepInspect.class

See also

• http://www.jgroups.org/
• http://gamedev.stackexchange.com/q/5956/450#5967