Interserver portals

[sqrtpapi2001]

An idea/suggestion/inquiry I had after remembering dan200's now defunct mod qCraft. Very old review by direwolf20: https://m.youtube.com/watch?v=jTLb_vMVM7c

A controller could set the IP of the mod's quantum portal and admins could approve connections or even allow players total freedom in making portals to other servers. Connections were limited to servers sharing the same mods and configs. Missing items were turned into placeholders. Entities could not pass through. Just an idea but judging by just how far this project has come I would really like to see just how doable it is and how far you could take it beyond the pale (as you've already done, very impressively).

Clearly, seamless interserver transport is a level of technical complexity way, way beyond even seamless in-world teleportation. For this reason I'm sure it'd be very valuable to admins of servers who want to do hub worlds, expand the capacity of their modded servers, etc. Also curious if you ever had this in mind and what you think it would involve.

Food for thought. Really blown away by this mod. Been playing this game for many years and stuff like this keeps be captivated. ✌️

[AverageComet250]

I like this idea.

It's a complex one though and just implementing a way to grab chunks and display them, as well as kicking a player and joining them to another server, would take a while.

There's also no security in it, as there might be three servers with the mod. 1 and 2 are using this functionality together, but three is owned by some other guy. Someone on 2 might just make a portal to three and have everyone on servers one and two join it, causing server 3 to crash.

There are a few ways to fix this, but the most simple would be using a unique key that each server has and a config option to enable and disable the mod. Each server would have to get the key for another server and add it to a list in the config that manages which servers can make a connection to them.

Also, how would people make an inter-server portal different from an interdimensional portal?

[sqrtpapi2001]

In qCraft, admins had the option of either manually approving connections to server IPs with a command in-game or just letting players do whatever they wanted (also with configurations accessible via commands). The whitelist of IPs would be stored in a file in the server folder.

Now, as you're saying, a server could act as a hub between two other servers and flood one or the other with people. Obviously, once a server has reached its capacity, new players can't join, so it could be that the portals are set to shut off, or become solid to players.

Of course, more sophisticated security measures could be devised involving player and IP whitelisting, incoming connection overload, and so on. It would be fun to consider the ways people could go above and beyond the simple security of admin approved connections somehow.

On the subject of exchanging keys, it could be done so that a single secure continuous connection is handled between both servers for more sophisticated reasons, like handling the portal render, etc.

The qCraft interserver portal used a controller block called a quantum computer. A craftable block with a simple ip address GUI only makes sense.

[sqrtpapi2001]

Kicking + joining is interesting. This is obviously the simplest way but how could it be made even more seamless? Sounds insane.

[AverageComet250]

Sending a world from another server as a dimension is an option. The dimension IDs would be something like immersice_portals:<server name/IP>-<dimension (e.g. overworld)>

[qouteall]

Interserver portals require sending packets across servers, cross-server visibility check, a cross-server dimension id system, and entity transfer between servers. It's hard to implement.

[misterquestions]

If we agree on a specification maybe we can start implementing it. I'm up for it!

[Nick1st]

The idea is quite interesting, though I might want to note some things down.

• About the Idea with making different mods not matter anymore: also it's possible to replace missing stuff with placeholders, networking is a completely different story. If a mod on the client expects a package from the Server that will never arrive, it'll crash, same the other way round. So switching between servers with the same mods might be possible, but I'd take it with a grain of salt if it's possible with different sets of mods.
• I'm not sure if I do make inter server portals seethrough. That's a ton of syncing stuff.
• This will never come to the forge version. It's simply impossible on Forge because of the way the current network protocol works. The only possible way on Forge would be to completely disconnect a client from the server and then reconnect it to another server, causing the whole login procedure to occur again, which takes the next 10 minutes... So not that practical and I think there are already mods that do that.
• Syncing the player inventory and most of the other stuff would be best in an full - fledged database system. At least that's my thought on it, but I hate redundancy...
• Minecraft is generally not a good game for clustering. Many attempts show that. It was not designed for multithreading, and even giving a single dimension tick to one CPU core is often too much for the core to handle. So yeah, this might be a nice hub feature, but the portals won't allow smooth teleportation (at least on Forge) and aren't worth the effort to implement.

But I'm nevertheless open to discussing this, maybe there's something coming around I didn't think of.

[qouteall]

The first part of implementing this would be a cross-server dimension id system. We can use ip and port as the server id, then attach the server id and in-server dimension id together to get a inter-server dimension id. ImmPtl use ResourceKey<Level> for dimension id everywhere so it needs to be refactored greatly.

The most difficult part would be synchronizing data between servers and players. This involves distributed system technologies. To do network synchronization, the server must do visibility tracking: knowing which players are seeing a specific chunk or a specific entity. The hard part is that the visibility is determined by the portals near that player. If a player is in server A, and seeing a portal pointing to server B, then there are two ways to do communication:

• Server A tells server B that the player is watching your chunk
• The player asks server B to view the chunks (This is unsafe as a hacked client can view wherever it wants.)

We don't want the whole server cluster to close if only one server is closed. Then we need a mechanism to detect whether a server is closed and disable the cross-server portal in each server. There are a lot of corner cases, for example the player crossed a cross-server portal pointing to a server just closed but due to network latency the original server didn't know the target server is closed. It may require a distributed consensus framework such as Zookeeper (Or we can manually implement RAFT protocol in Minecraft).

[qouteall]

MC also uses ResourceKey<Level> for diemension id everywhere so the inter-server dimension id system would be to encode the server id into the dimension id string, such as s_1_minecraft:overworld where 1 is the server id that's allocated via the distributed consensus system. (Some vanilla mechanisms use data from mincraft:overworld which is hardcoded. We can woraround this by having a "faked" overworld dimension.)

Networking delay makes the sequence of events vary between different observers. If a player P and a player Q in different servers go to one server, someone may observe that P comes first and someone may observe that Q comes first. So all teleportation events should be handled via the consensus framework. The consensus framework should also record which server owns the latest real player information, to avoid conflicts.

[qouteall]

Currently MC uses TCP to do network synchronization to the player. TCP ensures that every message is being received in order as long as the connection is alive. The packet of unloading a chunk always comes after the packet that loads a chunk. And the packet of unloading a chunk will be reliably received, or the client will have a memory leak.

An easy way of hacking this is to make the same player to join every server and only make one player instance "real" while other player instance are temporaray disabled. The disabled player can also do network synchrnozation in the server, but the visibility is being told by other servers peroidcally. Each server sends "visibility events" to other servers to update the status that in that server a "disabled" player sees a chunk or entity in that server. If there is no visibility event given some time (for example 30 seconds) the visibility is removed.

[qouteall]

ImmPtl is already very hacky. It's possible to do more hack and achieve this, but the more hacking it is the harder to develop. It's better to rewrite Minecraft in a distributed manner.

[misterquestions]

What about creating a fake-client implementation and sending a packet to the target server that tells this is our portal fake client. The auth process might be tricky for sure. Also, we might need to hook into packet sending to whitelist only relevant packets for us, that way we avoid heavy networking that won't ever be used.

When this fake client receives the world it should update the origin server local world to ensure its up to date.

[Ironwally]

This all sounds so crazy.