1st Party / Distributed Matchmaker support #660
Comments
markmandel
added
kind/feature
|
/cc @victor-prodan pretty sure this is what you wanted a long time ago? (e.g. #297) |
|
Staring at this, I realised that game servers could move straight to /cc @joeholley does the abovegel with what we had originally discussed? |
What happens after the GS returns to Ready state (after timeout)? Should it try to set itself to Reserve state and then Register with MM? |
Yep, sure this 👍 |
That's up to the game server. But yes, I expect it will re-register, possibly after a short period, to give an opportunity to scale down if there aren't any players currently playing.
It's my understanding, that for many matchmakers, a gameserver will register themselves for a time period with the matchmaker - i.e. "I'm available to play a game on, for the next 5 minutes". Once that time has passed, the matchmaker no longer has it available as an option, unless it re-registeres. This happens so that a fleet can scale down as needed, if there are less people than anticipated playing a game, and one needs to scale the fleet down. |
Matchmaker could also delete those unused gameservers via the k8s API. |
Even simpler - just as it sends GameStarting event, it could send a 'Shutdown' event as well. |
|
Yeah - it is dependent on the matchmaker - some of which some people have control over, and some people do not. But it sounds like the above design would work for all these different requirements? |
|
I would change Reserve(n) into Reserve() and Unreserve() (or other equivalent names), because it's more flexible and allows both the type of implementation when we know the reservation time in advance and also the kind in which the matchmaker tells a server to shut down. |
|
I actually think having both might be worth while. Reserve(n) would auto timeout while Reserve() would not. Unreserve() would force it into its unreserved state, removing the timeout if it exists. |
Not all languages have function overloading, but those that do can do
So I think then that the above design should work out well. I added a section on |
|
Starting work with a PR to implement WIP: https://github.com/markmandel/agones/tree/feature/sdk-allocate |
Now GameServers can self Allocate! This is just the implementation of the GO SDK at this stage (although the gRPC libraries have been regenerated). Other languages can come in later PRs. This is the first part of 1st Party MatchMaking support (googleforgames#660)
Now GameServers can self Allocate! This is just the implementation of the GO SDK at this stage (although the gRPC libraries have been regenerated). Other languages can come in later PRs. This is the first part of 1st Party MatchMaking support (googleforgames#660)
|
I just got completed with @Kuqd looks like your work in #630 fixes this -- can you confirm? If so, I'll wait on that to go through (looks like it's close, just need to resolve some conflicts mostly). /cc @dsazonoff for visibility as well. |
|
yes it does ! |
Now GameServers can self Allocate! This is just the implementation of the GO SDK at this stage (although the gRPC libraries have been regenerated). Other languages can come in later PRs. This is the first part of 1st Party MatchMaking support (googleforgames#660)
Now GameServers can self Allocate! This is just the implementation of the GO SDK at this stage (although the gRPC libraries have been regenerated). Other languages can come in later PRs. This is the first part of 1st Party MatchMaking support (googleforgames#660)
Now GameServers can self Allocate! This is just the implementation of the GO SDK at this stage (although the gRPC libraries have been regenerated). Other languages can come in later PRs. This is the first part of 1st Party MatchMaking support (googleforgames#660)
Now GameServers can self Allocate! This is just the implementation of the GO SDK at this stage (although the gRPC libraries have been regenerated). Other languages can come in later PRs. This is the first part of 1st Party MatchMaking support (googleforgames#660)
Now GameServers can self Allocate! This is just the implementation of the GO SDK at this stage (although the gRPC libraries have been regenerated). Other languages can come in later PRs. This is the first part of 1st Party MatchMaking support (googleforgames#660)
Now GameServers can self Allocate! This is just the implementation of the GO SDK at this stage (although the gRPC libraries have been regenerated). Other languages can come in later PRs. This is the first part of 1st Party MatchMaking support (googleforgames#660)
Now GameServers can self Allocate! This is just the implementation of the GO SDK at this stage (although the gRPC libraries have been regenerated). Other languages can come in later PRs. This is the first part of 1st Party MatchMaking support (#660)
The proto file definition for the reserve status in googleforgames#660, and the generated clients from there.
|
I was digging into this more - from the design and the original version of Looking at the code, I don't think this is a good idea. They should be async like I'll shift the current implementation of Allocate over to using the queue like the other implementations targeted at the next release. The API surface will stay the same though. This also means it doesn't matter what state change you are trying to implement - you can use the watch command to see when the final change occurs - so you only need one logical path to implement. Please let me know if anyone has objections / that doesn't make sense. |
The proto file definition for the reserve status in #660, and the generated clients from there.
|
Remaining work (I have done it, but am slowly feeding it through the PR queue):
|
Shows how the workflow can exist for 1st party/distributed matchmakers. Work on googleforgames#660
Shows how the workflow can exist for 1st party/distributed matchmakers. Work on googleforgames#660
Pushes a new simple-udp version (0.13) Work on googleforgames#660
Pushes a new simple-udp version (0.13) Work on googleforgames#660
Pushes a new simple-udp version (0.13) Work on googleforgames#660
Shows how the workflow can exist for 1st party/distributed matchmakers. Work on googleforgames#660
Pushes a new simple-udp version (0.13) Work on #660
Shows how the workflow can exist for 1st party/distributed matchmakers. Work on googleforgames#660
Shows how the workflow can exist for 1st party/distributed matchmakers. Work on #660
Update dot and generated PNG with the Reserved state, and resultant flow from there. Tried to keep it as simple as possible, while still representing potential state changes. Should be final work on googleforgames#660 except for missing SDK functions.
Update dot and generated PNG with the Reserved state, and resultant flow from there. Tried to keep it as simple as possible, while still representing potential state changes. Should be final work on googleforgames#660 except for missing SDK functions.
Update dot and generated PNG with the Reserved state, and resultant flow from there. Tried to keep it as simple as possible, while still representing potential state changes. Should be final work on googleforgames#660 except for missing SDK functions.
Update dot and generated PNG with the Reserved state, and resultant flow from there. Tried to keep it as simple as possible, while still representing potential state changes. Should be final work on #660 except for missing SDK functions.
|
So the base functionality of this is now complete. The remaining item is support for all the languages/engines. How do we feel about closing this ticket -- wait for the SDK functionality to be finished, or create a new ticket for the missing (which we have in #927 . Thoughts? |
|
I'm ok tracking the remaining work in #927 (and it's broader than this issue). |
Objective
To be able to support matchmaking systems that require a gameserver to register themselves with the matchmaker -- such as first party matchmakers.
Background
Many matchmakers that console and others companies provide as hosted services, have a matchmaker workflow in which:
This would be an alternative flow to
FleetAllocationorGameServerAllocation, which will remain the preferred method ofGameServerallocation, so that Agones can retain fine control of scheduling within the cluster, but since this is quite a prevalent workflow, Agones should also support it, with appropriate documentation on the tradeoffs.Requirements and Scale
The design and implementation must ideally have no potential race conditions, and actively prevent the user from incurring race conditions in their usage as well.
Design Ideas
To support this within Agones, we will need to add three enhancements:
ReservedGameServerstateReserve(seconds)Allocate()Reserved GameServer State
Reserved state is to signify that the GameServer cannot be deleted, as it may move to allocated in a given time frame. Therefore:
Reservedinstances will not be deletedReservedwill not incur an increase in GameServers in the Fleet.This will mean that if a GameSerer is not demarcated for a game session by the matchmaker, it can move back to Ready in a timely manner, and is able to be scaled down as needed.
SDK Function: Reserve(seconds)
This new SDK function,
Reservewill set theGameServerrecord to theReservedstate for the given number of seconds. (0 indicating forever). When that time period has ended, theGameServershall revert back toReady.It is assumed that when working with a matchmaker, the developer will mark the GameServer as
Reservedfor slightly longer than it is registered with the matchmaker, so as to avoid scale down race conditions.Technical Details
Rather than implementing this with a queue, this should be a synchronous call to the Kubernetes API, with in-built retry and a timeout (30s) on failure. Otherwise there is potential for race conditions between calling the SDK function, and the
GameServerbeing moved toReservedstate.SDK Function: Allocate()
This new SDK function all allows a game server to mark itself as
Allocatedwhen called.Technical Details
Rather than implementing this with a queue, this should be a synchronous call to the Kubernetes API, with in-built retry and a timeout (30s) on failure. Otherwise there is potential for race conditions between calling the SDK function, and the
GameServerbeing moved toAllocatedstate.SDK Function: Ready()
As currently exists,
Ready()should return theGameServerto a ready state, but also remove any timeout that may be in place from aReserve(n).Proposed Matchmaker Workflow
The following would be the workflow for a game server process as it is integrated with Agones and 1st party matchmaker.
In this workflow, there is no requirement for a GameServer to mark themselves as
Ready- they canReserve(n)themselves as soon as they are about to register themselves with the matchmaker.The text was updated successfully, but these errors were encountered: