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.).

Servers listen on UDP port 19132. 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.

Types

• string: int16 length prefix, counts number of bytes following. So far only ASCII bytes have been seen, but might not be restricted to ASCII.

• MAGIC: constant 16 bytes of data, always hex bytes 00ffff00fefefefefdfdfdfd12345678.

Packets

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

0x02 - client broadcast query

• 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

• 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 or less).

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

• int8 = 0x06 (packet type ID)
• MAGIC
• int64 = server ID
• 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

• 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 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

• int8 = 0x08 (packet type ID)
• MAGIC
• unknown data (18 bytes long in observed example)

Sent from server in response to packet 0x07.

0x1d - server query response

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

Server sends this packet in response to a 0x02 packet.