Honestly, I know I am starting to drift off here, but I am literally out of topics. I have posted so much today that I am not allowed to start a new topic for like 8 more hours XD
I think I got a bit overjoyed and chatty about sponge and made countless posts (Of course they were not necessarily spam, but still, my point is that there were a lot, not that they weren’t god)
Anyway, so I don’t get flagged, lets get back on topic.
I think it would be pointless to implement cross server communication if sponge does not have a proxy. I believe this would have been one of the things, if we were using bungee, to go under the bungeecord plugins folder rather than the server plugins. Correct me if I am wrong.indent preformatted text by 4 spaces
You still don’t understand… this has not directly something to do with bungeecord.
(not via player connection)
~ A brief explanation of current bungeecord’s communication channel with CraftBukkit / Spigot servers will maybe show you the difference.
BungeeCord uses a Minecraft vanilla feature called “Plugin Channel”. This is basically a protocol packet that can be send between client and server. It contains a String for the channel name and the packet content as a byte array. What BungeeCord basically does is to hack into that channel and intercept channel messages on the channel named “BungeeCord”. BungeeCord plugins can intercept more channels. Therefore a message can only be send to a server if a player is connected to the server!
The point of this thread is to embrace the support of server ↔ server messaging.
I honestly do not care, I think it is a good idea then. I thought you guys were trying to take a method used by proxies and implement it into sponge, but now I see what you mean now.
Correct me if I am wrong though, but will the servers have to be linked or proxied together? Or will they simply be able to send messages over the vast internet to other servers, and communicate stats and stuff?
The idea is to connect a group of servers. It does not matter if they are on the same machine, or on opposite sides of the earth.
I think we discussed that it is indifferent how the connection is implemented.
But one thing is sure, you won’t be able to simply connect to another server (security risk).
There has to be some password protection or even better a ssh key exchange.
But then again… Isn’t there always Bungee with its plugins? I have a pretty good feeling that Sponge is going to have something like that since md_5 is working on it…
Now that they know exacly what every part of theyr code does, let’s hope that this won’t give as many errors on the console as it used to give with bungee or bukkit
Nothing is decided yet and so far no statements from the core developers.
I think the best use case would be this:
Case - “Not supported” (default)
In default Sponge has no network messaging functionality.
If still used, it’ll relay the message back to the server itself.
Case - “Supported”
If a server operator wants networking functionality he can install an additional network messaging plugin.
This plugin enables the support for the network messaging functionality.
This use-case would be the best for all of us.
The Sponge Developers don’t have to implement a network messaging functionality.
The server operators have free choice what implemented version they would like.
As someone designing such a system for my own network of servers… Def want to chime in.
As many said, what the OP is asking is NOT the same as the Plugin Channels.
Currently many PIGGYBACK on top of bungee cord using the channels in order to simulate cross-server messaging, but honestly that approach is inefficient and has its quirks (can’t send to 0 player servers)
However, I worry about the idea of putting something like this into core, simply because its going to be a huge minority that would use it.
Ideally, this would be better suited as an API plugin that the server owner can write code against, that can be independently maintained and updated outside of the scope of sponge.
Lets consider that public plugins that you download will not really have a clean “implementation” of multi-server design. The way everyone links their servers is completely different on a case-by-case design basis, so its not a useful feature for public-use plugins.
Therefore, we are not solving any problems by putting something like this in core.
On the database connection pool topic, that is something I mentioned we need to do on day 1, as that DOES solve problems, being that every plugin using a DB manages their own connections, so having a system controlled pool that every plugin is encouraged to use (and those who didn’t would be shamed of course for hurting performance unnecessarily.), so that does have a huge place in core.
But networking? It’s too unique to each implementation to really serve a benefit in the API
and of course there is the concept of “But a Redis Pool would be nice, solves storing data and pubsub!”
Not everyone will be using Redis. JDBC is the common interface, so simply providing a JDBC based pool makes sense (then the server owner can configure the pool how ever they need, MySQL, SQLite, custom, etc)
Providing a 2ndary Redis pool goes back to my point - It would be extremely underused.
It’s trivial for a plugin to simply include Jedis or some other Redis library, write an API, then encourage others who do need this ability to use their API.
It has been pretty popular and I developed it to make it easy to create networked applications. With the library I created a Minecraft mod that allows people to communicate (by chat) across servers and also while in singleplayer. There is a video of it here: Online Chat - Minecraft Forge Mod - YouTube
Back to the topic. Me, I’m more on the socket ↔ socket faction side.
Why are they using JDBC for a job that is clearly not designed to be used that way?
You just need to take a look what happens over at BungeeCord: Plugins PIGGYBACK on top of bungee cord!
→ They use it, because there is an easy opportunity.
If they don’t want the (can't send to 0 player servers) they simply switch to jdbc and lower their demands by changing the initial concept ( or even discard it ).
I agree, the implementation should not be in Sponge.
And yes there are already API solutions for networking, and even some direct self-networking plugins.
But there are three points:
Server Admins will likely not use a plugin that needs a second or third network API plugin, caused by (3.).
Me as a developer, I don’t see the point for me to publish or work on a plugin against a network API plugin if this particular library is likely not used because of point (1.).- I’m surely not the only one, who feels that way.
Many private developed networking solutions thanks to few public plugins (2.)
=> Circle of Death.
Providing a basic networking interface in sponge would decouple the basic needs from unwanted dependencies and would make Sponge Server.instance = new BetterServer();.
I made some expiremental fundamental interfaces which then should be used / wrapped / whatever by Networking API Plugins. ^^ only examples
@baseball435 Would you be somehow interested to standardize basic features by making it a networking plugin for sponge with the described interfaces? ~ just theoretically ~
</ me being curious about it>
Using Plugin Channels with a middleware proxy like BungeeCord is simply out of scope of the API.
You’re talking about standing up a master server on another port, then having other clients connect to it.
Sponge is not a platform for managing other servers, so something like that has no place in the project.
It’s best to use existing pubsub technologies and if we implement 1 specific lib then everyones going to want their specific lib included to, can’t do that…
It has changed to Sponge NOT implementing some networking library that plugins can use.
Indeed I started this thread for that intention, but it changed soon when @vemacs , @connor_peet and @sibomots and more commented. It showed me that, like you say, everyone has a specific lib.
Talking about it changed my objective. ( thx to all )
It changed to have some few generalized interfaces that rudimentary describe feature of message sending over a network.
So as a result:
Simple plugins can use this simple interface to develop against.
And plugin libraries for networking can wrap them in, so the networking runs over them. They still have their full features, but only the basics features defined in that interface could be then used by other SpongeAP plugins.
However, I am wondering how the interfaces would look like.
They would need to somehow intersect a larger quantity of network libraries/plugins respectively to be wrapped into.
Finding that intersection seems to me to be the difficult part.
Sry I’m not a native English speaker, but i hope i got it this time right.
There’s still the issue that this system is for a very small minority of servers, and would not be useful or a generic “good for many” plugin.
Adding interfaces that are not even used by sponge implementation doesn’t really solve any problems.
What you are asking can very cleanly be done by a plugin instead just as Vault did.
It provides no real benefit to store the interfaces in Sponge, which then makes it harder for it to be advanced (What if 3 plugins implement the interface? Now they cant be updated w/o risk of breaking those plugins)
It causes more problems than it helps (which I can’t really see any real benefit to putting the interfaces into sponge).
They really belong in a separate project maintained by someone who’s actually going to be using them.
The sponge project would not be using them, so it is not a good place for them.
