Jump to content

  • Log In with Google      Sign In   
  • Create Account


#Actualpapalazaru

Posted 27 September 2012 - 04:14 PM

Typically, from what I've seen on console games, it's done brute force. The client sends a ping request to a bunch of servers returned by the matchmaking server.

This involves resolving addresses first, then sending ping packets to the resolved address, waiting for a reply. Often, there are several ping requests sent for latency measurement (and sometimes also to get some information about the game on the server), and then averaged.

On the game hosting side, there is a bandwidth cap you can set for QOS to avoid flooding the upstream bandwidth. If you have too many clients querying the same servers, these ping requests will be dropped at the server end, the gamer will be seen as 'unavailable' to some clients. That could be at the address resolver level, which should be more lightweight that letting the clients flood the game host with QOS requests. Typically, QoS negotiation can take a few seconds.

Also, you can have the game host notify the matchmaking server when their QOS bandwidth load changes significantly (10%, 50%, 90%, ...), then the matchmaking server can lower the priority of that game host if it is overloaded with queries. And of course, you do not advertise full servers, so these that would need to maximise their upstream bandwidth will never get pinged.

You can of course limit the number of concurrent qos requests on the game host side. You don't really want to run 1,000 simulatenous requests (typically, around 20), so you need to stagger them appropriately.

#5papalazaru

Posted 27 September 2012 - 04:13 PM

Typically, from what I've seen on console games, it's done brute force. The client sends a ping request to a bunch of servers returned by the matchmaking server.

This involves resolving addresses first, then sending ping packets to the resolved address, waiting for a reply. Often, there are several ping requests sent for latency measurement (and sometimes also to get some information about the game on the server), and then averaged.

On the game hosting side, there is a bandwidth cap you can set for QOS to avoid flooding the upstream bandwidth. If you have too many clients querying the same servers, these ping requests will be dropped at the server end, the gamer will be seen as 'unavailable' to some clients. That could be at the address resolver level, which should be more lightweight that letting the clients flood the game host with QOS requests. Typically, QoS negotiation can take a few seconds.

Also, you can have the game host notify the matchmaking server when their QOS bandwidth load changes significantly (10%, 50%, 90%, ...), then the matchmaking server can lower the priority of that game host if it is overloaded with queries. And of course, you do not advertise full servers, so these that would need to maximise their upload bandwidth will never get pinged.

You can of course limit the number of concurrent qos requests on the game host side. You don't really want to run 1,000 simulatenous requests (typically, around 20), so you need to stagger them appropriately.

#4papalazaru

Posted 27 September 2012 - 04:13 PM

Typically, from what I've seen on console games, it's done brute force. The client sends a ping request to a bunch of servers returned by the matchmaking server.

This involves resolving addresses first, then sending ping packets to the resolved address, waiting for a reply. Often, there are several ping requests sent for latency measurement (and sometimes also to get some information about the game on the server), and then averaged.

On the game server side, there is a bandwidth cap you can set for QOS to avoid flooding the upstream bandwidth. If you have too many clients querying the same servers, these ping requests will be dropped at the server end, the gamer will be seen as 'unavailable' to some clients. That could be at the address resolver level, which should be more lightweight that letting the clients flood the game server with QOS requests. Typically, QoS negotiation can take a few seconds.

Also, you can have the game server notify the matchmaking server when their QOS bandwidth load changes significantly (10%, 50%, 90%, ...), then the matchmaking server can lower the priority of that game server if it is overloaded with queries. And of course, you do not advertise full servers, so these that would need to maximise their upload bandwidth will never get pinged.

You can of course limit the number of concurrent qos requests on the game server side. You don't really want to run 1,000 simulatenous requests (typically, around 20), so you need to stagger them appropriately.

#3papalazaru

Posted 27 September 2012 - 04:09 PM

Typically, from what I've seen on console games, it's done brute force. The client sends a ping request to a bunch of servers returned by the matchmaking server.

This involves resolving addresses first, then sending ping packets to the resolved address, waiting for a reply. Often, there are several ping requests sent for latency measurement (and sometimes also to get some information about the game on the server), and then averaged.

On the game server side, there is a bandwidth cap you can set for QOS to avoid flooding the upstream bandwidth. If you have too many clients querying the same servers, these ping requests will be dropped at the server end, the gamer will be seen as 'unavailable'. That could be at the address resolver level, which should be more lightweight that letting the clients flood the game server with QOS requests. Typically, QoS negotiation can take a few seconds.

Also, you can have the game server notify the matchmaking server when their QOS bandwidth load changes significantly (10%, 50%, 90%, ...), then the matchmaking server can lower the priority of that game server if it is overloaded with queries. And of course, you do not advertise full servers, so these that would need to maximise their upload bandwidth will never get pinged.

You can of course limit the number of concurrent qos requests on the game server side. You don't really want to run 1,000 simulatenous requests (typically, around 20), so you need to stagger them appropriately.

#2papalazaru

Posted 27 September 2012 - 04:09 PM

Typically, from what I've seen on console games, it's done brute force. The client sends a ping request to a bunch of servers returned by the matchmaking server.

This involves resolving addresses first, then sending ping packets to the resolved address, waiting for a reply. Often, there are several ping requests sent for latency measurement (and sometimes also to get some information about the game on the server), and then averaged.

On the game server side, there is a bandwidth cap you can set for QOS to avoid flooding the upstream bandwidth. If you have too many clients querying the same servers, these ping requests will be dropped at the server end, the gamer will be seen as 'unavailable'. That could be at the address resolver level, which should be more lightweight that letting the clients flood the game server with QOS requests. Typically, QoS negotiation can take a few seconds.

Also, you can have the game server notify the matchmaking server when their QOS bandwidth load changes significantly (10%, 50%, 90%, ...), then the matchmaking server can lower the priority of that game server if it is overloaded with queries. And of course, you do not advertise full servers, so these that would need to maximise their upload bandwidth will never get pinged.

You can of course limit the number of concurrent qos requests on the game server side. You don't really want to run 1,000 simulatenous requests, so you need to stagger them appropriately.

#1papalazaru

Posted 27 September 2012 - 04:08 PM

Typically, from what I've seen on console games, it's done brute force. The client sends a ping request to a bunch of servers returned by the matchmaking server.

This involves resolving addresses first, then sending ping packets to the resolved address, waiting for a reply. Often, there are several ping requests sent for latency measurement (and sometimes also to get some information about the game on the server), and then averaged.

On the game server side, there is a bandwidth cap you can set for QOS to avoid flooding the upstream bandwidth. If you have too many clients querying the same servers, these ping requests will be dropped at the server end, the gamer will be seen as 'unavailable'. That could be at the address resolver level, which should be more lightweight that letting the clients flood the game server with QOS requests. Typically, QoS negotiation can take a few seconds.

Also, you can have the game server notify the matchmaking server when their QOS bandwidth load changes significantly (10%, 50%, 90%, ...), then the matchmaking server can lower the priority of that game server if it is overloaded with queries. And of course, you do not advertise full servers, so these that would need to maximise their upload bandwidth will never get pinged.

PARTNERS