Keep track of online servers to detect unreachable portals

[EpicKnarvik97]

It was originally planned that the InterServer table should have a property isOnline to keep track of online portals, but this was never implemented. If it is to be implemented, it would be better to keep track of whether the entire server is online by adding an isOnline property to the ServerInfo table. That way, you'll know that all portals belonging to an offline server are unreachable. This can also be used for legacy bungee to send a more clear error message.

Benefits to keeping track of online servers:

• Being able to tell the user that the portal is trying to connect to an offline server
• Being able to hide unreachable portals on offline servers
• Being able to mark unreachable portals on offline servers

[Thorinwasher]

The question is how to do that reliably?

Would it be a good idea to make a simple bungee plugin for it?

[EpicKnarvik97]

The question is how to do that reliably?

Would it be a good idea to make a simple bungee plugin for it?

If all servers share the database, we could update the database during onEnable and onDisable and poll it every 10 seconds or so.

For SQlite, we could probably send a custom bungee message during onEnable and onDisable, which the other servers would use to update their ServerInfo table.

Alternatively, we could just store the online status transiently and design a small protocol.
Basically, when a server is enabled, it would send an enabled message with its server id. Then, all servers receiving the message would send a reply message with their server id and the id of the server they are repying to, to notify the new server of their existence.
When a server is disabled, it would also send a disable message with its server id, but no reply would be necessary.

Only storing it transiently might be the better option, as it won't assume the other servers are available after a crash.

[EpicKnarvik97]

Protocol for a new enabled server:

1. A new server is enabled
2. The new server broadcasts a SERVER_ENABLED message to all servers
3. The other servers receive and store the server id of the newly enabled server (as long as the server isn't receiving its own message) which they use to check if the new Server's Stargates are available
4. The other servers send a SERVER_ENABLED_REPLY message containing the id of the new server and their own id
5. The new server receives the reply message and, if it's a reply for the new server, stores the received id which it uses to check if its Stargates are available

Protocol for a disabled server:

1. A server is disabled
2. The disabled server broadcasts a SERVER_DISABLED message to all other servers
3. The other servers receive the disabled message and removes the received server id from their list of known servers

SERVER_ENABLED message: Contains the id of the newly enabled server
SERVER_ENABLED_REPLY message: Contains the id of the server that is replied to, a separator and then the id of the server sending the reply
SERVER_DISABLED message: Contains the id of the disabled server

[Thorinwasher]

The main problem with broadcasting the messages is the requirements to be able to send those; plugin messages require a player to be online on the server receiving and broadcasting the message. In this case if a player was not online on a server shutting down or starting, no broadcasting message can be sent to relevant servers.

Note that this is not an issue for portal creation and destruction, as those actions require a player to be online (if not done by an addon). Receiving messages is only relevant when a player is online. Which is fine, as messages that could not be received are stored in a queue

[EpicKnarvik97]

The main problem with broadcasting the messages is the requirements to be able to send those; plugin messages require a player to be online on the server receiving and broadcasting the message. In this case if a player was not online on a server shutting down or starting, no broadcasting message can be sent to relevant servers.

Note that this is not an issue for portal creation and destruction, as those actions require a player to be online (if not done by an addon). Receiving messages is only relevant when a player is online. Which is fine, as messages that could not be received are stored in a queue

If a BungeeCord addon could fix this, that would be a working solution. Through event manipulation, the whole feature could potentially be an add-on. Alternatively, we could use sockets directly to communicate the protocol.

If we sent a plugin message when a player activated a portal, would the receiving server be able to reply? The connect message can be sent to a server without players.

[Thorinwasher]

The main problem with broadcasting the messages is the requirements to be able to send those; plugin messages require a player to be online on the server receiving and broadcasting the message. In this case if a player was not online on a server shutting down or starting, no broadcasting message can be sent to relevant servers.
Note that this is not an issue for portal creation and destruction, as those actions require a player to be online (if not done by an addon). Receiving messages is only relevant when a player is online. Which is fine, as messages that could not be received are stored in a queue

If a BungeeCord addon could fix this, that would be a working solution. Through event manipulation, the whole feature could potentially be an add-on. Alternatively, we could use sockets directly to communicate the protocol.

If we sent a plugin message when a player activated a portal, would the receiving server be able to reply? The connect message can be sent to a server without players.

Only if the server has a player on it, it would be able to reply. This is just an annoying limitation with bungee. Using sockets directly is an option, but it might be somewhat complicated, but wouldn't that also mean that the addresses/ports for each server would have to be defined in the config?

It might just be easier for the end user if we make a simple bungee plugin for this instead.

[EpicKnarvik97]

I have seen Bungeecord plugins that display the status of online servers, but I'm not entirely sure how to go about it. If the plugin could keep track of the servers, and be able to send/receive messages, we could just poll it for the information either on a schedule, or when a player activates a portal.

I'm not sure how to start even getting that information from. But if we are going to do it with a bungee plugin, we should probably put this on hold. Regardless of the solution, there doesn't seem to be advantages to storing the online status in the database, except for MySQL servers, so we can avoid database changes.