Open XAMPPRocky opened 1 year ago
'This issue is marked as Stale due to inactivity for more than 30 days. To avoid being marked as 'stale' please add 'awaiting-maintainer' label or add a comment. Thank you for your contributions '
Still an issue.
'This issue is marked as Stale due to inactivity for more than 30 days. To avoid being marked as 'stale' please add 'awaiting-maintainer' label or add a comment. Thank you for your contributions '
still an issue
'This issue is marked as Stale due to inactivity for more than 30 days. To avoid being marked as 'stale' please add 'awaiting-maintainer' label or add a comment. Thank you for your contributions '
still an issue
'This issue is marked as Stale due to inactivity for more than 30 days. To avoid being marked as 'stale' please add 'awaiting-maintainer' label or add a comment. Thank you for your contributions '
Still an issue
'This issue is marked as Stale due to inactivity for more than 30 days. To avoid being marked as 'stale' please add 'awaiting-maintainer' label or add a comment. Thank you for your contributions '
Still an issue
Is your feature request related to a problem? Please describe. Talking with @markmandel this issue is a follow on from #279 #404 and #2396. The problem being that currently if your gameserver requires significant time from its
GameserverAllocation
to when it's ready to accept players, by default you can run into a race condition, where the matchmaker has given the client the server information, and the client attempts to connect before the gameserver is actually ready to serve the connection, causing the client to be rejected.This can be worked around by adding a label or annotation that indicates when a server is really ready or implementing it in the connection logic itself, however the downside is that is a game specific solution, and requires any and all services which also depend on knowing when a gameserver is ready to be played such as Quilkin to also know how that specific game's logic works to be considered playable.
It would reduce a lot of effort and allow other services to leverage the
Allocated
state if it could be a strong guaranteed that when a server isAllocated
it's always playable for players.Describe the solution you'd like The solution that I've come with is to add a new state to the gameserver CRD, called
Allocating
, and add a health check for determining when a gameserver has becomeAllocated
.Instead of agones-controller immediately setting the gameserver to
Allocated
, it would instead set it toAllocating
, if no allocating health check is set, then the existing behaviour is triggered, and the server is immediately setAllocated
.If there is an allocating health check, then the agones-controller would begin to poll the health check to determine when the server has allocated (with a final timeout to prevent a server from being stuck forever
Allocating
).Describe alternatives you've considered How the gameserver communicates with agones could be a polling health check or it could be a webhook or Server Sent Event, the source of the health check isn't so important, whichever is the most convenient and compatible for most of the server SDKs would be fine.