Master: Max Number of Games Handled
by Fabian Holmberg · in Torque Game Engine · 02/04/2005 (12:30 am) · 6 replies
We are currently in the process of developing a title in which we intend to have thousands of players connected to a single master at any given moment.
Note however that this does not mean that there will be thousands of players within the same game. Each game will be limited to 22 players. However we could have thousands such games running concurrently, which means that a single master will have to be aware of the thousands of clients / servers connected at the same time.
Can TNL, as is, handle this? I am concerned because all packets (Client / Server / Master) are sent via a single NetInterface, if I am not mistaken. This could cause congestion as (correct me if I am wrong) a single NetInterface would have to handle ALL game traffic as well as connection traffic.
PS: I am referring to the implementation architecture of your ZAP game example for the abovementioned query...
Thanks.
Note however that this does not mean that there will be thousands of players within the same game. Each game will be limited to 22 players. However we could have thousands such games running concurrently, which means that a single master will have to be aware of the thousands of clients / servers connected at the same time.
Can TNL, as is, handle this? I am concerned because all packets (Client / Server / Master) are sent via a single NetInterface, if I am not mistaken. This could cause congestion as (correct me if I am wrong) a single NetInterface would have to handle ALL game traffic as well as connection traffic.
PS: I am referring to the implementation architecture of your ZAP game example for the abovementioned query...
Thanks.
About the author
#2
Er.. Given that Zap does not have several thousand players, the tech is relatively new, and so forth... how do you expect that anyone will have a hard answer to this question? :)
02/13/2005 (8:39 pm)
There's no upper limit. I would suggest doing some stress tests with your expected hardware and net connection to get an idea of what performance you can expect.Er.. Given that Zap does not have several thousand players, the tech is relatively new, and so forth... how do you expect that anyone will have a hard answer to this question? :)
#3
02/13/2005 (9:43 pm)
The master's client limit should be well above tens of thousands -- though it would be useful to write a stress-test program to be certain. All of the packet dispatch code within TNL is amortized O(1) due to hashing -- the only O(n) is a simple loop for checking packet sends. You may run into some issues with the public key crypto depending on your key size, but then that's a one-time hit when the connection starts up. Once a connection is established it assumes very little overhead.
#4
Again, the master would only be responsible for setting up and removing connections. The O(n) you are referring to must indeed be the checkIncomingPackets and processConnections in the NetInterface on the master. My concern was when i saw in the code that the number of connections defaulted to 128. Thats when I started to panic - however I did notice that there is a function that quadruples that amount, renitializing everything in the hash table to one of a bigger size, should the limit be reached. I might want to default that particular limit to something much higher...
02/14/2005 (1:18 am)
Ok, its good to have a rough idea of how much the master should be able to handle, although we will definately be doing a stress test. Again, the master would only be responsible for setting up and removing connections. The O(n) you are referring to must indeed be the checkIncomingPackets and processConnections in the NetInterface on the master. My concern was when i saw in the code that the number of connections defaulted to 128. Thats when I started to panic - however I did notice that there is a function that quadruples that amount, renitializing everything in the hash table to one of a bigger size, should the limit be reached. I might want to default that particular limit to something much higher...
#5
Of course, your player base is probably not going to be that big right at first. ;) But more so than the scalability in processing time, consider how much data you're going to be moving just due to your game protocol needs. TNL is very lightweight - not much overhead there. But if you start needing people to ping or send cd key info or other stuff, the data transfer requirements can add up quickly.
02/14/2005 (3:34 pm)
"Again, the master would only be responsible for setting up and removing connections." <-- you might want to look up some of the figures on the HL master servers. They have very, very minimal bandwidth usage per connection and still have some significant issues with their master servers. TNL is _very_ efficient, probably more so than the HL master stuff is, but there's still some fundamental issues to look at there. Several hundred thousand players each sending on average single byte each minute adds up. :)Of course, your player base is probably not going to be that big right at first. ;) But more so than the scalability in processing time, consider how much data you're going to be moving just due to your game protocol needs. TNL is very lightweight - not much overhead there. But if you start needing people to ping or send cd key info or other stuff, the data transfer requirements can add up quickly.
#6
The data transfer issue will definately be on the pinacle of our stress tests. We already know that we will be requiring user account authentication, as well as user specific data such as player attributes (etc) that will have to be sent from the master to the client. This is where things could get messy.
02/14/2005 (9:49 pm)
Interestingly what I noticed in HL is that they seem to have several master servers. They most likely a single master that monitors the (sub)masters. I would be curious to know what system they use in WOW. Perhaps each realm represents a master and things get sub divided from that point onwards.The data transfer issue will definately be on the pinacle of our stress tests. We already know that we will be requiring user account authentication, as well as user specific data such as player attributes (etc) that will have to be sent from the master to the client. This is where things could get messy.
Fabian Holmberg
Again the focus of my question is: how many connections can a master handle, assuming that all it does is the necessary arranged connection handling before the game starts and after a game is concluded?
Fabian.