Virtual masterserver running on a cluster (single-shard I guess)
Author
Hey, I am just starting on my network code and so I want to figure out the best way to do this...
My master server from a user perspective needs to manage a set of currently available multiplayer gamaes, basic chat, and maintain a list of connected users, log them in etc, basic stuff. An actual instance of a game is hosted on either a hosting client or a dedicated server.
So as far as I can tell, my options are the following:
1. The master server for each geographic region runs one relatively powerful machine. Very plausible and makes my life simpler. (Battle.net West, East, Asia?)
2. I use a generic memory caching or a lite database instead of storing things in memory... (haven't researched this in-depth in terms of actual packages (memcache?))
3. I develop some sort of Pattern to allow smooth clustering.
4. There is a Pattern already developed I can implement for this.
I'm guessing it's going to either be 1. or 4. 1. is easy, but 4. would be sick as shit. 2 seems slow and a pain in the ass, and 3 seems like a waste of resources/too much experimentation and probably slow too.
Oh, I am coding in Java but I could in theory switch to C++ for master server if it helps. Client/host is in Java.
Quote:Original post by flysarescary
Yay for ICE:
ICE is nice infrastructure, but pay attention to license. Interfaces would be probably best built using AMI.
The rest will all depend on your actual requirements, such as type of interactions between master server and instances, or how much persistent data you have and how often you need to update it.
Quote:to manage a set of currently available multiplayer gamaes, basic chat, and maintain a list of connected users, log them in etc, basic stuff.
This type of functionality is more likely to be IO bound.
Because there is no real-time data interchange or simulation in your master server, you can easily support 10,000 simultaneous users on a single PC-type server (e g single quad-core machine). If you design your system such that it only does matchmaking, and the clients don't load the system when a session is actually in progress, you can probably scale that single matchmaker as large as your game is likely to grow -- how many sales do you need before you will have more than 10,000 matchmaking queries at the same time?
If your game gets bigger than that, then you can split the matchmaking across multiple nodes, but they don't necessarily need to know about each other. For example, for popular games on Xbox Live, you (the user) will be dynamically allocated a node, and you will only find matches that are listed on the node you are allocated. Given that you'll need to have 10,000 match listings to get to that point, the loss of an additional 10,000 match listings seems a small price to pay :-)
Once you get to that point, you also have to build in steering, such that if A and B want to buddy up using some shared join criteria, you steer them both to one of the servers (typically the lowest-loaded server).
If your game gets bigger than that, then you can split the matchmaking across multiple nodes, but they don't necessarily need to know about each other. For example, for popular games on Xbox Live, you (the user) will be dynamically allocated a node, and you will only find matches that are listed on the node you are allocated. Given that you'll need to have 10,000 match listings to get to that point, the loss of an additional 10,000 match listings seems a small price to pay :-)
Once you get to that point, you also have to build in steering, such that if A and B want to buddy up using some shared join criteria, you steer them both to one of the servers (typically the lowest-loaded server).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement