Replies: 3 comments
-
I recommend using a regular polling loop of regular intervals instead of a fetch-on-request approach. This resolves the need to recursively fetch servers by only returning "flat" server lists per node at the expense of potentially slower updates of external server information. Eventual consistency should still be kept this way, however. |
Beta Was this translation helpful? Give feedback.
-
If we're going by polling loops we can use cron jobs to run the PHP functions, write them to be more CLI-friendly (I've done that in f7adc81 ), and add an output location to the .yaml for the rooms/servers files to get updated and pushed to whatever web server one could ask for |
Beta Was this translation helpful? Give feedback.
-
Late reply but the addition of the fetch-from-snitch feature (and accompanying Snitch API) further "flattens" the data by providing universewide netgame data alongside it's origin, resolving origin indirection. By extension, it is highly recommended to fetch-from-snitch over relying on the v1 API wherever possible. |
Beta Was this translation helpful? Give feedback.
-
The original master server API does not consider use of multiple servers, much less as a distributed, intercommunicating network.
This thread serves as discussion to the approach on how to resolve fetch loops within a network.
Beta Was this translation helpful? Give feedback.
All reactions