The client will communicate solely with an Apache HTTPD configured as reverse proxy. This server is the only machine exposed to the internet. Depending on the request URL it will forward the client requests to the webserver serving the official website, the game content webserver or the gameserver.
WebSocket is supposed to work through proxy servers which aren't aware of the websocket protocol. I just hope that's also the case for Apache HTTPD's mod_proxy_http.
The gameserver pulls the game content it needs from the content server using NFS. Having the client and the server game data in the same location makes maintainance a lot easier, because I don't have to worry about what's client-sided, what's server-sided, what's shared and if they are in sync or not.
The website webserver runs on a LAMP configuration. It also has access to the game database running MongoDB. This will allow integration between the game and interactive parts of the website. This could be used for sharing user accounts between game and website, user-pages showing character status or real-time game statistics on the website. The website will also likely need a good old MySQL database for 3rd party components like a forum, a CMS or a blogging software - also I want to separate the website data from the game data where possible to avoid game and website DOSing each other.
These five servers will run virtualized on the same machine at first. I will then put them on separate physical servers when necessary. Should these servers become overstressed, Apache, MySQL and MongoDB can already be sharded when necessary. My gameserver can not be sharded yet, but I designed the server architecture in a way which will make it easy to add support for this later.
No comments:
Post a Comment