Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Proposal: RefCount allocation to host many room in same pod #1197
Is your feature request related to a problem? Please describe.
This provides a complete model of Isolation, but at the cost of Runtime and Game Engine,
Does not share state between rooms, but shares execution engine (Load immutable gamedatas in memory, Runtime JIT, dynamic assemblies, etc...).
We're creating mobile game that run in .NET Core Server and Unity Client.
Many mobile games requires state-ful and realtime server but not request heavy traffic per single room.
Describe the solution you'd like
I suggest RefCount (virtual allocation).
I've heard a few requests for this sort of enhancement so it's definitely worth exploring and seeing how it would work.
There are a few of things I'm concerned about:
There are probably other things that will come up, but thinking through these will be a good place to start.
@logixworx - Are there any details about that system that you can share (or point to any public documentation)? Do you have any requirements that weren't described in the original post? Do you have any insights that we can leverage in Agones? Do you have any thoughts about the questions I posed above?
So I have quite a few thoughts, and it comes under several categories. This is a topic that has come up quite regularly over the years.
I'm going to use the term "Game Session" as the term I've grow comfortable with for a separate session / room within a Game Server.
There's some implementation details below, but I'm mostly trying to keep them to describe my ideas - please consider them sacrificial drafts.
Data Communication Routing
Would love comments, thoughts and questions on the above.
From an api standpoint it would be nice to just be able to call something like RequestSession() as much as I need. I have a system that allow us to fully clean the server from each session so being able to run the server for as long as possible is better then having to wait for a new container to boot.
We could still have the config option that equates to max total sessions the instance is allowed to make which would make the sidecar return an error when requesting a session once the limit has passed. This could fit into draining/updating as well by returning the error once the instance has been told to drain/update.
What is "it" in the above? What exactly would "RequestSession()" be doing here? Is this a SDK level API, or is more something like Allocation ?
One thing I didn't mention in the above, was I think we would also need a way to self-allocate a
Then you can move the
I think we are on the same page that the assumption is that in this instance, a
@logixworx no ETA as of yet. We've got a variety of users who are interested in this as well, so I would expect it to come at some point this year.
We still need to do a complete design document on this, as well as implementation - it's a pretty substantial piece of work, so I expect it will take some months to complete.