A Minecraft black hole

Lily has taken a liking to playing Minecraft, and I’ve been sucked into it as well. We have 6 computers networked together here at our home and store, so it made sense to set up a network server so we could play the game anywhere and have the same “world” to play in.

Just playing the game can be quite a time suck, but so was setting up the server. Although the game itself is quite well documented, some of the issues relating to setting up the server have poor or incorrect advice. This is often the result of formulaic answers being passed from one person to another with no understanding of how they work.

Fundamentally, Minecraft is a Java program, so when it is running on MS Windows, it shows in the task listings as java.exe or javaw.exe. The server is, however, available as either a Java program or as a native Windows executable. It turns out that the latter just invokes Java with the proper arguments to extract the Java code from the executable file itself.

When the server is first run, it writes several files to contain options, settings, and its world data. This is one place where the documentation I found was wrong. It claimed that on most systems, this information was written to the current directory, but that on Windows, it was written to the directory that contained the .exe file. This is incorrect. Although Windows gives this appearance, it is actually because when you run a .exe file from Window Explorer, the process’s current directory is set to the location of the .exe file. Thus, the program is indeed writing to its current directory (as on most other systems), but that current directory does not necessarily match the one that the program was run from. As a result you can use Shortcut files or batch script files to keep the installation location of the server code clean and store the data elsewhere. On my system (which is Windows 7) I installed the server program at Program Files (x86)\Mojang\Server alongside the client Minecraft.exe file, and the data in ProgramData\Local\Minecraft_Server.

I wanted this to run as a true server, which would be available anytime the computer was up, so I used NSSM to run the server as a proper Windows Service which you can start and stop using the Service Management console. This had the built-in ability to set the process current directory as mentioned above, and the service appears as an instance of javaw.exe running.

Next came the problem of connecting to this server from another computer. Windows Firewall to the (not) rescue. WF is itself has rather limited rules capability: You can set a default (to accept or reject) for network connections not covered by a specific rule, and the specific rules can select by IP address, port, traffic type (UDP or TCP), user, and program to decide whether to accept or reject network traffic. There is a different rule set for outbound and inbound traffic, with the former typically set to allow pretty much anything through.

It seems that when there is no specific rule for new traffic and the default rule rejects it, a “helpful” window appears on the screen asking whether the traffic should be permitted or rejected. This window would be truly helpful if it specified all the connection information (port, IP address, etc) and allowed the rule it makes to be tailored to the need. But instead, it always results in either an “allow all” or “deny all” rule for the particular program.

Problems come in when the program is a general language interpreter like Java, because this means the program identity (if any) in a rule is somewhat useless: it cannot distinguish javaw.exe running Minecraft from javaw.exe running some other (perhaps hostile) software.

You can’t make a rule to allow the Minecraft server to accept connections on port 25565 but deny all other traffic to java.exe because there is only one level of rule override. That override level cannot be used because non-Minecraft traffic will cause the “helper” will leap in and create another blanket accept or reject rule. The latter, being non-specific, would include Minecraft traffic and, were it a Reject rule, would override any Allow rule, even one with more specific criteria.

As a result of this “helper” our various computers already had an assortment of allow-all, deny-all, or no rule at all (and thus default deny) for javaw.exe.

The firewall logging also was no help. It appears that when a program accepting incoming traffic is blocked by the firewall, this happens when it first tries to accept the connections. The program is put in a sort of quarantine, and any later incoming connection attempts are treated as if no one were listening for them. This in turn means they do not appear in the firewall log as denied packets; they are just packets sent to a port no one is listening on. The quarantining of the program is not logged either. The net effect is that there is nothing in the log to explain why the incoming packets aren’t working.

This is one place where repeating of rote information flooded out any attempt I made to find help using Google. Most people who set up a server want to do this so other users (their friends, typically) can connect to their server and play with them. Trying to do this requires a whole other set of fiddling to arrange that traffic coming from the Internet at large is directed to the correct computer within their local network, none of which has anything to do with Windows Firewall.

So for now, my server has a specific rule allowing incoming TCP connections on port 25565 to the javaw.exe program (I could also make it user-specific to the user that the server is running as). Next time I try running some other Java program that wants network access, the “helper” will leap in and, depending on how I answer, put in a rule allowing any Java program to have any network traffic, or denying all such (and overriding my specific rule).

One solution for me to try is to use a feature of the file system to make a hard link to the javaw.exe file called, say, JavaForMinecraft.exe. If the server run using this file name instead of java.exe shows the alternate file name on its process, I could make a specific rule that uses this alternative program name, and rules generated by the “helper” for javaw.exe would not interfere.

Then there is a whirlpool of confusion swirling around Mojang accounts, Minecraft accounts, Windows accounts, Minecraft Profiles, and Worlds, but that might be the subject of another article.