-
Notifications
You must be signed in to change notification settings - Fork 781
Hosting an XMage server
Hosting an XMage server currently requires a bit of setup, depending on your local hardware and the intended use case. This page currently only contains the minimum steps to get an existing server installation up and running in such a way that it allows other clients to connect and play. It was written for XMage version 1.4.42V6.
This page intends to explain some of the quirks in the current server implementation and how these affect the the hosting process.
See here for a server installation guide that covers the basic installation process: https://www.slightlymagic.net/forum/viewtopic.php?f=70&t=15898
Generally, an XMage server uses two ports to manage incoming TCP connections. The primary port has to be specified in the server configuration file config.xml and has to be entered in the Client when connecting to a server. It defaults to port 17171, which is fine and should only be changed if necessary. By default, the secondary port is randomly chosen, denoted by the setting secondaryBindPort="-1" in config.xml.
The server process tells the clients the secondary port, by sending both the server hostname and secondary bind port. The client uses both of these values to connect to the secondary server port. Note that the client does use the hostname as told by the server over the initially entered address in the Client GUI. So it is crucial that this information bit returned by the server is accurate and the returned server address can be accessed by the client.
Generally, hosting a server in your private LAN is rather easy. If you have decent hardware that supports resolving host names of your devices in your network to IPs via DNS, then you are ready to go and don’t have to do much. Just start the server and connect.
But if your hardware does not support resolving local host names to IPs via DNS, you have to prepare your client computers accordingly. As explained above, XMage requires your server’s host name to be resolvable to it’s IP address via DNS. Otherwise, any connection attempts will fail. (If you wonder why it works when starting a server via the launcher: The server address localhost is always resolvable and always points to your own device.)
Your system provides a mechanism to overcome this issue: You can statically specify a list of host names (domain names) and their IP addresses in the so-called hosts file. If your client wants to connect, the system looks up the host name in this list first, before trying to use DNS. So if your host name and IP are placed in the system’s hosts file, you can connect even if your network does not provide a working DNS server.
- Configure your server to have a static IP address or configure your router to assign a static IP to your server via a static DHCP lease (Recommended way. If and how this works depends on your router model and firmware version on that device). Both ways assure that the server will always have the same IP. (Without static IPs, the entries created in the next step will become outdated and invalid after some time.)
- Add your server’s host name to the hosts file on all clients that should be able to connect: (If you are unsure how to modify your hosts file, use these steps as a general guide: https://support.rackspace.com/how-to/modify-your-hosts-file/)
- Add an entry pointing to your server IP to your hosts file:
192.168.1.123 hostname.localReplace192.168.1.123with your server’s IP address, as assigned in step 1, and replace the host namehostname.localwith the server’s actual host name. - Try to connect and look at your client log. If the client fails to connect and the log contains the following error when trying to connect to your server, adjust the hosts file accordingly: Example:
java.net.UnknownHostException: xmage.lan. Here,xmage.lanis the hostname reported by the server. The client tried to use this to connect to the server, but failed. So place<server_ip> xmage.lan(again, replace<server_ip>with the IP) into the hosts file. This’ll allow the client to connect to the server.
- Add an entry pointing to your server IP to your hosts file:
To be able to reliably host a public server behind a NAT layer, you have to adjust some settings, both in the XMage’s server settings and your hosts system settings.
- Configure your server to have a static IP address or configure your router to assign a static IP to your server via a static DHCP lease (Recommended way. If and how this works depends on your router model and firmware version on that device). Both ways assure that the server will always have the same IP. (Without static IPs, the entries created in the next step will become outdated and invalid after some time.)
- Specify a fixed secondary bind port in XMage’s
config.xml. For example, setsecondaryBindPort="17172". Use an unused port above 1024, as all ports ≤ 1024 require administrator rights. (If you use two adjacent ports, you’ll make your life a bit easier in the next step, as you can forward a port range, instead of two individual ports.) - Configure your router to forward both ports, the primary bind port (denoted as
port="17171"inconfig.xml) and the secondary bind port, as set inconfig.xml, to your server. If your router offers the choice to set the protocol family, configure the router to forward TCP connections. Use your router’s manual or online documentation to determine how to forward ports. - Acquire a globally accessible domain name via a DynDNS service (If your ISP assigns a daily-changing dynamic IP.). (For example, http://www.duckdns.org/ is a free DynDNS service.)
- Configure a machine on your network to periodically update the DNS entry. Routers running OpenWRT and AVM FritzBox devices can do this. Check your router for DynDNS support. Otherwise use the device you host your XMage server on to run the DynDNS updater script.
- Adjust the hostname of your server system to be equal to your FQDN (Fully qualified domain name). If your publicly visible domain you want to use is
xmage.dns.example.com, then set your hostname to this value. As explained above, the server uses this hostname and sends it to the client for the purpose of connecting to the secondary bind port. If you miss this and keep a name that is not globally resolvable, for examplexmage.local, then any attempted client connection from outside will fail. (This kind of issue is hard to diagnose from within your local network. To diagnose issues, use a mobile network connection or a public WiFi on a separate computer.)- If your hostname is correctly set to your outside-visible domain name, client connections will succeed.