#Should all servers subscribing to Messaging Service execute all the code?

1 messages · Page 1 of 1 (latest)

untold nymph
#

I’m currently building a system that relies on a messaging service. Whenever a new server is initialized, it subscribes to the appropriate topic. At the same time, my system uses a periodic update. My question is: once a server has already subscribed, should it skip the code that calculates the next update (that has a random factor) and messaging update and simply wait for the updates pushed via the messaging service? Or is it safe for every server to keep running that scheduling code independently?

In my case : I have my map’s “season” change every hour. When a new server comes online, it uses the messaging service to fetch the current season (the same value shared by all servers logically). Should the script that handles time tracking, season selection, etc., run on every server, regardless of subscription status, or only on those servers that weren’t able to subscribe (because no messaging service was available since no server was open)?

It feels a bit odd to let every server run the same scheduling logic, since they'll all send update and different results if i'm not wrong.
But at the same time making server skipping the scheduling logic is scary because maybe they won't get the Message from Messaging Service, idk.

Sorry for bad english I tried my best

gloomy kiln
# untold nymph I’m currently building a system that relies on a messaging service. Whenever a n...
  1. Designate a Leader ("Primary Server")
    Use a simple mechanism to let only one server run the scheduler logic.

This could be:

The first server that comes online.

A random server elected using a mutex-like key (e.g., stored in a datastore).

A heartbeat check to see if any scheduler is already running.

  1. All Servers Subscribe to the Messaging Service
    Every server subscribes to the messaging topic.

When a season update is broadcast (e.g., every hour), all servers receive it and update accordingly.

  1. Non-Leader Servers Do Not Run the Scheduler
    They do not randomly calculate or broadcast the next season.

This prevents desync issues.

  1. Fallback Safety Logic
    If a server starts and no recent message was received for X seconds, assume the messaging service is down or no server is active.

In this case, that server promotes itself to the primary scheduler and starts the logic.

#

Use a central data store (e.g., Roblox DataStore or memory-backed service) to store the current season + timestamp.

On server start, read that value before deciding whether to promote.

Add timestamps to messages so servers can detect stale data.

gloomy kiln
lament sedge
untold nymph
#

I was asking myself the same question..

lament sedge
# untold nymph I’m currently building a system that relies on a messaging service. Whenever a n...

Messaging service delivery is best-effort and not guaranteed. in your case of making the servers switch seasons every hour, it might be better to use memoryservice to store and retreive the season data, and yes all servers need to run at least some scheduling logic so that each server knows when to update the season. I think the hardest problem you have is how to synchronously select a new season, and usually you have some RNG involved. i suggest as part of your shared scheduling logic that you can include a Random object with a predetermined seed (i.e you write os.clock as the next random's seed each time), and then rely on memorystore's Update function for parallel safety. This will guarantee all servers stay in sync and you do not need to allocate a primary server for anything. All the servers need to read from the same memorystore entry every hour, plus once at startup no matter what you do, so all servers that use these seasons must also have the code to update the season. as luck might have it, a server might start up and happen to be the first to update the season on its first update call.

#

in theory you might only need to read once at the start and use the same RNG seed to generate the next seed, but i think having all servers check-in would be useful depending on what else you're putting in there.

gloomy kiln
untold nymph
# lament sedge Messaging service delivery is best-effort and not guaranteed. in your case of ma...

I'm really having trouble understanding your solution. It seems interesting, but at the same time, I'm having trouble understanding how it can maintain proper synchronization, to ensure that the season is the same.
With LowkeyFract solution, I understand better and I have a better idea of ​​how to do it, but if you're telling me that I risk relibality issues, I'd rather see your solution

Could you please help me, if you'd like and when you have the time, on how using Memory Store Service and a seed based on the current time would allow me to have synchronized seasons, the same ones on all servers ?

lament sedge