CO Server architecture

Have been doing some conquer related programming lately, for some reason it feels like a playground for me, so decided to ask this here.

On an ideal world, we can separate every map in different applications/machines, this comes with the cost of synchronization difficulties that have the potential to be huge, database not updated properly, server failures, creating quest-like npc in different maps may be a pain to do (opening different machines).

it may sound stupid if you want to open a PServer, but i still feel interested in this, sounds fun and maybe will learn something interesting, i have no interest in write npcs, quests, but the base for all that, a working server, but empty, and ridiculously complex to what a CO Server requires.

TL;DR
Want to do this for fun.
So, all the servers will be programmed in C#, what would you recommend/change to this kind of project? libraries, softwarem etc..?(description below this)

Atm, i have thought in 5 different applications

AccServer: same as always.

DataServer: to avoid working on different folders/machines with the MapServers, for example, World server ask to one of the Map servers (mapserver1) to load the map X, mapserver1 doesnt store any data, it requests to the Data server the map info, npc, mobs, etc... now we can work in one single machine, and potentially change anything data related on the runtime.

WorldServer: Link between different map servers, also contains information that is shared by all the maps (guilds, friend list, etc...)

MapServer: Process all the actions related to one or more map, downloads all the data from the DataServer.

RouterServer: can be many, like MapServers, this one just routers all the packets to the corresponding server (World, Map or both)

level 1: DataServer
level 2: WorldServer and MapServers
level 3: ProxyServers

there will be a common library containing packet structures and entities (items, guilds, characters...) that will be shared between these applications.

communication only exists between level 1-2 and level 2-3 (and ofc with each app in the same level)

Problems i can imagine right now:

- Map server crash must be handled to avoid data loss, either with many updates to the data server and world server (who would push updates to others Map servers), or local backups, most likely the first one since certain level of synchronization is required by the game.

- Synchronize servers may become a hard task and may generate some overhead, a layer to abstract this is required so network and "direct calls" are supported, not really direct calls because packets still would be de/serialized, but this would avoid a connection with others servers.

- A lot of asynchronous calls, so threads are not locked when requesting something from other server

custom Features i want to implement (because they sound cool and fun to do)
- Separated npc logic from dialogs for multilanguage support
- Replay system
- Complete log for trades and chat, so reports could be supported

All common things, battle, npcs, equipment, etc...

Sorry if this was poorly written described but i have classes now, hopefully someone gives feedback about this, no intention in going open source since development will be kinda slow but i have no problem in sharing the repo with a few persons.

Don't split it out more than necessary.

Tbh. with CO you really don't need more than an account server and a game server.

There is no single CO server that will ever be big enough to ever need more than that, unless it was retail CO, so don't overthink it.

Quote:

Originally Posted by Super Aids Don't split it out more than necessary. Tbh. with CO you really don't need more than an account server and a game server. There is no single CO server that will ever be big enough to ever need more than that, unless it was retail CO, so don't overthink it.

I agree, i even believe that it would be slower with the amount of players that a server can expect, but i find interesting that extra complexity, as i said, it's just a for fun project, like the webserver that all of us did but would never use.

It is a massive overkill, even retail CO could do with 1 GameServer (Map+Everything else) / realm, the population count is not high enough (and the game design of CO doesn't need it either, after a critical amount, servers become overcrowded and the game is basically unplayable).

Your architecture sounds a lot like one I came up with some time ago, minus the data server - that's a clever addition. Some of the services can be omitted and the process simplified a bit. Like, you have it right with a world server being a conductor of the different map servers - that's how you get a really nice, scalable system, but the routing server might be unnecessary. The way I have it, the world server is just an RPC server for the account and map servers. When a player connects, the account server queries the game server for character data, and then sends that and the players's authentication token to the map server hosting that character's map ID. The player is sent directly to that map server. Then, on map change, the client receives another 1055 to connect to the next map server, where it might read again from the world server or just read from the map server's cache. The map servers are connected together via the world server. In general, the map servers are independent from the other servers. Something else that might interest you is a microservice architecture, but you'd have to create a recoverable TCP client proxy and TCP gateway microservice. But that would definitely be overkill.

Quote:

Originally Posted by Spirited Your architecture sounds a lot like one I came up with some time ago, minus the data server - that's a clever addition. Some of the services can be omitted and the process simplified a bit. Like, you have it right with a world server being a conductor of the different map servers - that's how you get a really nice, scalable system, but the routing server might be unnecessary. The way I have it, the world server is just an RPC server for the account and map servers. When a player connects, the account server queries the game server for character data, and then sends that and the players's authentication token to the map server hosting that character's map ID. The player is sent directly to that map server. Then, on map change, the client receives another 1055 to connect to the next map server, where it might read again from the world server or just read from the map server's cache. The map servers are connected together via the world server. In general, the map servers are independent from the other servers. Something else that might interest you is a microservice architecture, but you'd have to create a recoverable TCP client proxy and TCP gateway microservice. But that would definitely be overkill.

RouterServer are there to change between map servers, didn't know that the client would handle a reconnection like that, so most likely i will get rid of them and keep the others. Still doing some research and clearing/refactoring old projects that were experimental and i'm pretending to use, also have to decide a patch too, thinking in a patch in the 5065-5200 range since the amount resources for them is huge and i have a better understanding of the cryptography used or download one of the updated trinity sources to check them.

I've split the servers up to a similar extent that you've been looking at, honestly it's a wasted exercise, you lose more performance from the extra steps than simply having it all in one multi-threaded application.

Also as you've pointed out splitting it up introduces more risk in a way, having a smaller piece fail rather than the whole thing actually presents a bigger problem. On a large scale you would handle this with failover and redundancy, either through your own software or virtual hosts running in high availability. Honestly though, for a conquer private server both of these are fairly expensive both in terms of cost and processing power, it's simply better to have the whole game server fail and restart it.

[Only registered and activated users can see links. Click Here To Register...] It's quite old but incorporates Auth, Game, NPC and what I described as a Ban server. The Ban server performs the movement checks, but was intended to check various other things that I never got around to adding.

But yeah in the end the complexity isn't worth it.

Quote:

Originally Posted by Korvacs I've split the servers up to a similar extent that you've been looking at, honestly it's a wasted exercise, you lose more performance from the extra steps than simply having it all in one multi-threaded application. Also as you've pointed out splitting it up introduces more risk in a way, having a smaller piece fail rather than the whole thing actually presents a bigger problem. On a large scale you would handle this with failover and redundancy, either through your own software or virtual hosts running in high availability. Honestly though, for a conquer private server both of these are fairly expensive both in terms of cost and processing power, it's simply better to have the whole game server fail and restart it. [Only registered and activated users can see links. Click Here To Register...] It's quite old but incorporates Auth, Game, NPC and what I described as a Ban server. The Ban server performs the movement checks, but was intended to check various other things that I never got around to adding. But yeah in the end the complexity isn't worth it.

Although only an auth and world server, another example of how complexity can become pretty difficult to maintain, iff not done with caution.

[Only registered and activated users can see links. Click Here To Register...]