Server admins often need to manage their servers, but launching Skulltag is slow and inconvenient. The RCON protocol allows us to make tools that connect to servers quickly and directly, letting administrators manage their servers with ease.
This article describes how to create RCON clients of your own that connect to Skulltag servers.
What is here?
|
Version: 3
All Skulltag servers use UDP as their network protocol. Additionally, all traffic is compressed using the Huffman algorithm to save bandwidth. Therefore, you'll need a copy of huffman.cpp or huffman.java to encode and decode your traffic appropriately.
Tips:We're using QZrcon-modifed huffman sources for Qt support.Definition of data types used in this article:
Byte: 8 bit integer (see the enumerated types below)
String: null-terminated series of Bytes
Messages that the server sends to the client always begin with one of the following bytes:
enum
{
SVRC_OLDPROTOCOL = 32, //This set of enumerations starts at 32, increments by one
SVRC_BANNED,
SVRC_SALT,
SVRC_LOGGEDIN,
SVRC_INVALIDPASSWORD,
SVRC_MESSAGE,
SVRC_UPDATE,
};
Messages that the client sends to the server always begin with one of the following bytes:
enum
{
CLRC_BEGINCONNECTION = 52, // Also increments by one
CLRC_PASSWORD,
CLRC_COMMAND,
CLRC_PONG,
CLRC_DISCONNECT,
};
Also, when the server sends SVRC_UPDATE, it's immediately followed by another byte:
enum
{
SVRCU_PLAYERDATA = 0,
SVRCU_ADMINCOUNT,
SVRCU_MAP,
};
Begin by sending two bytes to the server: CLRC_BEGINCONNECTION, followed by the protocol version you support (see above).
If you're banned by the server, you'll receive SVRC_BANNED.
If your version of the protocol is too old, you'll receive SVRC_OLDPROTOCOL, followed by the server's protocol version (byte), and the server's version string (string).
Otherwise, you'll receive the all-clear with SVRC_SALT, followed by a salt you'll use when you hash your password (string). This should be a 32 byte salt.
Now, create an MD5 hash of the provided salt, followed by the server's RCON password. You want to concatenate the salt and password together (salt first, password second), and then digest it into an MD5 hash. You have to send the hex version of the hash to the server. Send the server a packet with CLRC_PASSWORD and the hash. The pre-digested password does not need to be null-terminated.
If the password is incorrect, you'll receive SVRC_INVALIDPASSWORD.
Otherwise, you'll receive SVRC_LOGGEDIN. You're in! This is followed by the server's protocol version (byte), hostname (string) and some information on the server using the SVRC_UPDATE method described below. Basically, the server sends you the number of updates you're about to receive (byte), then the data for each one (which includes the header (SVRCU_MAP, SVRCU_ADMINCOUNT, etc), but not SVRC_UPDATE). Finally, some recent lines of the console are sent: first the number of lines (byte) followed by each line (strings).
The server will now send you information as events occur on the server.
When a new line is printed on the server console, you'll receive SVRC_MESSAGE, followed by the message (string).
Other types of updates have been streamlined a little. They all start with SVRC_UPDATE. Then...
When the map changes, it's followed by SVRCU_MAP and the new map name (string).
When the number of other RCON admins changes, it's followed by SVRCU_ADMINCOUNT and the number (byte).
When the number of players changes, or a players changes his name, you'll receive SVRCU_PLAYERDATA, followed by the number of players (byte), and each of their names (strings).
Send the server CLRC_COMMAND, followed by the command (string). This should be a console command, and the server will execute it verbatim.
By default, RCON clients not heard from within 10 seconds are timed out by the server. Therefore, you need to send the server CLRC_PONG regularly (we suggest every 5 seconds or so, to compensate for lag).
Send the server CLRC_DISCONNECT.
Happy coding!