Difference between revisions of "Raknet Protocol"

From wiki.vg
Jump to navigation Jump to search
Line 298: Line 298:
 
  |}
 
  |}
  
The client sends these to the target server with ever decreasing MTU until the server responds. This is used to discover the MTU size for the connection. According to the official docs, "The MTU size is the maximum size of a packet RakNet will generate", and "if you set the MTU size larger than your or any router along the network path takes, then the network will split the packet at best, or drop it at worst", so this process of sending decreasingly padded packets (compensating for the size of the packet itself and UDP overhead, which together make 48 bytes) seem to be used to discover the maximum packet size the network can handle. See the [http://www.jenkinssoftware.com/raknet/manual/programmingtips.html official documentation page] for more info about the MTU size. If the RakNet protocol does not match your own, respond with the Incompatible protocol packet.<br><br>
+
The client sends these to the target server with ever decreasing MTU until the server responds. This is used to discover the MTU size for the connection. According to the official docs, "The MTU size is the maximum size of a packet RakNet will generate", and "if you set the MTU size larger than your or any router along the network path takes, then the network will split the packet at best, or drop it at worst", so this process of sending decreasingly padded packets (compensating for the size of the packet itself and UDP overhead, which together make 46 bytes) seem to be used to discover the maximum packet size the network can handle. See the [http://www.jenkinssoftware.com/raknet/manual/programmingtips.html official documentation page] for more info about the MTU size. If the RakNet protocol does not match your own, respond with the Incompatible protocol packet.<br><br>
 
You should always respond to the first of these packets that you receive with Open Connection Reply 1, containing an MTU size of the amount of padding you received in bytes plus 46.
 
You should always respond to the first of these packets that you receive with Open Connection Reply 1, containing an MTU size of the amount of padding you received in bytes plus 46.
  

Revision as of 15:42, 26 April 2024

RakNet is a networking library used by Minecraft Bedrock Edition. You might want to also look at the documentation for the Bedrock Protocol. This is based on the old Pocket Edition Protocol Documentation and may be incomplete or outdated. The source code for the RakNet Library can be found here. RakNet uses UDP as its networking protocol. The key differences from TCP are that not all packets are guaranteed to reach the destination at all or in order (it isn't reliable) and it uses messages with a specified length instead of streams of data. RakNet compensates for the out-of-order delivery and makes it reliable.


NOTE: You may want to use an existing library if one exists for your language of choice. Here is an incomplete list. Not all of these are maintained or complete. If these are outdated you may need to change the protocol version to 11 before it can work. The protocol doesn't seem to have had any significant changes since the official implementation was discontinued in 2014, so as long as you bump the protocol version older libraries are likely to still work.

Name Description Language License Active development
go-raknet Network System used for Dragonfly written in Go Golang GPL-3 Yes
RakNet RakNet implementation written in Rust Rust GPL-3 Yes
PieRakNet Network System used for PieMC written in Python Python GPL-3 Yes
NukkitX Network Network components used within NukkitX, but with great support for general use as well Java Apache License Yes
rak-net rak-net is the first updated and fully working RakNet implementation written in Python to run a Minecraft Bedrock Edition server. This library was mainly created for Podrum, although it can be used in other projects too and can be installed via pip. Python MIT Yes
JRakNet JRakNet is a networking library for Java which implements the UDP based protocol RakNet Java MIT Yes
netty-raknet High performance implementation of RakNet for netty, following strict netty patterns. Java MIT Yes
JSRakNet JSRakNet is the first up to date and fully working raknet implementation written in Javascript to run a Minecraft PE server, designed mainly for JSPrismarine, but the implementation offers a general use Javascript MIT Yes
JRakLibPlus A library for easy creation of RakNet servers, based on RakLib and JRakLib. Java LGPL No
RakLib RakNet server implementation written in PHP. This library is very lightweight on actual implementation - it provides the bare minimum to get a Minecraft Pocket Edition server functional. It only currently provides server functionality, and does not support most RakNet features. PHP GPL Yes
raknet UDP network library that follows the RakNet protocol for Node.js Javascript MIT No
PyRakLib PyRakLib is a networking library that follows the RakNet protocol for MCPE. It is ported from the PHP library RakLib. Python GPL No
rust-raknet RakNet Protocol implementation by Rust. Rust MIT Yes
Raknet (official) The official implementation. Outdated and mostly for reference purposes. May not work with the latest Bedrock. C++ BSD No

Data types

Size (Bytes) Range Notes
byte 1 0 to 255
Long 8 -2^63 to 2^63-1 Signed 64-bit Integer
Magic 16 00ffff00fefefefefdfdfdfd12345678 Always those hex bytes, corresponding to RakNet's default OFFLINE_MESSAGE_DATA_ID
short 2 -32768 to 32767
unsigned short 2 0 to 65535
string unsigned short + string N/A Prefixed by a short containing the length of the string in characters. It appears that only the following ASCII characters can be displayed: !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
boolean 1 0 to 1 True is encoded as 0x01, false as 0x00.
address 7 or 29 1 byte for the IP version (4 or 6), followed by (for IPv4) 4 bytes for the IP and an unsigned short for the port number or (for IPv6) an unsigned short for the address family, an unsigned short for the port, 4 bytes for the flow info, 16 bytes for address and 4 bytes for scope id
uint24le 3 3-byte little-endian unsigned integer
Int 4 -2147483648 to 2147483647 Signed little-endian 32-bit Integer

Handshake sequence

  1. C→S: Open Connection Request 1
  2. S→C: Open Connection Reply 1
  3. C→S: Open Connection Request 2
  4. S→C: Open Connection Reply 2

From here on, the RakNet connection is established and all RakNet messages are contained in a Frame Set Packet.

  1. C→S: Connection Request
  2. S→C: Connection Request Accepted
  3. C→S: New Incoming Connection

Next packets should be Game Packet

Packets

Unconnected Ping

Packet ID Field Name Field Type Notes
0x01, 0x02 Time Long
MAGIC magic
Client GUID Long

This is the first RakNet message sent by the client to a RakNet server. 0x01 is sent almost every second if the client is on the server list menu and every 4-5 seconds if the client is in-game. 0x02 is only replied to if there are open connections to the server. Note: as of 0.15.6 it seems that the game refreshes it's LAN world list every 4-5 seconds, however it seems the game will still ping in 1 second intervals.
This packet should be responded to with unconnected Pong.

Unconnected Pong

Packet ID Field Name Field Type Notes
0x1c Time Long
Server GUID Long
MAGIC magic
Server ID string string Used for the MOTD. See below for details.

Unconnected Pong message is sent by the server to the client in response to the Unconnected Ping message. It contains various data that is sent to the client such as MOTD, number of players, max player count, etc. The format is given below:

Server ID string format

For Minecraft Bedrock this is separated by semicolons and uses the following format:
Edition (MCPE or MCEE for Education Edition);MOTD line 1;Protocol Version;Version Name;Player Count;Max Player Count;Server Unique ID;MOTD line 2;Game mode;Game mode (numeric);Port (IPv4);Port (IPv6);
Example:
MCPE;Dedicated Server;390;1.14.60;0;10;13253860892328930865;Bedrock level;Survival;1;19132;19133;
Result:
Server ID String Example.png
The Game mode and Game mode (numeric) values seem to not be used by the client.

Connected Ping

Packet ID Field Name Field Type Notes
0x00 Time Long

This is the first packet sent in the Encapsulated Frame Set Packet by the client to the server. It is sent with the reliability type Unreliable so it can be handled immediately by the server. It is used for calculating the average ping between the client and the server.

Connected Pong

Packet ID Field Name Field Type Notes
0x03 Ping Time Long
Pong Time Long

Connected Pong message is sent in response to the Connected Ping message with reliability type set to Unreliable so it can be handled immediately by the client.

Open Connection Request 1

Packet ID Field Name Field Type Notes
0x05 Magic MAGIC
Protocol version byte Currently 11
MTU Zero padding The MTU sent in the response appears to be somewhere around the size of this padding + 46 (28 udp overhead, 1 packet id, 16 magic, 1 protocol version). This padding seems to be used to discover the maximum packet size the network can handle.

The client sends these to the target server with ever decreasing MTU until the server responds. This is used to discover the MTU size for the connection. According to the official docs, "The MTU size is the maximum size of a packet RakNet will generate", and "if you set the MTU size larger than your or any router along the network path takes, then the network will split the packet at best, or drop it at worst", so this process of sending decreasingly padded packets (compensating for the size of the packet itself and UDP overhead, which together make 46 bytes) seem to be used to discover the maximum packet size the network can handle. See the official documentation page for more info about the MTU size. If the RakNet protocol does not match your own, respond with the Incompatible protocol packet.

You should always respond to the first of these packets that you receive with Open Connection Reply 1, containing an MTU size of the amount of padding you received in bytes plus 46.

Open Connection Reply 1

Packet ID Field Name Field Type Notes
0x06 Magic MAGIC
Server GUID Long
Use security? boolean If true, a cookie can be specified after to prevent source IP spoofing
Cookie Int Only if use security; a cookie to be sent back by the client in Open Connection Request 2
MTU short see Open Connection Request 1

Open Connection Request 2

Packet ID Field Name Field Type Notes
0x07 Magic MAGIC
Server Address address
Cookie Int Only present if a cookie was provided by the server in Open Connection Request 1
Client supports security boolean Only present if a cookie was provided by the server in Open Connection Request 1 and always false for the vanilla client
MTU short
Client GUID Long

Open Connection Reply 2

Packet ID Field Name Field Type Notes
0x08 Magic MAGIC
Server GUID Long
Client Address address
MTU short
Encryption enabled? boolean

Connection Request

Packet ID Field Name Field Type Notes
0x09 GUID Long
Time Long
Use security? boolean

Connection Request Accepted

Packet ID Field Name Field Type Notes
0x10 Client address address
System index short Unknown what this does. 0 works as a value.
Internal IDs 10x address Unknown what these do. 255.255.255.255:19132 for all of them seems to work, any other address will probably work as well.
Request time Long
Time Long

New Incoming Connection

Packet ID Field Name Field Type Notes
0x13 Server address address
Internal address 20x address Unknown what this is used for.
Incoming Timestamp Long
Server Timestamp Long

Disconnect

Packet ID
0x15

Incompatible Protocol

Packet ID Field Name Field Type Notes
0x19 Protocol byte
Magic MAGIC
Server GUID Long

Unconnected Ping

Packet ID Field Name Field Type Notes
0x01, 0x02 Time Long
GUID Long

Frame Set Packet

Packet ID Field Name Field Type Notes
0x80..0x8d Sequence number uint24le
Frames Flags byte Top 3 bits are reliability type, fourth bit is 1 when the frame is fragmented and part of a compound.
Length IN BITS unsigned short Length of the body in bits.
Reliable frame index uint24le only if reliable
Sequenced frame index uint24le only if sequenced
Order Ordered frame index uint24le only if ordered
Order channel byte
Fragment Compound size int only if fragmented
Compound ID short
Index int
Body ceil(length/8) bytes

The reliability types are as follows:

ID Name Reliable Ordered Sequenced
0 unreliable
1 unreliable sequenced x x
2 reliable x
3 reliable ordered x x
4 reliable sequenced x x x
5 unreliable (+ ACK receipt)
6 reliable (+ ACK receipt) x
7 reliable ordered (+ ACK receipt) x x

Sequenced implies ordered.

Game Packet

Packet ID Field Name Field Type Notes
0xfe Body bytes Single packet of the GAME protocol. The packet is usually compressed.

NACK

Packet ID Field Name Field Type Notes
0xa0 Record count short
Record Single Sequence number? boolean False for range, True for no range
No Range Sequence number uint24le Number of sequence to not acknowledge
Range Start Sequence number uint24le
End Sequence number uint24le

ACK

Packet ID Field Name Field Type Notes
0xc0 Record count short
Record Single Sequence number? boolean False for range, True for no range
No Range Sequence number uint24le Number of sequence to acknowledge
Range Start Sequence number uint24le
End Sequence number uint24le