Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

aixen server model #5

Open
haneefmubarak opened this issue Mar 13, 2014 · 13 comments
Open

aixen server model #5

haneefmubarak opened this issue Mar 13, 2014 · 13 comments

Comments

@haneefmubarak
Copy link
Owner

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

aixen server model

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
Copy link
Collaborator

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

@XePeleato
Copy link
Collaborator

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

@substanc3-dev
Copy link
Collaborator

The modifications will be made later.

@haneefmubarak
Copy link
Owner Author

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//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
Copy link
Owner Author

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//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
Copy link
Collaborator

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

@substanc3-dev
Copy link
Collaborator

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

This was referenced Mar 15, 2014
@haneefmubarak
Copy link
Owner Author

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
Copy link
Collaborator

MayeulC commented Mar 15, 2014

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
Copy link
Owner Author

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
Copy link
Owner Author

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
Copy link
Owner Author

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

@haneefmubarak
Copy link
Owner Author

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))?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants