For developers: running #vanilla MaNGOS as docker containers

[wowmad]

I'd say that does not really matter because MaNGOS can use Postgres too. What I was talking about was, that the communication between realm list and world server should not be done by passing values through the database at all.

I agree with you... we only need to have a webservices configured to access the databases, and you can have text files to load that configuration, it only needs to reference links to access all published methods. You must not have the need to modify all code because something has changed in database.

Something like this...
Understand: WWW = Client Application; Webservers = Application Servers; Cluster = Database/Storage
3 layers, each almost independent of the others;
You can have independent clustered applications load partially in some application servers and not others, and storage could be a webservice that use a database (cluster) allowing replication to different nodes.

So, the problem is not the implementation, the problem is how to define the architecture to function as desired.

[theluda]

I would say, that is a bit too complicated for what needs to be achieved.

For starters a simple messaging service between world and authentication servers would suffice to abstract the database connection away which is now in between.

In a 2nd step, the messaging service could also be used to e.g. connect multiple world servers for syncing chat, character and world data.

[r00ty]

I'm not so much a fan of docker. So won't comment on that. The image above is somewhat over-complicated. But something similar could be achieved. The issue with a large area database cluster is that then too many people hold the keys. That is, anyone running one of the cluster servers would have unrestricted access to data and thus opens up a larger area of corruption/illegal adjustment of data.

With regards to world <-> auth server communication. I had a think about this once and I wonder if the wider solution is to have the auth server provide a second identity per account in the form of a guid. So, internally the ids are sequential still. But each account also has a guid.

The implications of this are that a server could use multiple account brokers (auth servers). This way there might be some larger organizations providing auth server services. Single servers could subscribe to one or more of these. Players register on one service, get a single realmlist and can then access multiple downstream servers.

There could also be an anonymous service used by multiple servers to safeguard user data, also protected by the auth server(s). A user could login and pull a protected copy of their data which could be used on another server, should a particular one be taken down.

So essentially the trick would be:

Client -> AuthServer (login and all associated packets)
AuthServer -> Client (Session key)
Client -> WorldServer (session key + whatever else is sent to world server)
WorldServer -> AuthServer (Session key + IP + whatever other into)
AuthServer -> WorldServer (Unique guid, or error if session not found)
WorldServer (find player data in DB for unique guid)
WorldServer -> Client (list players)

But I must admit I've not looked through code (I come from the world of TrintyCore, but essentially it's about the protocol so, applicable to both) to see where else worldserver uses auth. Aside from permissions. I think while the auth server could still provide a permission template, I think there'd need to be a locally kept override on the worldserver too. Generally moving to the point that the auth server's job is really just to authenticate a valid non banned user account and validate session keys.

[wowmad]

I would say, that is a bit too complicated for what needs to be achieved.

For starters a simple messaging service between world and authentication servers would suffice to abstract the database connection away which is now in between.

In a 2nd step, the messaging service could also be used to e.g. connect multiple world servers for syncing chat, character and world data.

About 1st problem: How to abstract database connection

I think that is possible to implement webservices inside PostgreSQL. Today, I did a search and I find this link http://postgrest.com/ (see if helps). This way MaNGOS would only consume this database webservices.

The database tablespace need to be in a drbd cluster filesystem to be fault-tolerant.

About 2nd problem: Messaging Service

I don't know if you are talking about the concepts of Enterprise Messaging System (EMS) or Enterprise Service Bus (ESB), but if you are, you are complicating more than me, because you need webservices (SOA or REST Messages) for that. Note: You need to have attention to security of transport layer, SSL is not enouth!

If you really want something simple, you will use Remote Procedure Call (RPC).

With RPC you can do what you want, because the programmer need to implement everything. It could work fine to connect multiple world servers for syncing chat, character and world data, because most of the data that you need to parse is text. You can parse binary data too, but in any case, you will need to be careful with marshalling.

Image of ESB :

[wowmad]

Subject: For developers: running #vanilla MaNGOS as docker containers

...
With regards to world <-> auth server communication. I had a think about this once and I wonder if the wider solution is to have the auth server provide a second identity per account in the form of a guid. So, internally the ids are sequential still. But each account also has a guid.
...
So essentially the trick would be:

Client -> AuthServer (login and all associated packets)
AuthServer -> Client (Session key)
Client -> WorldServer (session key + whatever else is sent to world server)
WorldServer -> AuthServer (Session key + IP + whatever other into)
AuthServer -> WorldServer (Unique guid, or error if session not found)
WorldServer (find player data in DB for unique guid)
WorldServer -> Client (list players)
...

Why not let PostgreSQL handle it? You can use single-sign-on authentication methods to do that.
http://www.postgresql.org/docs/9.5/stat ... thods.html

[theluda]

Why not let PostgreSQL handle it? You can use single-sign-on authentication methods to do that.
http://www.postgresql.org/docs/9.5/stat ... thods.html

Because we are talking about WoW client authentication as in SRP6 which is not a thing you do using a database.

[wowmad]

Why not let PostgreSQL handle it? You can use single-sign-on authentication methods to do that.
http://www.postgresql.org/docs/9.5/stat ... thods.html

Because we are talking about WoW client authentication as in SRP6 which is not a thing you do using a database.

I don't know how it works (would help if you can explain me, where i can find the source code for this particular case), but I see that account is defined in realm db.

Can't you use dblinks, table inheritance and use tableoid to identify distinct users in multiple realms? I know that could break your code, but it will be the same if you make a TABLE CHANGE anyway.

Imagine that you keep the current table structure, but you redefine tables using inheritance like this:

Code: Select all

Server_Table: <srvID> <pw Hash Key>
Account_Table: <userID> with inheritance of Server_Table
Global server view:  SELECT d.tableoid::regclass, d.*
                         FROM Server_Table d