Comments (6)
In our case, we prefer that the results of ListAction and CounterAction are also returned.
Can you explain why? I'm curious as to the use case.
Also, since you get the results, and you know what you send, you could do the diff yourself quite easily.
I thought that if we got the result of appended values, simply add them into our storage with the allocated GameServer data without calculating the diff of request and response.
I plan to cache them into our storage to use these roomIDs from other hosts to connect to the GameServer without sending request to allocator service.
Also, since you get the results, and you know what you send, you could do the diff yourself quite easily.
You are right, we can calculate the diff easily so it's not essential.
from agones.
I'm focused on some other stuff at the moment, so if you want to have a go, please feel free!
If you have questions, feel free to drop them here, or come by #development in Slack!
from agones.
We have a similar use case in implementing the High Density GameServer pattern.
When we request a GameServer allocation, we would like to be able to use list to pre-populate the room in GameServer in batches.
This will reduce the number of actual allocation requests, which is more efficient.
However, the current implementation of CountsAndLists does not necessarily append all list items defined. If you try to fill more than the capacity, you will get an error and the GameServer allocation will succeed with only some of the items filled.
In this case, the expected state of the GameServer and the actual state of the GameServer will inevitably be out of sync.
To solve this problem, it would be helpful if counts and lists are returned in the allocation response as suggested.
from agones.
In our case, we prefer that the results of ListAction and CounterAction are also returned.
For example, the following form.
Request:
{
"lists": {
"rooms": {
"addValues": ["room-3", "room-4", "room-5"]
}
},
"gameServerSelectors": [
{
"gameServerState": 1,
"lists": {
"rooms": {
"minAvailable": 1
}
}
},
{
"gameServerState": 0
}
]
}
Selected GS:
kind: GameServer
metadata:
name: gs-1
status:
state: Allocated
lists: {"rooms":{"capacity":3,"values":["room-1", "room-2"]}}
Result of GS:
kind: GameServer
metadata:
name: gs-1
status:
state: Allocated
lists: {"rooms":{"capacity":3,"values":["room-1", "room-2", "room-3"]}}
Response:
{
"gameServerName": "gs-1",
"ports": [],
"address": "",
"addresses": [],
"nodeName": "",
"source": "",
"metadata": {},
"lists": ["room-1", "room-2", "room-3"]
"listAction": {
"rooms": {
"addedValues": ["room-3"]
}
}
}
from agones.
In our case, we prefer that the results of ListAction and CounterAction are also returned.
Can you explain why? I'm curious as to the use case.
Also, since you get the results, and you know what you send, you could do the diff yourself quite easily.
from agones.
Are you already working on this issue?
If not, would you mind if I tackle it?
from agones.
Related Issues (20)
- Migration from pterodactyl to agones | Egg like solution | More real steamserver examples
- Issue with Agones Game Server Connectivity Using Cilium CNI HOT 8
- Fleet autoscaler with "List" policy throws an error if configured with a fleet with no replicas HOT 4
- CORS enabled on ping service
- Upgrade to Golang 1.22.6 HOT 2
- Extend Webhook autoscaler to send fleet metadata with the request HOT 4
- Add chain ID status to fleetautoscaler event logger
- FleetAutoscaler with Counter policy trying to scale Fleet to negative replicas count HOT 2
- Add logging to webhook failure and schedule parsing errors for Schedule/Chain policies
- Game servers are having some delays until getting external IPs from agones SDK HOT 1
- Update AWS Provider Version for Terraform module to fix Timeout Rather than Manual Workarounds
- Incorrect error logging caused by ResourceVersion conflict on SDK Patch call HOT 2
- Release 1.43.0 HOT 1
- Support GameServer.Spec.SdkServer.LogLevel "Trace" HOT 1
- Rolling updates do not progress if all game servers in the fleet are in the `Allocated` state
- Doc: "Available metrics" mark up was broken down HOT 1
- Cannot Use Agones SDK Image on Windows 2022 Node Due to Missing os.version in Docker Manifest
- Add Helm Chart Variable for Configuring SIDECAR_IMAGE Independently
- Clarrification on the metric `gameserver_creation_duration`
- Poor packing with agones-allocator and Counter for high-capacity game servers HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from agones.