SubData, in a similar fashion to the Plugin Messaging Channel (PMC), allows for the various components in your SubServers network to communicate with each other. However, unlike the PMC, it doesn't rely on a player's connection to send and receive data. This ultimately makes it a better choice to use if you need to send data which is unrelated to players.
Topics on This Page:
Connecting to SubData
Communicating with SubData (for Developers)
Connecting to SubData
SubServers.Bungee opens port 4391 (by default) so that SubServers apps can communicate with each-other. To connect a SubServers app to SubServers.Bungee, open its main config file and enter the address needed to connect. Depending on your encryption type, you may need to take an additional step listed below.
No Encryption
Encryption: None
How to Connect: No additional action is required
This one simply sends the data as-is, with no encryption applied. This is SubData's fastest and most insecure mode.
AES Encryption
Encryption: AES, AES-128, AES-192, AES-256
How to Connect: Copy the password field in config.yml to the app you're trying to connect
SubData natively supports AES 128, 192, and 256 bit password-based encryption if you need to turn up the security. It does this by turning packets into AES encrypted binary data and sending that instead.
For some java installations, AES 192 and/or 256 bit encryption has been disabled. You can download a fix for this here. For more information, click here.
RSA/AES Encryption
Encryption: RSA/AES, RSA-2048/AES-128, RSA-3072/AES-192, RSA-4096/AES-256
How to Connect: Copy subdata.rsa.key to the config folder of the app you're trying to connect
So, what's better than some good ol' password-based encryption? How about a system where we login using a signature file, send over a completely randomized password that was encrypted using that signature, and then start encrypting using that randomized password. Yeah, sounds better to me, too.
In this mode, each SubData connection uses its own randomized password to AES encrypt and decrypt data after login. Even though you may be sending the same data, no two connections are the same. This can be considered the most secure mode of SubData.
DHE/AES Encryption
Encryption: DHE/AES, DHE-128/AES-128, DHE-192/AES-192, DHE-256/AES-256
How to Connect: No additional action is required
If you don't feel like fumbling around with passwords and key files just to get some encryption, then this one's for you. By using the Diffie-Hellman Exchange, both ends of the connection can agree on a completely randomized password to encrypt with automatically.
As you may have noticed, this mode is similar in nature to RSA/AES. The main difference is the lack of key files. What you're giving up on for this ease of use, however, is the simple fact that only you have your key files. Being keyless, the Diffie-Hellman Exchange doesn't care who's on the other end when negotiating a password.
Communicating with SubData
SubData has grown beyond SubServers into its very own project. This means that some things, like the API and Protocol Formatting, have been moved to more appropriate locations on its new wiki. Here are some additional topics you may be interested in:
Sending and Receiving Custom Messages
Working with Multiple Data Channels
Creating Custom Ciphers
Network States
Protocol Formatting
Channel Tracking
SubServers allows multiple SubData channels to be opened from the same source at one time. As a result, the way SubData channels are tracked within SubServers has gotten a little complex. If you're a developer, you may have noticed that when you get the linked client for a server (for example), it now returns an array.
The Master Channel
The first item in the array client[0] is always guaranteed be the master channel; its id of 0 will never change. The master channel is the initial channel opened by SubServers itself. Additionally, it is always present in the array, even if unavailable. If it does happen to be unavailable it will just simply return a null value, but it shouldn't be that way for long, since SubServers will reconnect this channel automatically.
SubChannels
Everything else in the array is a subchannel. Each subchannel is dynamically registered with a positive id number. However, this can come with its own set of problems.
Let's say we have 2 subchannels connected. If client[1] disconnects, this means the next connection to identify itself as a subchannel will get id 1 because that id is no longer in use. However, if you tried to access client[2] during the time subchannel 1 was disconnected, you would have been met with an ArrayIndexOutOfBoundsException because the position was not the same as the id number.
Since this method of tracking is clearly unreliable for use cases other than simple listing and iteration, we recommend for the opener of the channel to keep track of its own subchannel(s).