I’m implementing matchmaking where servers can send join requests to other servers for players (via MessagingService) to get the access code for teleportation. The receiving server can allow or deny access. I’m worried about this edge case:
ServerA needs a server for Player1 and decides to send them to ServerB.
ServerA sends a message to ServerB’s topic containing the join request.
ServerB receives the message. There is only 1 player in ServerB, so it decides to allow access and temporarily reserves a spot for them. (Ideally, ServerB would then request to keep the server open temporarily.)
ServerB sends a message to ServerA’s topic containing an “okay” response along with the access code.
The player in ServerB leaves.
ServerB shuts down because there are no players.
ServerA receives the “okay” response. Player1 is still in ServerA, so it teleports them instead of sending a “nevermind” response to unreserve their spot.
Player1 fails to connect to ServerB because it shut down. Their experience is worsened because they either need to restart the game or wait for ServerA to find and request a different server for them.
I’m worried what might happen if 20 people are sent to a server and the first 1 or 2 users leave causing it to shut down in the time it takes to receive the response and teleport them. I want this system to feel responsive and consistently work well at both low and high player counts. It might help to have an API that can try to delay the server from shutting down (returning a boolean or timestamp.) Alternatively, we just need server closing behaviors documented somewhere; If it waits 15 seconds before fully closing there wouldn’t be much of a problem.
Does BindToClose work for you here? It should hold the door open for a server meeting shutdown conditions, but I’m not sure if a server will proceed with shutdown regardless if new players are introduced within the 30 second window.
My hope is that the server attempting the teleport teleportation would error if BindToClose has started for the target server. If not, then the player would probably get stuck in transit and need to rejoin because the server isn’t likely to accept new players at that point. I want to prevent unnecessary server shutdowns in edge cases like this. A group of people across different servers could be ready to teleport only for it to shut down because the first person left immediately.
I see, it is a tricky situation seeing as Roblox prefers to clean up servers as soon as possible, I’m not sure they’re currently open to any server lifetime extension API beyond BindToClose. It would still be interesting to test BindToClose with this use case, although I’ve realized the possibility players may not even be allowed to join servers already flagged for shutdown.
BindToClose in this case isn’t precisely what you’re looking for since it doesn’t prevent so much as postpone a server’s shutdown, but you can indeed utilize it to notify your teleportation system (hopefully within a window prior to initiating the teleport) that the destination server is no longer valid.
This might be an undesirable workaround depending on the gameplay, but if you have concerns about players in A server leaving before players from B server can join them, you could alternatively teleport all of them to a fresh server.
I’m trying to achieve something similar to how Roblox joins people to servers when you press play from the website, except giving me much more control over how the world starts up and what map is selected. Putting them in a fresh server would result in that 1 player being all alone. The engine probably needs a new server-side API for it.