Proposed redux of the IP/UUID Forwarding System.

[me4502]

LexManos has come up with an alternative method of performing the IP/UUID forwarding system, that will also support much more features.

To quote LexManos,

Anyways catching, up, ya I may be persuaded to support IP/UUID forwarding, if the protocol was re-designed. As for the current fix, it doesn't take into account a FML client connecting to a FML server, it simply makes all clients 'vanilla' in Forge's eyes which could cause issues. What I would suggest, if possible is that we as a community agree to take over one of the protocol IDs and make it a server<->server communication thing where we can do things like tel what type of server it is, and what features it supports. It is simple enough because vanilla just kicks with a 'invalid protocol id' or something like that so it's easy to tell whats DOESNT support it.

[dualspiral]

Just to add my tuppence, considering I wrote the latest patch that Lex is referring to:

As for the current fix, it doesn't take into account a FML client connecting to a FML server, it simply makes all clients 'vanilla' in Forge's eyes which could cause issues

I acknowledge this in the commit. Currently, only Spigot and other vanilla implementations (such as the C++ server that's been written, I forget what it is called now) support the forwarding, so removing the FML token had no bearing on FML->FML connections (because they couldn't be done with IP forwarding, and it is only removed if IP forwarding is enabled), which is why I figured that the current patch is safe to use. However, I am painfully aware that with Sponge coming along, being (at least at first) Forge based, this has to change given the change Lex has made to Forge (which, all things considered, is actually a change that helps on the Bungee end too.)

My initial thought, given what Lex has suggested, would be to do the following:

• Add an \0IPFORWARD\0 token to the handshake, much like FML does at the moment.
  • A server expecting this, and not getting it will kick the client with a nice message
  • A client sending this, but getting a vanilla packet back will know IP forwarding isn't supported, and will disconnect from the server, again, with a nice message.
• An IP forwarding enabled server will then send a packet, like Lex has suggested, with an agreed ID. This packet will have null separated fields, much like now. The first three fields MUST be IP address, UUID and GameProfile, serialised as JSON. Futher fields can then be appended - maybe JSON with keys that indicate where that data is from (such as FML).

I don't expect what I've written is the perfect solution, but I'd hope that by giving a suggestion, it'll kick off a discussion amongst interested parties.

[minecrafter]

@dualspiral You're talking about MCServer

[maxzz88]

My suggestion is:

{"hostname":"example.com", "ip":"127.0.0.1", "uuid":"000000-00-00-0000", "profile":{json object}, "fml":true/false}

or

{"hostname":"example.com", "ip":"127.0.0.1", "uuid":"000000-00-00-0000", "profile":{json object}}\0FML\0

[kamcio96]

{ "hostname": "example.com", "ip": "127.0.0.1", "uuid": "uuidformat", "profile": "jsonobject", "forge": { "version": "1.1.1", "mods": "json list with mod's version" } } ;)

[kamcio96]

So? @md-5 @LexManos :D

[LexManos]

Sending json is not feasible as the host field has a limit in length. We would need a secondary inter-server communication protocol.

[Hackswell]

Any progress on this issue? Or is everybody still mulling it over spiced wine?

[maxzz88]

https://github.com/dualspiral/BungeeCord/tree/ip-forwarding

[dualspiral]

That was me just playing about. I'm leaving it to others.

[JBYoshi]

Here's my idea:

1. The client appends \0+ to the server IP in the handshake packet.
2. When the server sees a handshake packet ending with \0+, it responds with a server info packet, formatted in JSON. This is sent regardless of the "next state" (status or login) so the client can display the info in the server list or to use it for validation. In the case of a status ping, the server will continue to process packets per normal. However, in the case of a login, the server will wait for a client info packet.
3. When the client gets a server info packet during the login phase, it will respond with a client info packet, formatted the same way as the server info packet.

Examples of what would be sent in the server info packet:

• The server's mods/plugins
• An authentication challenge

Examples of what would be sent in the client info packet:

• The client's mods
• An authentication response
• IP forwarding data

[kamcio96]

https://github.com/kamcio96/MinecraftPlusProtocol @JBYoshi It is part of your idea :wink: