aixen server model

[haneefmubarak]

Here's a rough idea of what I have so far:

Sorry about the graph being messy and all. Anyways, essentially, the diagram shows:

• multiple masters
• multiple slaves
• multiple DB servers
• cloud storage for persistent large assets

Some stuff that the diagram doesn't show particularly well:

• each slave should be able to easily handle quite a few players (maybe ~64 minimum?)
• slaves don't have to be online 24/7 - they can come and go offline as they please
• slaves are servers that users should volunteer - perhaps users can be incentivized by being automatically assigned to their server?
• each master should be able to handle a fair number of slaves - the ultimate fanout should be pretty damn high

[substanc3-dev]

That looks like the XBL server model... But good idea, masters can be my servers.

[XePeleato]

It's ok, but for connecting with the emulator? I think we need some modifications to the emulator

[substanc3-dev]

The modifications will be made later.

[haneefmubarak]

Aixen will have a library which will allow various things, including the emulator to easily connect to Aixen.

On Thursday, March 13, 2014, Jano Varga notifications@github.com wrote:

The modifications will be made later.

Reply to this email directly or view it on GitHubhttps://github.com/haneefmubarak/Aixen/issues/5#issuecomment-37507431 .

NOTICE: This e-mail (and any attachments) may contain PRIVILEGED OR CONFIDENTIAL information and is intended only for the use of the specific individual(s) to whom it is addressed. It may contain information that is privileged and confidential under state and federal law. This information may be used or disclosed only in accordance with law, and you may be subject to penalties under law for improper use or further disclosure of the information in this e-mail and its attachments. If you have received this e-mail in error, please immediately notify the person named above by reply e-mail, and then delete the original e-mail. Thank you.

[haneefmubarak]

The main difference is that the xbl model just has server clusters in various places.

On Wednesday, March 12, 2014, Jano Varga notifications@github.com wrote:

That looks like the XBL server model... But good idea, masters can be my servers.

Reply to this email directly or view it on GitHubhttps://github.com/haneefmubarak/Aixen/issues/5#issuecomment-37504755 .

NOTICE: This e-mail (and any attachments) may contain PRIVILEGED OR CONFIDENTIAL information and is intended only for the use of the specific individual(s) to whom it is addressed. It may contain information that is privileged and confidential under state and federal law. This information may be used or disclosed only in accordance with law, and you may be subject to penalties under law for improper use or further disclosure of the information in this e-mail and its attachments. If you have received this e-mail in error, please immediately notify the person named above by reply e-mail, and then delete the original e-mail. Thank you.

[substanc3-dev]

So why mot to be simplystic like them? (I know, we dont have so much powerful servers..)

[substanc3-dev]

As im looking... Oh my english... :dancer: But i did much work and code now compiles, but i need your help, contact me on email. that was for @haneefmubarak .

[haneefmubarak]

Here's the general flow of how, say two players (A and B), would be connected together to play a game (from each of the points of view):

Players I & II:

0000:   CONNECT     to hardcoded master server (HCS)
0001:   WAIT        for response
0002:   AUTH        to HCS
0003:   RECV        AUTHCODE (authorization code) from server
0004:   RECV        list of all masters
0005:   PING        all masters
0006:   RECONNECT   to new master (lowest ping)
0007:   REAUTH      using AUTHCODE
0008:   RECV        SECODE (session authorization code)
0009:   RECV        list of all slaves
0010:   PING        all slaves
0011:   RECONNECT   to slave
0012:   SUBAUTH using SECODE
-------------------------------------------------------
At this point, the user does various actions,
like checking their messages, and this happens
using the slave server (which will talk to the
master if necessary). Finally the user joins
the matchmaking lobby for their game.
-------------------------------------------------------
0100:   SEND        matchmaking request for game and lobby
0101:   WAIT        for match
0102:   RECV        list of players for match
0103:   JOIN        connect to all other players
-------------------------------------------------------
Now the user plays their game, most of the
data is sent P2P, with a only few things
being done using the slave server, such as
synchronization and player messaging.

Random (first) master:

0000:   ACCEPT      connection from user
0001:   SEND        request for auth
0002:   CHECK       that auth is correct
0003:   SEND        authcode
0004:   SEND        list of all masters
0005:   DISCONNECT  from client

Pinged (selected) master:

0005:   RETURN      PING from client
0006:   ACCEPT      RECONNECT from client
0007:   CHECK       that REAUTH is correct
0008:   SEND        SECODE
0009:   SEND        list of slaves
0010:   DISCONNECT

Slave:

0010:   RETURN      ping from client
0011:   ACCEPT      connection from client
0012:   CHECK       for correct SECODE
-------------------------------------------------------
And then do matchmaking:
-------------------------------------------------------
0100:   RECV        matchmaking request
0101:   MATCH       find players to match up
0102:   SEND        list of players
0103:   COOP        conduct the syncs and messages between players

[MayeulC]

I was wondering... @haneefmubarak Doesn't this implies that the user can only play with the ones on the same slave? It might be a good idea, so that the ping is always the lowest possible, but the slave must contact other slaves to obtain their playerlist, and order these queries to others servers based on the latency this user has in regard to them. So, the client should send the ping results, shouldn't it? The slave could also regularly ping other slaves (actually this is certainly required to know their status), but it can be less precise. An other alternative is to ddo a selection of players, propose it to the player, and let it reply with the ping he has relatively to each one of these. Ecept, of course, if we let the user choose its slave : in that case, he knows the users pool the matchmaking will happen in.

The system might even get more complicated if we add some features (ie, matchmaking prefers friends, or the same language, level, or what else...) But you may have already taken care of this? what do you think?

[haneefmubarak]

Well, the slave would actually talk to the master for matchmaking, so it isn't restricted to players on the slave only. Messaging and sync are distributed across the slaves of the players.

[haneefmubarak]

I like the idea of latency sorted matching, but instead of having the client and the ping, slaves would probably point the player instead.

[haneefmubarak]

I think that we don't need the master servers to be connected and that we can make the protocols binary anyways.

[haneefmubarak]

additional research questions:

• [ ] are there any improvements that could be made to the model?
• [ ] how exactly should handshakes occur? I had a basic idea that i have written about here, but I am open to suggestions
• [ ] is there a way that we could distribute the necessary persistent storage outside of a cloud (ie: slave servers, possibly players computers (content relating to them and their friends))?