First of all. Since MMOPRG have a very high amount of growth, server scalability is a big issue.
Single process server, doesn?t scale well, since there is only one process, and no other fork or thread, this kind of approach, will naver take advantage of any load distribution technique. SMP requieres multi-threaded applications, and GRID or Clustering, needs multi tier server.
The dificulty to achive this goal, isn?t so hard. A good development plan, roadmap, coding conventions and the use a hand picked selection of OpenSource libraries, can make the server development fast and using quality assurance,
So, the following document, show the structure, and funtionality to achive a multi tier, multi threaded server.
The goal is to have a discussion to enrich and qualify is, with proper guidance, commitmnet, and collaboration, this could be done. After the Server Structure Proposal, is polished, the specific implementation model of each part, should be disccused. After this, we shoudl have a server concept, and requirements to develop at least, our 3 to 5 first version of the server. using mos of the current server development.
The conceptual design of the architecture:
The server is organized it 3 tiers, a login tier, a world tier, and the client. Also, helping the login and world tier, is a database tier and to coodinate all efforts, is a Cluster Controller.
The general description of the information flow is:
1.Client request a login to the cluster controller.
2.Cluster Controller points the user to the login server available.
3.Login is done.
4.Login server ask for the list of available world from the Cluster Controller.
5.User select World to login
6.Login server ask for available World server to Cluster Controller.
7.Login gives auth token to ClusterController wich routes it to the World Server.
8.User get auth token and world server information.
9.User gets to world server.
The Login Server and the World server, can communitate independantly from the Cluster Controller with the client. So far, we have 3 tier. Each Tier could be at separate server or even separate fisical locations.
The Cluster Controller.
The proposed modular structure of the clustercontroller is:
Cluster controller is the single point of control. Redundancy could be obtained with other technology as Linux Virtual Server, or simple DNS round robin (Dns most simple balancing method).
The server setups 3 TCP ports, one for Authentification requests, one for World server availability reports and one for Login Server availability reports.
Each world server register himself to the Cluster Controller, so the Cluster Controller, builds it?s list of available worlds and servers, the same happens with Login servers.
The cluster controllers, has a simple less conection algorith to make the load balance between login and world servers.
Hardware requirements the cluster controller are very low, since only implements lists of availability and, status verification routine and communitacion routines. A single microprocessor CPU can handle the load of the cluster controller.
The storage farm
The storage farm, is maybe the simplest part of all:
It present us with the network interface to communicate world and login servers with the database server. A Data base Abstraction layer is suggested to achive more flexibility.
Login Server
The modular concept of a Login Server is:
Provides the authentication interface to respond to login and map seleccion requests from cleints.
Also a client update infrastucture is built at the login server, to keep separated the client infraestructure to the server infrastructure, this module implements all the methods to update the information at the client.
The world/map list are the interfaces to manage the list of server and the cluster interface.
The cluster interface are the methods to report to the cluster controller.
Storage interface are the methods to access the data.
For a threaded model, each login request requieres a thread. So a single server could use SMP machines, and multiple server can be used.
The World/Server
The conceptual model of the world/map server
The word server, is the most dificult and complex element of the sistem.
A world is composed by various maps, and maps can lead to other maps or worlds.
Each map has it?s own NPC, objects and players, so each map must have it owns thread.
To make NPC more independant, and to make a less single process, each kind of monster, from a world, must have it?s own thread. This thread is called the monster fatory, wich is on charge of spawning NPC of it?s kind, at the desired map of the world.
Players develop it?s own thread, so when a player changes from map the player object controlling the thread could be passed by to the map as reference.
The object factory, provides object references, to maps, players and NPC
So, using a model, of threaded maps, threaded users, and threaded NPC, a higly SMP machine scalability could be reached.
About the technology to use.
C++ is the choice for the programming language.
For the cluster controller, login server and world/login server the ICE library for distributed programming is a good choice, since is open source, developed to be fast, has a pretty good documentation and provides all the interfaces to create a distributed environment and network communications used among world, login, cluster controller and client.
More information: http://www.zeroc.com/ice.html
For the storage server, JAVA is the preferred plataform, since it as a pretty good load balancing tool for almost any kind of databases named cluster-jdbc http://c-jdbc.objectweb.org/, and also ICE provides java bindings, so the environment is set.
N.B.
About my typing, read pajarico signature...[/url]
we are quite off topic, based on your experience, what is missing? architecture is ok? What else?