ServerToServer
Configuring multiple servers to allow players to teleport between them is a complex topic. The Transporter plugin provides many options that allow complex configurations. The scenarios presented below build in complexity starting with the simplest first. In all the examples, the IP addresses used are for illustrative purposes only and don't represent actual servers on the Internet, so you'll need to substitute your own addresses where necessary. Anywhere a literal IP address is used, an Internet host name can also be used, if available.
All the commands shown are assumed to be entered in the Minecraft server console on the indicated server.
No matter what scenario is applicable to your situation, it's recommended you read through Scenario 1 since a lot of the basics are covered there. All the other scenarios are built on the same ideas.
In all the diagrams, the orange lines represent network connections between instances of the plugin running on each Minecraft server, and green lines represent normal network connections between Minecraft clients and servers. Solid, dashed, and dotted lines are used to distinguish between different connections of the same type.
Forum user Mathew Alden has been kind enough to create a video which explains some this material (this is a new video for v8.13 of the plugin): https://www.youtube.com/watch?v=fUWYQxL0_MU
Before getting to far into how to get this working, you need to understand how Transporter works between servers.
The basic idea is that the Transporter plugin on each server connects to the Transporter plugin on the other servers. This is a dedicated connection for use solely by Transporter and has nothing to do with connected players. A player should never connect to the address/port Transporter is listening on, and Transporter should never connect to the address/port your Minecraft server is listening on. The two are separate. Keep that straight in your head. This connection carries the "plugin traffic" shown in the diagrams below.
The port Transporter listens on MUST BE DIFFERENT than the port your Minecraft server listens on. By default, your Minecraft server listens on port 25565 and Transporter listens on port 25555. To change the port Transporter listens on, see the Network page and look for the "listenAddress" option.
When properly configured on two servers, the Transporter plugins on those servers will connect to each other and trade all sorts of information about each other. When this connection is established, the servers are "connected" and the act of linking gates between servers can begin. If the servers are not connected, THERE IS NO POINT TRYING TO LINK GATES BETWEEN SERVERS. This is because some of the information traded over this connection is the names of all the gates on each server. You can't link gates between servers if the gate names you want to use are not known because they haven't been traded.
Before you jump into configuring server connections you need to understand some basic networking concepts:
- What is an IP address and hostname?
- What is a port number?
- What is a network socket?
- How does a firewall work?
If you don't know the answers to all of those questions, you need to either find someone to help you, take a networking class, or start reading some books about networking. If you can't answer some of the questions or you're a little fuzzy on the concepts, I can promise that you'll find the rest of this page difficult to grasp.
This is the simplest multiserver configuration. Both servers are directly connected to the Internet and users can connect directly to either server by simply entering a server's IP address and port in their Minecraft client. This scenario also requires a ClientPatch to be installed on every client that plays on the servers.
- IP address: 200.10.20.30
- Minecraft port: 25565 (default)
- Transporter plugin port: 25555 (default)
- Transporter plugin key: server1Key
- IP address: 200.10.30.40
- Minecraft port: 25565 (default)
- Transporter plugin port: 25555 (default)
- Transporter plugin key: server2Key
On Server1, enter the following commands in the server console:
trp network set key server1Key trp server add server2 200.10.30.40 server2Key
The commands do the following:
- The first command sets Server1's plugin key. The key is used to identify this server to other servers when the plugin connects to those other servers. The key should be treated as a password and be reasonably hard to guess. Unlike a password, however, you'll need to share the key with the admin of any other server you'll be connecting to. After setting the key, the network portion of the plugin will automatically reload.
- The second command adds a connection to Server2. The first argument after the "add" keyword is the name we're giving the other server. This name can be almost anything, is private to Server1, and is used when referring to remote gates on Server2. The next argument is the address of the plugin running on the other server, so if the other plugin wasn't running on the default port of 25555, you would need to append a colon and the alternate port number to the IP address. The last argument to this command is the other server's key. Because there is no fourth argument to specify the address of the Minecraft server itself, the plugin address is used, but with the default Minecraft port.
After issuing the commands, you should see messages on the console about failed connection attempts to Server2. This is normal since Server2 hasn't been configured to accept the connections. The connection attempts are repeated about once a minute (by default) and will continue until either a successful connection is made or the configured server is either disabled or removed.
To see a list of configured servers on Server1, use the trp server list command. You should see something like this:
10:46:40 [INFO] [Transporter] 1 servers: 10:46:40 [INFO] [Transporter] server2: 200.10.30.40 'server2Key' up/down 10:46:40 [INFO] [Transporter] publicAddress: * (*:25565) 10:46:40 [INFO] [Transporter] privateAddress: * (200.10.20.30:25565)
Each server in the resulting list shows the following information:
- the name you've given to the server, "server2"
- the server's plugin address and port, "200.10.30.40" (remember, this is the address and port of the plugin on the other server)
- the server's key, "server2Key"
- the server's enabled state, "up"
- the server's connection state, "down"
The last two items, "up/down", are critical to getting servers connected. The ultimate goal is make these read "up/up", which means a functioning connection exists to the other server. Right now, the connection is not "up" because the other server is not accepting connections yet. That will be handled very soon.
Under this basic information there are 2 additional bits of information:
- publicAddress: this is the address Server1 will tell clients to connect to when they teleport to Server2. In this scenario, it's "*", which means teleport to the same address as the plugin on that server (200.10.30.40), and the default Minecraft server port (25565).
- privateAddress: this is the address of the Server1's Minecraft server that we'll tell Server2 to send players to when they teleport to Server1 when Server2 detects the player is behind the same firewall as Server1, if any. In this scenario, it's "*", which means teleport to Server1's IP address (200.10.20.30), and the port Server1's Minecraft server is listening on (25565, from the server.properties file). Since there's no firewall in this scenario, ignore this.
Now, on to Server2:
trp network set key server2Key trp server add server1 200.10.20.30 server1Key
The commands mirror the commands from Server1, but the addresses, names, and key are different.
Soon after executing the last command, a successful connection between the two servers should be made. If a connection isn't made, there should be information displayed in the console about what's not working.
If you run the trp server list command on Server1 again, you'll see something like:
10:46:40 [INFO] [Transporter] 1 servers: 10:46:40 [INFO] [Transporter] server2: 200.10.30.40 'server2Key' up/up outgoing 200.10.30.40/76537 v7.0 10:46:40 [INFO] [Transporter] publicAddress: * (*:25565) 10:46:40 [INFO] [Transporter] privateAddress: * (200.10.20.30:25565) 10:46:40 [INFO] [Transporter] remotePublicAddress: 200.10.30.40:25565 10:46:40 [INFO] [Transporter] remotePrivateAddress: 200.10.30.40:25565 10:46:40 [INFO] [Transporter] remoteCluster: -
The output you see might be different from above in a couple of ways:
- the connection direction might be "incoming" rather than "outgoing"; connections between servers can be initiated from either direction based on timing and other factors
- the port number at the end of the second-to-last field will almost certainly be different because of the way network sockets work; don't worry that it doesn't match any of the port numbers you've configured
Remember those two important items in this line? They now read "up/up", which means a functional connection between the servers has been made, which was the goal.
The end of the main server line displays the version of the plugin running on the remote server. There are also 3 additional fields under the server line:
- remotePublicAddress: this is the address we received from Server2 as its advertised public address and port. This is the address we'll tell a client to reconnect to when they teleport to Server2.
- remotePrivateAddress: this is the address we received from Server2 as its advertised private address and port. This is the address we'll tell a client to reconnect to when they teleport to Server2 and we detect they're behind the same firewall as Server2. Since there's no firewall in this scenario, ignore this.
- clusterName: this is the cluster Server2 belongs to. The plugin doesn't support true clustering yet so ignores this field.
Now that you have the two servers connected, you can link gates between them. See the Gates page for more information.
You can test a server connection by using the trp server ping server1 command. A ping message will be sent to the named server and, assuming a response is received, the round trip time will be displayed. This ping is not a normal, ICMP ping packet. It only works when the servers are successfully connected.
Sometimes a server you've added becomes non-responsive or goes offline for a while. Your server will continue to attempt to connect to the afflicted server about once a minute (by default). This generates messages on the console which can be bothersome. There are a couple of things you can do to eliminate the messages. You can disable a server without removing it to prevent the connection attempts and corresponding messages. Use the trp server disable server1 command to accomplish this. Use the trp server enable server1 to re-enable the server and begin trying to connect again.
The other way to get rid of the messages is to set the plugin's "suppressConnectionAttempts" network option using the command trp network set suppressConnectionAttempts 2. The value of this option determines the number of connection failure messages to display before suppressing them. A value of -1 (the default) means to never suppress them. Each server keeps track of its own connection failures and the count is reset to 0 after a successful connection.
If your server is logging messages about incoming connection requests from unknown sources (maybe someone is trying to hack you?), you can add the offending source addresses to a ban list so the plugin will ignore the requests. Use the trp server ban add ... command to accomplish this. The command takes as an argument a regular expression that will be used to test the source IP during a connection request. If a match is found, the connection is rejected. You can use the command multiple times to add multiple patterns to match against. Likewise, use the trp server ban remove ... command to remove a pattern from the list, and the trp server ban list to see the contents of the list.
See the Commands page for more information on all the available server and network related commands.
This scenario is similar to the first, but the two Minecraft servers are co-hosted on the same computer, so share the same IP address. Like the first scenario, this requires a ClientPatch.
- IP address: 200.10.20.30
- Minecraft port: 25565 (default)
- Transporter plugin port: 25555 (default)
- Transporter plugin key: server1Key
- IP address: 200.10.20.30
- Minecraft port: 25566 (non-default)
- Transporter plugin port: 25556 (non-default)
- Transporter plugin key: server2Key
On Server1, enter the following commands in the server console:
trp network set key server1Key trp server add server2 localhost:25556 server2Key
The commands are very similar to the commands in the first scenario, but the plugin address in the second command now points to the same host and the non-default port the plugin will be listening on in the second server.
On Server2, enter the following commands in the server console:
trp network set listenAddress *:25556 trp network set key server2Key trp server add server1 localhost:25555 server1Key
The first command is new and tells the plugin to listen for incoming connections from other Transporter plugins on all the local addresses (indicated by the asterisk), but the non-default port of 25556.
Like the second command for Server1, the third command for Server2 points to the same host, but specifies the default plugin port of 25555 (since we didn't change the listen address of the plugin on Server1).
Soon after executing the last command, a successful connection between the two servers should be made. If a connection isn't made, there should be information displayed in the console about what's not working.
This important difference between this scenario and the first is the requirement for the different listenAddress on the second server. This is necessary because because TCP/IP networking does not allow two processes on the same host to listen on the same port.
This scenario is common for service providers who don't want to require their users install a client patch. It makes use of another piece of software called a proxy. This software runs as a server process and handles connections from players, passing those connections to multiple Minecraft servers in a "cluster". Players connect to the proxy and not directly to the Minecraft servers. This scenario makes use of proxy software called http://www.spigotmc.org/threads/bungeecord.392/. Installing and configuring the proxy software is beyond the scope of this discussion; see the documentation for the proxy software.
- IP address: 200.10.20.30
- Listen port: 25565
- Servers: server1, server2
- IP address: 200.10.20.30
- Minecraft port: 25501
- Transporter plugin port: 25601
- Transporter plugin key: server1Key
- IP address: 200.10.20.30
- Minecraft port: 25502
- Transporter plugin port: 25602
- Transporter plugin key: server2Key
After configuring the proxy and Minecraft servers as directed in the proxy documentation, configure the Transporter plugin on each server.
On Server1, enter the following commands in the server console:
trp network set key server1Key trp network set listenAddress *:25601 trp network set clusterName cluster trp network set bungeeServer server1 trp server add server2 localhost:25602 server2Key
Again, the commands should be familiar, but the third and fourth commands are new. The third command sets the server's cluster name to "cluster". You can set the server's cluster name to anything you want; the important thing is that is must match the cluster name used on all the other servers behind the same proxy. The fourth command sets the name of this server as configured in the proxy software. It must match exactly what's in the proxy's configuration.
On Server2, enter the following commands in the server console:
trp network set listenAddress *:25602 trp network set key server2Key trp network set clusterName cluster trp network set bungeeServer server2 trp server add server1 localhost:25601 server1Key
This is basically the same as on Server1, but the port numbers are different as is the bungeeServer setting.
Like the other scenarios, soon after executing the last command, a successful connection between the two servers should be made. If a connection isn't made, there should be information displayed in the console about what's not working.
After some gates are linked between the servers (using the standard methods as described in Gates), when a player steps into a gate on Server1, Transporter will tell the proxy to reconnect them to Server2. The player notice a reconnect and step out of the gate on Server2. Since the proxy is handling the reconnect, no client patch is necessary.
This scenario can be extended to host more Minecraft servers, even servers on different hosts behind the proxy.
This scenario builds on the first by moving the servers behind a firewall and adding an additional player who is also behind the firewall. Also, both servers will be co-hosted on the same computer. This is common when running a Minecraft server at home over a broadband connection. Like the first scenario, this requires a ClientPatch.
- IP address: 192.168.0.2
- Minecraft port: 25565 (default)
- Transporter plugin port: 25555 (default)
- Transporter plugin key: server1Key
- IP address: 192.168.0.2
- Minecraft port: 25566 (non-default)
- Transporter plugin port: 25556 (non-default)
- Transporter plugin key: server2Key
- Public IP address: 200.10.30.40
- Private IP address: 192.168.0.1
- Forward port 25565 to 192.168.0.2:25565 (for MC client connections)
- Forward port 25566 to 192.168.0.2:25566 (for MC client connections)
- IP address: 210.0.0.10
- IP address: 192.168.0.5
Before configuring the plugin, make sure both Minecraft servers are running correctly by having both players connect to each server. This will ensure the firewall is forwarding traffic correctly and the Minecraft servers are listening on different ports. DO NOT PROCEED if both players can't connect to both servers. No amount of fiddling with the plugin will make things work if the players can't connect.
On Server1, enter the following commands in the server console:
trp network set key server1Key trp server add server2 192.168.0.2:25556 server2Key trp server set server2 publicAddress "192.168.0.2/^192\.168\.0\..* 200.10.30.40:25565"
The commands are very similar to the commands in the first scenario, but the plugin address in the second command now points to the same host and the non-default port the plugin will be listening on in the second server.
NOTE: This feature has not been extensively tested so if you're having problems using it, let the plugin author know in the support forum.
The last command is also new and sets the "publicAddress" option of the newly added server. This is the address we tell Server2 to send clients to when they teleport to Server1. This is necessary because connections to Server1 could be from both the private 192.168.0.0 network and the public Internet. We need to tell each of these classes of client (public or private) a different address to connect to. The address is a space separated list of items:
- item 1: 192.168.0.2/^192\.168\.0\..*
- item 2: 200.10.30.40:25565
The first item is composed of a slash (/) separated list of components. The first component in this list ("192.168.0.2") is the address the client should connect to. The second (and subsequent components, if any) are regular expressions to match against the client's IP address. If a match is found, the address in the first component is sent to the client as the address to connect to when a player teleports from Server2 to Server1. The regular expression will match any clients in the same 24 bit subnet as Server1, namely Player2.
The second item is interpretted the same way as the first, but since it doesn't include any regular expressions, it implicitly matches any client address. So any client that doesn't match the regular expression[s] in the first item (e.g., Player1) will be told to connect to 200.10.30.40:25565 when teleporting from Server1 to Server2.
On Server2, enter the following commands in the server console:
trp network set listenAddress *:25556 trp network set key server2Key trp server add server1 localhost:25555 server1Key trp server set server1 publicAddress "192.168.0.2:25566/^192\.168\.0\..* 200.10.30.40:25566"
The first command is new and tells the plugin to listen for incoming connections from other Transporter plugins on all the local addresses (indicated by the asterisk), but the non-default port of 25556.
Like the second command for Server1, the third command for Server2 points to the same host, but specifies the default plugin port of 25555 (since we didn't change the listen address of the plugin on Server1).
The last command is similar to the last command for Server1 and sets the "publicAddress" option for the server. The only differences are the addresses that will be reported to clients because those addresses must correspond to Server2.
After the plugins connect to each other, the output of trp server list on Server1 will look something like:
15:42:56 [INFO] [Transporter] 1 servers: 16:46:00 [INFO] [Transporter] server2: localhost:25556 'server2Key' up/up incoming 127.0.0.1/62432 v7.0 16:46:00 [INFO] [Transporter] publicAddress: 192.168.0.2/^192\.168\.0\..* 200.10.30.40:25565 (192.168.0.2:25565/^192\.168\.0\..* 200.10.30.40:25565) 16:46:00 [INFO] [Transporter] privateAddress: * (192.168.0.2:25565) 16:46:00 [INFO] [Transporter] remotePublicAddress: 192.168.0.2:25566/^192\.168\.0\..* 200.10.30.40:25566 16:46:00 [INFO] [Transporter] remotePrivateAddress: 192.168.0.2:25566 16:46:00 [INFO] [Transporter] remoteCluster: -
This scenario is like the last but moves one of the servers outside the firewall to the public Internet. Like the first two scenarios, this requires a ClientPatch.
- IP address: 200.10.20.30
- Minecraft port: 25565 (default)
- Transporter plugin port: 25555 (default)
- Transporter plugin key: server1Key
- IP address: 192.168.0.2
- Minecraft port: 25565 (default)
- Transporter plugin port: 25555 (default)
- Transporter plugin key: server2Key
- Public IP address: 200.10.30.40
- Private IP address: 192.168.0.1
- Forward port 25565 to 192.168.0.2 (for MC client connections)
- Forward port 25555 to 192.168.0.2 (for Transporter plugin connections)
- IP address: 210.0.0.10
- IP address: 192.168.0.5
On Server1, enter the following commands in the server console:
trp network set key server1Key trp server add server2 200.10.30.40 server2Key
On Server2, enter the following commands in the server console:
trp network set key server2Key trp server add server1 200.10.20.30 server1Key
Notice these commands are identical to the commands used in the first scenario.
This configuration uses a plugin feature new in v7.0 and above: NAT detection. When Player2 is on Server2 and teleports to Server1, everything works normally. But when the player tries to teleport back to Server2, something different happens. Server1 sees the IP address of Server2 as 200.10.30.40. It sees the IP address of Player2 as the same address. When this happens, Server1 tells Player2 to connect the "privateAddress" Server2 sent to Server1 when they first connected (shown as "remotePrivateAddress" in Server1's server list). By default, this address will be the actual IP address of Server2, or 192.168.0.2. This results in Player2 being told to connect directly to Server2 on the private network.
If necessary, the "privateAddress" a server announces to other servers can be changed; it's a server option, which means it can be changed for each connected server. Setting the "privateAddress" option for a server to "-" means "don't send a private address", which disables the NAT detection on the remote server. See the [Servers] page for more information about the available options and values.