Server Architecture Proposal

Content and general development discussion, including maps, quests, and server code from the development team.
Post Reply
User avatar
criptos
Peon
Peon
Posts: 75
Joined: 20 Sep 2005, 17:00
Contact:

Server Architecture Proposal

Post by criptos » 16 Oct 2005, 02:07

Server structure proposal.

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.
Image

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:
Image

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:
Image

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:
Image

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
Image


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]
May the Source be With You
User avatar
biggeruniverse
Peon
Peon
Posts: 42
Joined: 17 Sep 2005, 05:33

Post by biggeruniverse » 16 Oct 2005, 02:19

Wow. That looks really familiar (http://jerome.biggeruniverse.com)...

EDIT: You know, it's hard to tell what's a link on this forum. Can someone with admin access fix that?
We are on the outer reaches of someone else's universe
User avatar
criptos
Peon
Peon
Posts: 75
Joined: 20 Sep 2005, 17:00
Contact:

JeromeProyect.

Post by criptos » 16 Oct 2005, 20:57

BigUniverse... I?ve been reading the site you mention.

The structure, may resamble, but, I been unable to found an architecture development, and again, seems hard to do a proyect managment without proper requirement, that is want I want to achieve here.

Also, for what I look, jerome also develops communication layers and so on...

I really think that using ICE+SDL, the server could be done within a year, a first version, within 3 or 4 monts...
May the Source be With You
User avatar
biggeruniverse
Peon
Peon
Posts: 42
Joined: 17 Sep 2005, 05:33

Post by biggeruniverse » 16 Oct 2005, 21:09

The idea of JEROME is to abstract all network/node related architecture away from the developer. It also handles dynamic node creation and loss, as any good cluster should.

In terms of development it works much list Servlets/EJB development, where you write and implementation of an interface, and tell the server to load your implementation when messages arrive.

In terms of implementation, it's very similar to what criptos has outlined, but a year ahead in terms of implementation. Also, since it's pure Java, nodes can be run on any kind of hardware or OS that has a JVM (no porting required).

JEROME has been brought up before, and as always, it's up to development team which direction to go for tmwserv.
We are on the outer reaches of someone else's universe
User avatar
criptos
Peon
Peon
Posts: 75
Joined: 20 Sep 2005, 17:00
Contact:

Post by criptos » 16 Oct 2005, 22:43

URL for design and architecture documentation of jerome?...


Any way :) we are quite off topic, based on your experience, what is missing? architecture is ok? What else?
May the Source be With You
User avatar
biggeruniverse
Peon
Peon
Posts: 42
Joined: 17 Sep 2005, 05:33

Post by biggeruniverse » 17 Oct 2005, 03:25

http://jerome.biggeruniverse.com/docs/javadoc/api/ :P

Sorry. I don't have a URL for my brain yet...
We are on the outer reaches of someone else's universe
Post Reply