Centralised account storage / character server

[mamoru]

This would allow multiple servers (and possibly the website) to use the same game accounts and characters. Food for thought.

[alex-tokar]

Here's an idea of how this could work:

Basically, what this means:

Each server will implement an additional thread. This thread will be responsible for connecting to the login server, sending packets to the login server, receiving packets, etc. This means that the login server will be an actual server, with the threads on the game servers being clients.

When a player connects to one of the game servers (such as NA/EU/etc), the game server will forward login related packets to the login server (account login/registration, list of characters, etc). This login server will do the actual verification/registration, then send responses to the game server which requested them, which forwards them to the client. This would essentially make the game server act as a proxy between game and login server.

Then the interesting part happens: when the user chooses to login to a particular character, the game server forwards this information to the login server. The login server will keep track of on which game server the player's data is on. If the player wants to log in to a server different than the server with his character's data, the login server will be responsible for downloading the data from the server that has the data, and uploading it to the server the player wants to log in to. After that is done, the server logs the player into the game.

The login server would also be in charge of kicking characters from the game; if player Xxx is online on EU, but Xxx successfully logs in from NA as well, the EU one will be kicked out, and the player data will be transferred to NA.

Compression library such as zlib could also be used to compress the transmitted player data. I suspect that reading/compressing such data would likely need to be a thread of its own as well, so that other people who want to log in are not blocked from doing so.

The reason that this would be implemented directly in the Atrinik servers is that it's easier to maintain, and it's portable; it should be easy for both Linux and Windows servers to talk to the login server.

[alex-tokar]

There are some other things to take into considerations for this:

• GUILDS: Currently guilds use Python shelve database to store their data. I don't recall exactly what sort of data is stored, but pending approvals, list of members, member ranks, are some of the things that come to mind. We may need a centralized server for this kind of stuff, or keeping guilds per-server; I'm not sure. Certainly, guild info about particular player could become an info object, but syncing members awaiting approval might be problematic, for example. The question is, do we even want to keep guilds as they exist today? They don't seem to be that useful, except for guild chat... might need to rethink them, but that's a discussion for another issue, most likely.
• STATISTICS: The statistics server would need to be decentralized; it could run on the same machine as the login server, but servers would need to use the login server IP for sending data to the statistics server.
• MAILBOXES: These things could be changed so that instead of using Python shelve database, they create a file in the player's data directory, so that it would be synchronized across different game servers. The trouble is figuring out on which server the player's data is on currently. Perhaps file creation could be part of the login server protocol, which would be aware of where the data is, but I don't know...
• AUCTION HOUSE: Here, I'm not sure... it uses mailboxes for sending gold, so mailboxes would need to be fixed first. The thing is, it's probably not a great idea for having different auction houses for different servers. Perhaps this should also be changed to be global across all the servers; and instead of having the items visible on the maps, they will only be in an internal database on the login server.
• CHAT: Chat packets could also be forwarded to the login server, which would broadcast it to all the other servers, for true global chat.

I'm not sure if I listed all of the things that would require globalization changes, but, the nice thing is that all of the above items would benefit from some kind of database backend running on the login server. Probably some sort of SQL server, such as MySQL. The trouble is, all of the scripts would require multi-threading to work properly in such case, so as to not block the server from running if the SQL queries take some time. Multi-threading is currently... not supported very well by the server. Our Python API supports it, but if you're not careful with for example object access, things such as linked lists can get corrupted. And for mailboxes, auction houses, etc, this is unacceptable, as they deal with object insertion/removal. So this would need to be fixed first, but again, another issue.

[alex-tokar]

Another thing is: we need to settle on a name for this so-called login server. As it will handle much more than just login/authentication, as you can see above. In the future it could also handle account creation from the website, and being the metaserver (instead of the one on the website - the website one would mirror the login server one).

Some more things it could very well be used for: monitoring all the servers (traffic usage, pings, other connection info, perhaps graphs), global server shutdown (soft-shutdown of all the game servers), global announcements (before server shutdown for example), kicking/banning, monitoring chat in real-time, logging chat, etc.

Some ideas for names:

• Control server
• Root server
• Master server
• Main server
• Central server

Personally, I'm leaning towards "Master server" so far. It would, essentially, be the master server, controlling all of the game servers. Without the master server, none of the game servers can really function on their own.

[ddhanna]

MCServer
It would stand for Master Control Server.
When referring to it we could call it the MCS for short.

[alex-tokar]

Well... master control would imply that it's the only thing that can control the connected servers, which is false - they can still be controlled separately.

[ddhanna]

I know what you think of Microsoft so i was trying to keep MS from being the initials.....

[alex-tokar]

Well, if we're going to start referring to other acronym meanings, MCServer could also stand for Minecraft Server, so there's that. ;-P