Project Scope
The complete implementation foresees multi-domains, account administration, zone-groups, NPCs and other simulation handling, but you have to start somewhere and that is from the ground up. In this case that means that we have to build the most basic components first to make the whole work.
The complete implementation foresees multi-domains, account administration, zone-groups, NPCs and other simulation handling, but you have to start somewhere and that is from the ground up. In this case that means that we have to build the most basic components first to make the whole work.
Our first task here is to build a multi-server structure. There are two aspects to it, start using mnesia for self-replicating persistent data across the nodes and the next part is a sort of chat room server across the nodes the facilitate message passing among processes that have common interests, like for example guild chat, which obviously needs to function for members no matter on which zone and server they play or you could have your users connect to server X, zone Mainland, but start the NPCs for that zone on server Y, given that you can connect your servers at 1Gb speed, but might only have a 20Mb pipeline, speed is not the issue. This way you could also connect on server Y a service that records all the chat in a certain channel to scan for example for spammers and foul language. The mnesia and multi server chat is already done, next we need to do a sort of internal logon procedure and create an action plug in for the internal player/NPC proxies. The final implementation will open a client TCP process for every client connected, but there is going to be ALWAYS an internal client proxy, which will stay alive, even when the TCP client disconnects, so the proxy is part of the simulation implementing behavior through the action plug in, while the TCP client is just the external connector. The client proxy is going to be a fixed program implementing basic behavior regarding how to plug into the chat server, but we may want to be able to put the player in control of his char or even a "mind-controlled" NPC or disable user input for a while, when a small script runs, so the actual character behavior needs to be handled by a changeable action plug in. So the action plug in will determine how to handle requests, a user might send a request to move or chat to the proxy, the proxy sends thedata to the action handler which might determine, that the user can move or maybe he wants to chat, but given abusive behavior the administrator decided to mute this user for some time and the chat request is discarded. We can see that user handling is so much easier, but how do we start a whole zone ??
Zone handling
Let's give some initial thoughts on zones:
* Zones can be shared across servers with our multi chat room servers
* Some servers should be dedicated to user connections and not run NPCs or Sim events, they will be busy with filtering/handling requests and optimizing bandwidth usage
* If we assign zones to servers, how to handle load balancing ? Maybe assign fallback servers ?
* How to handle instances ? This needs to be coded right into the core structure
Thought: any zone is an instance, zones are linked instances, instances are stand-alone
* How to handle weather and global economic events ?
* How to handle NPCs that walk across regions ?
* How to handle flocks and armies ?
* When a node's down, where do we put his processes without interrupting?
The chat rooms stay the same, the sim needs to be restarted on a different node
It looks like we need a global resource manager and do some cluster configuration. So the cluster master needs to do some load balancing, know the optimal configs, backup configs and if else fails improvise. He will require to know number of running processes on each node, which ones are connection nodes (for users), which ones are sim nodes (for sim and/or NPCs), the main database node that writes to disk should not run anything and probably the master node, it is thinkable that the subscription master node runs password authentication on local mnesia tables which do not replicate on a separate and isolated node.
Next tasks on the To-Do List:
* Create an action plug in template [easy]
* Internal user registration (to avoid same user on several nodes or processes) [easy]
* Cluster behavior [medium]
* Zone Simulation Manager [medium]
* TPC/IP server with authentication [medium] + protocol converter [medium]
* TCP/IP test client [medium]
* Apocalyx integration [medium]
* Master node [hard]
* NPC scripts [hard]
* Subscription Server [hard]
* Interrealm connector [hard]
I will go through the list be degree of difficulty (which also reflects time required to do it).
Until next time,
Sunweaver
Let's give some initial thoughts on zones:
* Zones can be shared across servers with our multi chat room servers
* Some servers should be dedicated to user connections and not run NPCs or Sim events, they will be busy with filtering/handling requests and optimizing bandwidth usage
* If we assign zones to servers, how to handle load balancing ? Maybe assign fallback servers ?
* How to handle instances ? This needs to be coded right into the core structure
Thought: any zone is an instance, zones are linked instances, instances are stand-alone
* How to handle weather and global economic events ?
* How to handle NPCs that walk across regions ?
* How to handle flocks and armies ?
* When a node's down, where do we put his processes without interrupting?
The chat rooms stay the same, the sim needs to be restarted on a different node
It looks like we need a global resource manager and do some cluster configuration. So the cluster master needs to do some load balancing, know the optimal configs, backup configs and if else fails improvise. He will require to know number of running processes on each node, which ones are connection nodes (for users), which ones are sim nodes (for sim and/or NPCs), the main database node that writes to disk should not run anything and probably the master node, it is thinkable that the subscription master node runs password authentication on local mnesia tables which do not replicate on a separate and isolated node.
Next tasks on the To-Do List:
* Create an action plug in template [easy]
* Internal user registration (to avoid same user on several nodes or processes) [easy]
* Cluster behavior [medium]
* Zone Simulation Manager [medium]
* TPC/IP server with authentication [medium] + protocol converter [medium]
* TCP/IP test client [medium]
* Apocalyx integration [medium]
* Master node [hard]
* NPC scripts [hard]
* Subscription Server [hard]
* Interrealm connector [hard]
I will go through the list be degree of difficulty (which also reflects time required to do it).
Until next time,
Sunweaver
No comments:
Post a Comment