Considering Glowstone now supports the proxy data from Bungee, it is only reasonably fair to support the proxy data from LilyPad as well.
Note: LilyPad does not use plugin messages to transfer information between servers, unlike Bungee. Supporting this data is out of scope for Glowstone but is still explained at the end of this ticket.
The major difference between the Bungee data and the LilyPad data is that the Bungee data is terminated by NUL while LilyPad uses a JSON string. Both still use the same field on the handshake packet though, so that's something that's easy to work with.
For a visual representation, Bungee data would look something like this:
localhost\0127.0.0.1\0c465b1543c294dbfa7e3e0869504b8d8\0[{"name":"textures","value":"...","signature":"..."}]
...or in a more readable breakdown...
Hostname \0 IP Address \0 UUID \0 [JSON array of properties]
This varies from LilyPad quite a lot, as LilyPad data would look something like this (for the same player):
{"h":"localhost","rIp":"127.0.0.1","rP":25565,"n":"turt2live","u":"c465b1543c294dbfa7e3e0869504b8d8","s":"...","p":[{"n":"textures","v":"...","s":"..."}]}
As you can see, it's very different. LilyPad adds additional fields that Bungee doesn't have: Port number, player name, and a "secret" (s). The secret is used for internal operations to verify that the server being connected to is a valid Minecraft server on the proxy network.
Glowstone won't need to (and shouldn't) support the handling of the secret, but it should at least be made decently accessible for the LilyPad author(s) so that we can avoid getting in the way of their workflow.
Additionally, it should be noted that the "properties" format sent by LilyPad varies significantly.
The remainder of this ticket is a description on how LilyPad doesn't use plugin messages. Feel free to skip.
LilyPad operates off of 3 roles: Proxy, Server, and Connect. The "Connect" role is a central server that handles the various incoming connections and routes them as needed. The "Proxy" role is the server you connect to with your Minecraft client. The "Server" role is, in this case, Glowstone.
On the Minecraft server is a plugin that, currently, reflects into the server to modify it's packet handling so that the server can read the proxy data correctly. As it currently stands, LilyPad's plugin only supports CraftBukkit servers due to it's heavy use of the NMS Netty implementation. The plugin also spins up a second thread for communicating to Connect (the server that manages the connections). This connection allows for the servers to talk to each other without piggybacking on a player, but also means that Glowstone has no logical reason to initiate that connection internally. The plugin can continue to handle it's connection to Connect.
LilyPad does implement it's own protocol for handling cross-server (or cross-role as it would be called in LilyPad) communications and has a fairly extensive API to support it. Seeing as it runs on a different port (and different connection) to Minecraft means that Glowstone has no reason to support it, and therefore the LilyPad author(s) can handle their own protocol through use of a plugin (like they currently do) or however else they decide to handle it.
Considering Glowstone now supports the proxy data from Bungee, it is only reasonably fair to support the proxy data from LilyPad as well.
Note: LilyPad does not use plugin messages to transfer information between servers, unlike Bungee. Supporting this data is out of scope for Glowstone but is still explained at the end of this ticket.
The major difference between the Bungee data and the LilyPad data is that the Bungee data is terminated by
NUL
while LilyPad uses a JSON string. Both still use the same field on the handshake packet though, so that's something that's easy to work with.For a visual representation, Bungee data would look something like this:
localhost\0127.0.0.1\0c465b1543c294dbfa7e3e0869504b8d8\0[{"name":"textures","value":"...","signature":"..."}]
...or in a more readable breakdown...Hostname \0 IP Address \0 UUID \0 [JSON array of properties]
This varies from LilyPad quite a lot, as LilyPad data would look something like this (for the same player):
{"h":"localhost","rIp":"127.0.0.1","rP":25565,"n":"turt2live","u":"c465b1543c294dbfa7e3e0869504b8d8","s":"...","p":[{"n":"textures","v":"...","s":"..."}]}
As you can see, it's very different. LilyPad adds additional fields that Bungee doesn't have: Port number, player name, and a "secret" (
s
). The secret is used for internal operations to verify that the server being connected to is a valid Minecraft server on the proxy network.Glowstone won't need to (and shouldn't) support the handling of the secret, but it should at least be made decently accessible for the LilyPad author(s) so that we can avoid getting in the way of their workflow.
Additionally, it should be noted that the "properties" format sent by LilyPad varies significantly.
The remainder of this ticket is a description on how LilyPad doesn't use plugin messages. Feel free to skip.
LilyPad operates off of 3 roles: Proxy, Server, and Connect. The "Connect" role is a central server that handles the various incoming connections and routes them as needed. The "Proxy" role is the server you connect to with your Minecraft client. The "Server" role is, in this case, Glowstone.
On the Minecraft server is a plugin that, currently, reflects into the server to modify it's packet handling so that the server can read the proxy data correctly. As it currently stands, LilyPad's plugin only supports CraftBukkit servers due to it's heavy use of the NMS Netty implementation. The plugin also spins up a second thread for communicating to Connect (the server that manages the connections). This connection allows for the servers to talk to each other without piggybacking on a player, but also means that Glowstone has no logical reason to initiate that connection internally. The plugin can continue to handle it's connection to Connect.
LilyPad does implement it's own protocol for handling cross-server (or cross-role as it would be called in LilyPad) communications and has a fairly extensive API to support it. Seeing as it runs on a different port (and different connection) to Minecraft means that Glowstone has no reason to support it, and therefore the LilyPad author(s) can handle their own protocol through use of a plugin (like they currently do) or however else they decide to handle it.
PS: Shoutout to @coelho :heart: