RCON clients in Go
As part of our continued efforts to make game server hosting easier, we recently built and released into the wild a series of RCON clients for popular game RCON protocols as open source on Github.
Go makes writing these things particularly satisfying as its standard library includes a whole bunch of networking code that is nice and simple to use. We built these clients because we want to have our hosting management software able to communicate with the actual games it manages so it can both monitor them for information (like player counts) and also ask them to shutdown cleanly (for games that don’t cleanly shutdown when they receive the TERM signal and instead potentially corrupt any open files they are writing to). While there are many, many different game protocols out there, many games tend to use one of the following:
We also implemented a specific client just for TeamSpeak, since it is very popular.
How do I use them?
Examples of basic usage can be found on the Github pages linked above. The clients for A2S and BattlEye are designed to be as basic as possible and know basically nothing about what they might be talking to. There are no wrappers and convenience methods for known commands for game X or server Y, instead the clients provide a simple interface to talking directly at the protocol level to allow you to use them for any game or server that speaks that language. To copy the example code from the BattlEye client, it’s quite simple:
The code above is near identical for the A2S client and you can see it is very simple to just send a command to the server and receive a response.
The TS3 client works a little differently because it is a specific client for a specific server. In this case, we provide methods for each command rather than just a raw protocol client. The full documentation is available via the Github page, but a short example demonstrates just how simple it is to use:
How do YOU use them?
Well now, that would be telling…
Oh okay then, I’ll give you a brief overview. As mentioned above, being able to nicely shutdown servers that maintain a lot of writable open files so we don’t cause corruption on process termination is pretty important. No-one likes to log into their Minecraft server after restarting it and find that their entire world is just gone.
To facilitate this, our ClanForge server management platform does a number of checks and controls around how it communicates with the servers it is managing and how it shuts them down. Here’s a snippet from one of our core management services on exactly how it does that:
The example above is taken from a function that gets executed whenever a stop request is actioned (i.e. shutting down the game server) on a managed server.
On the first line, we grab a client using the identifier for the game we’re trying to operate on. We’ve written a number of game-specific clients that build on top of the basic protocol libraries we’ve open sourced that are all registered at compile time against their game identifiers. If we don’t have a client for that game, then we return early. Not every game needs a client and if it doesn’t have one, we just carry on as normal.
However, if we do have a client, and that client supports the PreStop hook — a hook we define as meaning “things that need to be done before the process is forcibly terminated” — then we let our other management processes know that a stop is expected so they don’t think the game just crashed and try to restart it. Assuming that all goes well, we execute our clients’ PreStop hook to run through all the things we need to ensure your server doesn’t break anything when/if we force it to shutdown later, then we wait for it to exit gracefully and resort to hard terminating it if it takes too long.
PreStop for most servers involves the basic steps of:
- Tell the players they are going to be disconnected
- Wait for a bit to give them a chance to finish whatever they are doing in game
- Kick all the players from the server
- Tell the game to save any data to disk it might have in memory
- Tell the game to shutdown
Simples!
We hope you find our RCON clients useful and we look forward to hearing about how you’re using them and seeing contributions from the open source community.
