Pocket Minecraft Protocol

Unlike the Minecraft protocol, this protocol uses UDP with (so far observed, at least) one message per packet. This makes the protocol easier to work with when it comes to packet serialization, and might offer latency improvements, but will inevitably have the usual UDP issues (packets lost, truncated, duplicated, out-of-order, etc.).

Old servers listen on UDP port 19132. As of the survival update, the port is different (unknown as of now) Clients don't pick any specific port to listen on.

Please note that even where packet field names are written in this page, these are still largely hypothetical and could well be incorrect guesses.

It has been determined that PM uses RakNet for its networking library, some documentation that seems relevant.

Terminology

PM

Pocket Minecraft (aka Minecraft PE or Minecraft Pocket Edition)

Types

• string: int16 length prefix, counts number of bytes following. It appears that only the following ASCII characters can be displayed: !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~

• MAGIC: constant 16 bytes of data, always hex bytes 00ffff00fefefefefdfdfdfd12345678, corresponding to RakNet's default OFFLINE_MESSAGE_DATA_ID

Packets

All packets start with a single byte that identifies the packet type, the rest of the packet follows it.

0x02 - client broadcast query

RakNet name: ID_UNCONNECTED_PING_OPEN_CONNECTIONS

client->broadcast

• int8 = 0x02 (packet type ID)
• int64 = ping ID
• MAGIC

Clients start out by sending this packet to the IP broadcast address on port 19132 repeatedly (approx once per second) when joining a server was chosen on the main screen, and stops when the user selects a server (or leaves the screen). The ping ID from the client increases over time, and appears to be the number of milliseconds since the client program was started (might be used to measure server response latency).

0x05 - mtu sizing request

RakNet name: ID_OPEN_CONNECTION_REQUEST_1

client->server

• int8 = 0x05 (packet type ID)
• MAGIC
• int8 = 0x04 (unknown meaning)
• many 0x00 bytes (bringing size of the data portion of the UDP packet up to 1464 in the initial case by this "field" being 1446 bytes long).

Sent from client after it receives packet 0x1d. The client will repeatedly send this with reducing sizes until it successfully receives a reply. Observed behaviour is that the client will send packets ~0.5s apart in the following way, until it gets a 0x06 response packet, or reaches the end of these:

• 4 packets of total data length 1464
• 4 packets of total data length 1172
• 5 packets of total data length 548

After this the client appears not to send any more packets to the server, but also doesn't (at least immediately) leave the "locating server" progress screen.

0x06 - server mtu sizing response

RakNet name: ID_OPEN_CONNECTION_REPLY_1

server->client

• int8 = 0x06 (packet type ID)
• MAGIC
• int64 = server ID? This value seems to be constant for an installation of PM, or differs between the demo and full version.
• int8 = 0 (unknown meaning)
• int16 = total bytes received in MTU sizing packet (i.e determined MTU size)

Sent from server after it receives packet 0x05.

0x07 - unknown

RakNet name: ID_OPEN_CONNECTION_REQUEST_2

client->server

• int8 = 0x07 (packet type ID)
• MAGIC
• 5 bytes - unknown meaning, only seen 0x043f57fefd
• int16 - server UDP port number (typically 19132)
• int16 - unknown, might be decided MTU size (seen values of 548, 1464 - but doesn't always match what the server sent in packet 0x06)
• int32 - unknown, only seen 0x00000000 and 0xffffffff.
• int32 - randomly-generated session ID? value changes, but the same value is seen later on.

Sent from client in response to packet 0x06.

0x08 - unknown

RakNet name: ID_OPEN_CONNECTION_REPLY_2

server->client

• int8 = 0x08 (packet type ID)
• MAGIC
• int32 - unknown, only seen 0xffffffff.
• int32 - unknown, apparently random value (need to confirm that this changes, maybe another session ID?)
• 5 bytes - unknown meaning, only seen 0x043f57fefd (same as in packet 0x07)
• int16 - client UDP port number (typically varies)
• int16 - unknown, might be decided MTU size (seen value of 548, maybe others)
• int8 - unknown, seen value 0x00 only

Sent from server in response to packet 0x07.

0x1d or 0x1c - server query response

RakNet names: ID_ADVERTISE_SYSTEM, ID_UNCONNECTED_PONG

server->client

• int8 = 0x1d (packet type ID)
• int64 = ping ID from client
• int64 = server ID
• MAGIC
• 0x[usernamelength + 5]
• string ("MCCPP;Demo;" + Host username)

Server sends this packet in response to a 0x02 packet. It may be either a 0x1d or a 0x1c, depending on version.