Server Architecture

[bsparks]

update server architecture to be similar to this, by splitting into these processes hopefully we can get lag down and support a few hundred players

http://www.mmorpg.com/blogs/FaceOfMankind/052013/25185_A-Journey-Into-MMO-Server-Architecture

[bsparks]

as I'm researching and trying stuff out i'll try to update this

so we won't be needing a patch server of course, as the game is online.

the proxy servers are the web socket servers, I've been experimenting and working on using node clustering to generate several of those.

then I'm thinking we should use RabbitMQ to hook up all the "back end" servers together.

I think there should be a separate chat server, and then I'm thinking of splitting out the world octree into separate processes as well, with a "master" world server that handles said octree management.

also the sync server can prolly commit to the db once a minute? maybe longer...

oh and the website has to get split out for sure, been thinking we might be better off using https://nodebb.org/

[nickjanssen]

Very nice article! I do have some questions though:

• Since we are moving to Unity we will probably need a patch server. So then, the patch server appears to do a very simple job? Just verify what version the client is running and send yes or no. If outdated, the client needs to download a new version of the Ironbane client. Also, what if the client spoofs the version of the client to be something else?
• I don't understand the concept of 'spreading the work load among several game servers'. Will players be able to see each other on different servers? In the end, are we creating something like WoW, where there are multiple realms? Or are we making one massive world where everyone can see everyone?
• What is the function of the World server? Does it take care of balancing the clients between several game servers? Why is a connection needed to it at all times? Perhaps, if a game server fails, the world server redirects you to another game server?
• Do all game servers read and write to the same sync server? So there is only one database in use for all game servers? Probably related to question 2)
• Are we using the node.js variant then of RabbitMQ? https://github.com/squaremo/amqp.node
• Are we going to make repositories for each server type?

Woo, I'm quite excited! This is truly scalable!

[bsparks]

I imagine that we'd check the client version when they connect. If they are going to hack the exe (which I guess if we are making the client open source, should be easy) then there is probably nothing we can do about it.

I think that we should create just a single world, no realms or shards. There could still be zones and instances however. I think that the world server would keep a list of all "units" in the entire world, but mostly act as a router to the various game servers. The game servers would only need to loop through a small number of units (prolly spatially organized?) and then communicate changes back to the world server. I think kind of how the old worldHandler worked, except splitting out the cells into processes instead. (this is theory that I'm still trying to wrap my head around for implementation myself :) )

I think the sync server would be pretty much reading everything from the db at the start, then keeping state in memory, and just writing to the db every few minutes. Instead of every change.

Yeah I think that was the version of amqp (the default protocol for RabbitMQ) that I was looking at.

I don't think we need separate repos for the server, even tho the items are separated, they'll still all be working together as a cohesive "server" unit (hopefully).