Forge Compatibility with Proxies (Mixins?)

[Jimmeh]

Hi guys! I currently have a project that I've been developing in a 'vanilla' environment that I'm actually looking to transfer over to Forge, simply because of how much better the experience would be using Forge. Before starting on this Forge mod, I was planning ahead and was looking at options for proxies, of which I would greatly like to use Velocity. In their docs and by asking around their Discord, they don't support support versions of Forge of 1.13 or later because of changes in the "handshake protocol". But I also really don't want to use an unsupported version of Forge, such as 1.12.2, to be able to use a proxy. I was pointed in the direction of potentially making my own client-side mod to allow Forge to be compatible with an updated proxy, such as Velocity. When asking for a direction for achieving this, I was told to have a look at how the Forge server implements logins and that the discrepancy might be with how modified the handshake protocol is. This sounds like quite the challenge to me and I'm completely up for trying to accomplish it. So for the sake of planning ahead and having a rough idea of how I could accomplish that when the time comes to work on it, has anyone else had experience with trying to achieve this? I appreciate any help or direction offered! Thanks! 

Edited January 29, 2022 by Jimmeh
More relevant title

[Jimmeh]

After briefly talking with another developer, he mentioned that "Forge syncs data before the login sequence is complete. Since you can’t reset the login phase you have no way to renegotiate that data." Apparently that's what 'breaks' the compatibility between Forge and various proxies. I asked if a Mixin could fix this behavior and he said it could in theory. So I wanted to update this thread and now ask someone has any thoughts on this / the approach I could take to accomplish this. Thanks again for any help given!

[Jimmeh]

10 minutes ago, diesieben07 said:

Coremodding Forge itself is not at all supported.

A much better solution is simply a client-side mod which connects to the new server when instructed to do so instead of trying to hack around things and try to keep the same connection.

I have implemented a proof of concept for such a mod here: https://github.com/diesieben07/serverswitchy. It's currently only 1.17.1 due to the lack of feedback that was given by the previous person I made this for.

Brilliant! Thank you so much. I've worked with vanilla-based environments for many years and am now relatively new to Forge, so it was a bit daunting of how to actually accomplish this. I'll take a good look through this project. If I have questions, do you mind if I quote/tag you in the future on this thread to pick your brain a little bit?

[Jimmeh]

Actually @diesieben07, I do have an initial question on this. When set up with a proxy, is the general 'flow' that the proxy would need to communicate with the server-side mod which would then communicate with the client-side serverswitchy-like mod? 

 

Edit: I think we just posted at the same time. haha. Your previous response answers this, I think.

Edited January 29, 2022 by Jimmeh

[Jimmeh]

17 minutes ago, diesieben07 said:

Sure, let me know if this solves your usecase.

Note that this does NOT enable BungeeCoord/Velocity, etc. It is an alternative solution.

I just had a brief look through your repo. Although Forge syntax is still a bit foreign to me, this does generally make sense. Could you elaborate a bit on what a server-side counterpart to this could look like? Just to paint a picture of what I'm imagining, I'm ideally going to use something like Kubernetes to containerize servers and will have a deployment and server-management system to expand/contract the amount of servers based on current demand. So the server-side counterpart to a serverswitchy would theoretically be a proxy. Thinking out loud here, that would determine which of the servers to send the player to out of the ones that are currently available, then relay that IP to the serverswitchy mod, correct?

[Jimmeh]

3 minutes ago, diesieben07 said:

No. ServerSwitchy simply allows a server to send a packet to a player that says "hey, go here instead". "here" being a different IP and port. The client-side mod would then display this screen and, if the player accepts or has selected "do not ask again" before, automatically connect to the different server.

No proxy or other voodoo necessary.

The server-side part is as simple as sending a custom payload packet to the players you want to switch servers. You can see this done in the included debug command of the mod here: https://github.com/diesieben07/ServerSwitchy/blob/master/src/main/java/dev/weiland/mods/serverswitchy/ServerSwitchyCommands.java#L56-L64.

Ohhhh, okay. This actually sounds much more simple than what I was thinking.

Lets say I have something like this:
                                         Join Server

Game Server A              Game Server B            Game Server C

The Join Server would have ServerSwitchy (of course, as well as the client). This server contains a collection of IPs for game servers that are currently active. So theoretically, the server-side could be listening on Forge's equivalent of a PlayerJoinEvent, have some logic to determine which game server to send them to, send the payload packet and the client-side ServerSwitchy gives them a choice to go or disconnect. Something like that?

[Jimmeh]

4 minutes ago, diesieben07 said:

It doesn't have to. You can install it to enable that debugging command, but usually whatever server-side software you have running would send the plugin message (custom payload) when it wants to transfer the player. It doesn't have to be installed for it to be used on the client.

Not sure why PlayerJoinEvent. Why would you want to send them to somewhere else immediately?

Okay, this is making more sense. And I was thinking on Player join because I suppose my mind is still in "proxy mode". haha. As in, that "Join Server" is the only server the player manually connects to, then all the other servers on the network, such as the game servers (perhaps each one representing a different region either in-game or in the world, such as US, EU, etc), are only accessible through the Join Server's transfer, so that this front, Join Server is the only one really exposed to the player. Not sure if that's the correct way to word it, but that's how it's worked in my mind the past few days I've been looking through proxies (even though I now understand this doesn't need to be a proxy).

[Jimmeh]

22 minutes ago, diesieben07 said:

If you want to do it "on login" you should be able to do it with a basic TCP-level load balancer type software, which decides (at connection time, before the player even joins the server) which server they get routed to.

The only place where you need special handling is if you want them to first join another server, then something in game happens (e.g. they select a region on a sign or whatever) and then they get transferred to a different server. This is where you can then use ServerSwitchy.

Hmmm, okay! I'll have to look into TCP-level load balancer software. That very well may be the ideal solution! Again, thanks so much for your time and help!