Difference between revisions of "RCON"

From wiki.vg
Jump to navigation Jump to search
m (Removed swears)
(clarifications; formatting)
Line 1: Line 1:
RCON is a protocol introduced in 1.9pre4 for the purpose of remote administration of a server. It's basically an implementation of the Source RCON protocol for Minecraft [http://developer.valvesoftware.com/wiki/Source_RCON_Protocol]
+
'''RCON''' is a protocol that allows server administrators to remotely execute {{Minecraft Wiki|Commands|Minecraft commands}}. Introduced in 1.9pre4, it's basically an implementation of the [http://developer.valvesoftware.com/wiki/Source_RCON_Protocol Source RCON protocol] for Minecraft.
+
 
 
== Server Config ==
 
== Server Config ==
  
Line 12: Line 12:
 
== Packet Format ==
 
== Packet Format ==
  
Integers are little-endian, in contrast with the [[Protocol|Beta protocol]].
+
Integers are little-endian, in contrast with the [[Protocol|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 <code>-1</code>
+
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 <code>-1</code>.
  
 
{| class="wikitable"
 
{| class="wikitable"
|-
+
|-
! Field name
+
! Field name
! Field Type
+
! Field type
! Notes
+
! Notes
|-  
+
|-  
| Length
+
| Length
| int
+
| int
| Length of ''remainder'' of packet
+
| Length of ''remainder'' of packet
|-
+
|-
| Request ID
+
| Request ID
| int
+
| int
| Client-generated ID
+
| Client-generated ID
|-
+
|-
| Type
+
| Type
| int
+
| int
| <code>3</code> for login, <code>2</code> to run a command, <code>0</code> for a multi-packet response
+
| <code>3</code> for login, <code>2</code> to run a command, <code>0</code> for a multi-packet response
|-
+
|-
| Payload
+
| Payload
| byte[]
+
| byte[]
| ASCII text
+
| ASCII text
|-
+
|-
| 2-byte pad
+
| 2-byte pad
| byte, byte
+
| byte, byte
| Two null bytes
+
| Two null bytes
|}
+
|}
  
 
== Packets ==
 
== Packets ==
Line 51: Line 49:
 
Outgoing payload: password.  
 
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 an request ID of -1, auth failed (wrong 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 ===
 
=== 2: Command ===

Revision as of 18:09, 8 October 2016

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.

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.

Implementation details

Maximum request length: 1460 (giving a max payload length of 1446)

Code exists in the notchian server to split large responses (>4096 bytes) into multiple smaller packets. However, the code that actually encodes each packet expects a max length of 1248, giving a max response payload length of 1234 bytes.

Example implementations