RCON
RCON is a protocol that allows server administrators to remotely execute Minecraft commands. Introduced in 1.9pre4, it's basically an implementation of the Source RCON protocol for Minecraft.
Contents
Server Config
enable-rcon=true rcon.password=<your password> rcon.port=<1-65535> broadcast-rcon-to-ops=false
The default port is 25575.
Packet Format
Integers are little-endian, in contrast with the Minecraft protocol.
Responses are sent back with the same Request ID that you send. In the event of an auth failure (i.e. your login is incorrect, or you're trying to send commands without first logging in), request ID will be set to -1.
| Field name | Field type | Notes |
|---|---|---|
| Length | int | Length of remainder of packet |
| Request ID | int | Client-generated ID |
| Type | int | 3 for login, 2 to run a command, 0 for a multi-packet response
|
| Payload | byte[] | ASCII text |
| 2-byte pad | byte, byte | Two null bytes |
Packets
3: Login
Outgoing payload: password.
If the server returns a packet with the same request ID, auth was successful (note: packet type is 2, not 3). If you get a request ID of -1, auth failed (wrong password).
2: Command
Outgoing payload should be the command to run, e.g. time set 0
0: Command response
Incoming payload is the output of the command, though many commands return nothing, and there's no way of detecting unknown commands.
The output of the command may be split over multiple packets, each containing 4096 bytes (less for the last packet). Each packet contains part of the payload (and the two-byte padding). The last packet sent is the end of the output.
Fragmentation
Maximum C->S packet payload length: 1446 (total: 1460) - outdated?
Maximum S->C packet payload length: 4096 (total: 4110)
The minecraft server can fragment responses across multiple packets. There's no simple way to know when the last response packet has been received; approaches include:
- Wait until we receive a packet with a payload length < 4096 (not 100% reliable!)
- Wait for n seconds
- Send two command packets; the second command triggers a response from the server with the same Request ID, and from this we know that we've already received the full response to the first command.
- The second packet should use a command that will not produce fragmented output
- An alternative is for the second C->S packet to use an invalid type (say, 100); the server will respond with a 'Command response' packet with its payload set to 'Unknown request 100'.
Example implementations
- https://godoc.org/github.com/Tnze/go-mc/net#RCONConn (Go, client and server)
- https://github.com/barneygale/MCRcon (python, basic, synchronous)
- https://github.com/MrReacher/async-mcrcon (python 3.5+, basic, asynchronous)
- https://gist.github.com/1292348 (php, basic, synchronous)
- https://github.com/tehbeard/node-rcon (node.js, basic, asyncronous)
- https://bitbucket.org/jyc/rcon.js (RingoJS, synchronous, BSD-licensed)
- https://bitbucket.org/jyc/rcon (PHP, synchronous, BSD-licensed)
- https://github.com/A2PLab/minelib (basic, Scala)
- https://github.com/tiiffi/mcrcon (C, synchronous, zlib/libpng License)
- https://github.com/micvbang/pocketmine-rcon (go, basic, synchronous)
- https://github.com/SommerEngineering/MinecraftServerRCONSharp (.NET/Mono, C#, thread-safe)
- https://github.com/CatCoderr/JRcon (Java, asyncronous, AGPL-3.0 license)
- https://github.com/coNQP/mcipc (python 3.6)
