Add a way to directly communicate with Paper servers

[Strokkur424]

Requested Feature

What I would like to suggest is a feature which is not only tied to Velocity, but also Paper.

In short, I think it would be great to be able to directly communicate with backend Paper servers from the Velocity proxy. This could be done in a way similar to plugin messages (maybe a bit more wrapped together, allowing sending of more complex data types?), where either proxy or paper server send out a message and the receiver may receive and handle it.

Why is this needed?

I think this is mainly useful in case of sending "general" information without the need to rely on a specific player's connection.

Alternative Solutions

Currently, the only way to send information from or to backend servers is using plugin messages. This system has a few flaws though:

1. It requires an active player connection, meaning you can't just send data at any time (like server startup).
2. If not intercepted properly, messages from the backend to the proxy can result in a player being able to view those plugin messages.

Additional Information

I have decided to open the issue on the Velocity repo instead of the Paper one, since I feel like this is more a concern to developers who work on proxy servers instead of developers purely working with Paper.

[Q2297045667]

Oh,I think this proposal is very good.

[NonSwag]

I don't really see the point in this
I mean why would you send data between the servers if there is no player connected
If you need to sync things just wait for a connection
Also the player can't intercept the messages if you register the channel
And if the channel is not registered you can't even send a message over it via API
This seems to me like an xy problem: what are you trying to do?
If you really need a consistent connection just use something like redis

[Strokkur424]

Because you are asking for a use case:
A possible use case of this I see in stuff like config sync. Oftentimes, networks like to have one unified chat system or similar. This format is oftentimes controlled via config. But what if you have, let's say, 5 backend servers, where if you modify the format once, you have to modify it for 5 servers, which can become really annoying.

For redis, you need a running redis server, which puts both more weight on the person who uses your plugin and who develops your plugin.

[Timongcraft]

Also external communication could be used to retrieve player data for another backend.
But plugin messages can get lost when the player loses the connection, etc.
The thing I'm most concerned about is, if everyone uses such a system, what about other platforms and how "advanced" your data can get.
If someone really needs this kind of communication, they probably have their own communication or use some advanced cross-platform stuff (e.g. https://modrinth.com/plugin/protoweaver), if "simple" support is built into Velocity and Paper, will anyone actually use it? Or what do you envision this will be like?

[Strokkur424]

It is fairly clear that this is only a viable option for networks who only use Paper/Velocity together. Cross-platform is not really possible since we don't have control over any of the other platforms.

The main reason I view in why anybody would prefer this over protoweaver is just that it doesn't require a dependency + due to it being PaperMC maintained, people have an easier time finding and figuring stuff like that out. I, for instance, wasn't aware of protoweaver.

My vision for this is mainly a byte array based approach (or maybe a wrapper around that, similar to PDC). Sending from Velocity to Paper backend ideally just provides some RegisteredServer#getProxyConnection method, which, if not null, you can use to send bytes or the mentioned "PDC-like" object. From the Paper backend, I am not 100% sure how sending data could look like. Perhaps another register method in JavaPlugin or Server?

Receiving would just be handled as simple event registers.

The main use case I had in mind is just player-independent data sync. For bigger data values, you'd obviously use a database. But similar could be said for concepts like PDC - It's great, but for very big amounts of data, you should instead use a database. I just think that for the initial "a database is overkill", this system could be better

[rymiel]

I mean why would you send data between the servers if there is no player connected

Sending data about a player when that player leaves is a good example. You can't do it at that point because the connection is already lost.

[electronicboy]

I've always been conflicted on this sorta thing, it's been one of those things that I've wanted to look into but, never something I've wanted to actually deploy

1. On the backend, this would likely require the plugin messaging API to be replaced, this is already somewhat of a discussed goal given the nature of the configuration phase existing

2. This would break vanilla protocol support; we'd have no way of affirming that a target server supports this other than connecting and trying to access it. We'd likely need to modify the config to add a per-server setting to enable to support for this, given that there is no mechanism of querying support for this nicely as early on as we'd need to jump in

3. in counterpoint to 1, "Do I want to compete with the already existing solutions which are actually battle tested and are designed in a manner that they can support things like failsafe, etc."

4. realistically, this is such a low priority vs all the other things I need to find the time/motivation for