Difference between revisions of "Pocket Minecraft Protocol"

From wiki.vg
Jump to navigation Jump to search
(Enhancement)
(New packets, field names)
Line 71: Line 71:
 
| class="col4" | Notes
 
| class="col4" | Notes
 
|- class="row1"
 
|- class="row1"
| class="col0 centeralign" rowspan="7" | 0x02
+
| class="col0 centeralign" rowspan="3" | 0x02
 
| class="col1 centeralign" | Ping ID
 
| class="col1 centeralign" | Ping ID
 
| class="col2 centeralign" | int64
 
| class="col2 centeralign" | int64
Line 102: Line 102:
 
| class="col4" | Notes
 
| class="col4" | Notes
 
|- class="row1"
 
|- class="row1"
| class="col0 centeralign" rowspan="7" | 0x05
+
| class="col0 centeralign" rowspan="4" | 0x05
 
| class="col1 centeralign" | MAGIC
 
| class="col1 centeralign" | MAGIC
 
| class="col2 centeralign" | MAGIC
 
| class="col2 centeralign" | MAGIC
Line 108: Line 108:
 
| class="col4" |  
 
| class="col4" |  
 
|- class="row2"
 
|- class="row2"
| class="col0 centeralign" | Version
+
| class="col0 centeralign" | Protocol Version
 
| class="col1 centeralign" | byte
 
| class="col1 centeralign" | byte
 
| class="col2 centeralign" | <code>5</code>
 
| class="col2 centeralign" | <code>5</code>
| class="col3" | Protocol version, currently 5
+
| class="col3" | Currently 5
 
|- class="row2"
 
|- class="row2"
 
| class="col0 centeralign" | Null Payload
 
| class="col0 centeralign" | Null Payload
Line 121: Line 121:
 
| class="col1 rightalign" colspan="4" | 18 Bytes + lenght of Null Payload
 
| class="col1 rightalign" colspan="4" | 18 Bytes + lenght of Null Payload
 
|}
 
|}
 +
If the version is different than yours, reply with a
 +
[[#0x1A|ID_INCOMPATIBLE_PROTOCOL_VERSION (0x1A)]
  
 
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:
 
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:
Line 143: Line 145:
 
| class="col4" | Notes
 
| class="col4" | Notes
 
|- class="row1"
 
|- class="row1"
| class="col0 centeralign" rowspan="7" | 0x06
+
| class="col0 centeralign" rowspan="5" | 0x06
 
| class="col1 centeralign" | MAGIC
 
| class="col1 centeralign" | MAGIC
 
| class="col2 centeralign" | MAGIC
 
| class="col2 centeralign" | MAGIC
Line 154: Line 156:
 
| class="col3" | This value seems to be constant for an installation of PM, or differs between the demo and full version.
 
| class="col3" | This value seems to be constant for an installation of PM, or differs between the demo and full version.
 
|- class="row3"
 
|- class="row3"
| class="col0 centeralign" | Unused
+
| class="col0 centeralign" | Server Security
 
| class="col1 centeralign" | byte
 
| class="col1 centeralign" | byte
 
| class="col2 centeralign" | <code>0</code>
 
| class="col2 centeralign" | <code>0</code>
| class="col3" |  
+
| class="col3" | Always 0
 
|- class="row4"
 
|- class="row4"
 
| class="col0 centeralign" | MTU Size
 
| class="col0 centeralign" | MTU Size
Line 185: Line 187:
 
| class="col4" | Notes
 
| class="col4" | Notes
 
|- class="row1"
 
|- class="row1"
| class="col0 centeralign" rowspan="7" | 0x07
+
| class="col0 centeralign" rowspan="6" | 0x07
 
| class="col1 centeralign" | MAGIC
 
| class="col1 centeralign" | MAGIC
 
| class="col2 centeralign" | MAGIC
 
| class="col2 centeralign" | MAGIC
Line 191: Line 193:
 
| class="col4" |  
 
| class="col4" |  
 
|- class="row2"
 
|- class="row2"
| class="col0 centeralign" | Unused
+
| class="col0 centeralign" | Security + Cookie
| class="col1 centeralign" | 5 bytes
+
| class="col1 centeralign" | 1 + 4 bytes
 
| class="col2 centeralign" | <code>0x043f57fefd</code>
 
| class="col2 centeralign" | <code>0x043f57fefd</code>
| class="col3" | Only seen this value
+
| class="col3" | Unused, constant value
 
|- class="row3"
 
|- class="row3"
| class="col0 centeralign" | Port
+
| class="col0 centeralign" | Server UDP Port
 
| class="col1 centeralign" | short
 
| class="col1 centeralign" | short
 
| class="col2 centeralign" | <code>19132</code>
 
| class="col2 centeralign" | <code>19132</code>
Line 209: Line 211:
 
| class="col1 centeralign" | int64
 
| class="col1 centeralign" | int64
 
| class="col2 centeralign" | <code>0x00000000372cdc9e</code>
 
| class="col2 centeralign" | <code>0x00000000372cdc9e</code>
| class="col3" | The Client / Server ID will be the same for a device
+
| class="col3" | The Client / Server ID will be the same for a given device
 
|- class="row6"
 
|- class="row6"
 
| class="col0" | Total Size:
 
| class="col0" | Total Size:
| class="col1 rightalign" colspan="4" | 39 Bytes
+
| class="col1 rightalign" colspan="4" | 34 Bytes
 
|}
 
|}
  
Line 231: Line 233:
 
| class="col4" | Notes
 
| class="col4" | Notes
 
|- class="row1"
 
|- class="row1"
| class="col0 centeralign" rowspan="7" | 0x08
+
| class="col0 centeralign" rowspan="6" | 0x08
 
| class="col1 centeralign" | MAGIC
 
| class="col1 centeralign" | MAGIC
 
| class="col2 centeralign" | MAGIC
 
| class="col2 centeralign" | MAGIC
Line 242: Line 244:
 
| class="col3" |
 
| class="col3" |
 
|- class="row3"
 
|- class="row3"
| class="col0 centeralign" | Unused
+
| class="col0 centeralign" | Client UDP Port
| class="col1 centeralign" | 5 bytes
+
| class="col1 centeralign" | short
| class="col2 centeralign" | <code>0x043f57fefd</code>
+
| class="col2 centeralign" | <code>46946</code>
 
| class="col3" |  
 
| class="col3" |  
 
|- class="row4"
 
|- class="row4"
 +
| class="col0 centeralign" | MTU Size
 +
| class="col1 centeralign" | short
 +
| class="col2 centeralign" | <code>1464</code>
 +
| class="col3" |
 +
|- class="row5"
 +
| class="col0 centeralign" | Security
 +
| class="col1 centeralign" | byte
 +
| class="col2 centeralign" | <code>0</code>
 +
| class="col3" | Always 0
 +
|- class="row6"
 
| class="col0" | Total Size:
 
| class="col0" | Total Size:
 
| class="col1 rightalign" colspan="4" | 30 Bytes
 
| class="col1 rightalign" colspan="4" | 30 Bytes
Line 253: Line 265:
 
Sent from server in response to packet 0x07.
 
Sent from server in response to packet 0x07.
  
{{anchor|0x1D}}
+
 
=== ID_ADVERTISE_SYSTEM (0x1D) ===
+
{{anchor|0x1A}}
Same as [[#0x1C|ID_UNCONNECTED_PING_OPEN_CONNECTIONS (0x1C)]], but with the Packet ID changed. Depends of the version
+
=== ID_INCOMPATIBLE_PROTOCOL_VERSION (0x1A) ===
 +
 
 +
''Server to Client''
 +
 
 +
{| class="wikitable"
 +
|- class="row0"
 +
| class="col0" | Packet ID
 +
| class="col1" | Field Name
 +
| class="col2" | Field Type
 +
| class="col3" | Example
 +
| class="col4" | Notes
 +
|- class="row1"
 +
| class="col0 centeralign" rowspan="4" | 0x1A
 +
| class="col1 centeralign" | Protocol Version
 +
| class="col2 centeralign" | byte
 +
| class="col3 centeralign" | <code>5</code>
 +
| class="col4" |
 +
|- class="row2"
 +
| class="col0 centeralign" | MAGIC
 +
| class="col1 centeralign" | MAGIC
 +
| class="col2 centeralign" |
 +
| class="col3" |
 +
|- class="row2"
 +
| class="col0 centeralign" | Server ID
 +
| class="col1 centeralign" | int64
 +
| class="col2 centeralign" | <code>0x00000000372cdc9e</code>
 +
| class="col3" |
 +
|- class="row3"
 +
| class="col0" | Total Size:
 +
| class="col1 rightalign" colspan="4" | 26 Bytes
 +
|}
 +
 
  
 
{{anchor|0x1C}}
 
{{anchor|0x1C}}
Line 270: Line 313:
 
| class="col4" | Notes
 
| class="col4" | Notes
 
|- class="row1"
 
|- class="row1"
| class="col0 centeralign" rowspan="7" | 0x1c
+
| class="col0 centeralign" rowspan="5" | 0x1C
 
| class="col1 centeralign" | Ping ID
 
| class="col1 centeralign" | Ping ID
 
| class="col2 centeralign" | int64
 
| class="col2 centeralign" | int64
Line 286: Line 329:
 
| class="col3" |
 
| class="col3" |
 
|- class="row2"
 
|- class="row2"
| class="col0 centeralign" | Host Info
+
| class="col0 centeralign" | Data
 
| class="col1 centeralign" | string
 
| class="col1 centeralign" | string
 
| class="col2 centeralign" | <code>MCCPP;Demo;Steve</code>
 
| class="col2 centeralign" | <code>MCCPP;Demo;Steve</code>
Line 297: Line 340:
 
Server sends this packet in response to a 0x02 packet. It may be either a 0x1d or a 0x1c, depending on version.
 
Server sends this packet in response to a 0x02 packet. It may be either a 0x1d or a 0x1c, depending on version.
 
If the Server is invisible, this packet will be sent without username
 
If the Server is invisible, this packet will be sent without username
 +
 +
 +
{{anchor|0x1D}}
 +
=== ID_ADVERTISE_SYSTEM (0x1D) ===
 +
Same as [[#0x1C|ID_UNCONNECTED_PING_OPEN_CONNECTIONS (0x1C)]], but with the Packet ID changed. Depends of the version
  
  
 
{{anchor|0x84}}
 
{{anchor|0x84}}
  
=== Unknown (0x84) ===
+
=== ID_RESERVED_7 (0x84) ===
  
 
''Two-Way''
 
''Two-Way''
  
 +
'''This packet is part of the real Minecraft PE implementation.'''
  
Fields in this packet are variable, also the lenght
+
 
 +
This packet has a partial unknown structure
  
 
{| class="wikitable"
 
{| class="wikitable"
Line 316: Line 366:
 
| class="col4" | Notes
 
| class="col4" | Notes
 
|- class="row1"
 
|- class="row1"
| class="col0 centeralign" rowspan="7" | 0x84
+
| class="col0 centeralign" rowspan="2" | 0x84
 
| class="col1 centeralign" | Unknown
 
| class="col1 centeralign" | Unknown
 
| class="col2 centeralign" | variable
 
| class="col2 centeralign" | variable
Line 333: Line 383:
  
 
''Two-Way''
 
''Two-Way''
 +
 +
'''This packet is part of the real Minecraft PE implementation.'''
  
 
{| class="wikitable"
 
{| class="wikitable"
Line 342: Line 394:
 
| class="col4" | Notes
 
| class="col4" | Notes
 
|- class="row1"
 
|- class="row1"
| class="col0 centeralign" rowspan="7" | 0xC0
+
| class="col0 centeralign" rowspan="2" | 0xC0
 
| class="col1 centeralign" | Ping ID
 
| class="col1 centeralign" | Ping ID
 
| class="col2 centeralign" | 6 bytes
 
| class="col2 centeralign" | 6 bytes

Revision as of 02:17, 20 October 2012

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 the same 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

Size Range Notes
byte 1 -128 to 127 Signed, two's complement
short 2 -32768 to 32767 Signed, two's complement
int32 4 -2147483648 to 2147483647 Signed, two's complement
int64 8 Maybe a double?
MAGIC 16 0x00ffff00fefefefefdfdfdfd12345678 always hex bytes 0x00ffff00fefefefefdfdfdfd12345678, corresponding to RakNet's default OFFLINE_MESSAGE_DATA_ID
string ≥ 1 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{|}~

Packets

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


ID_UNCONNECTED_PING_OPEN_CONNECTIONS (0x02)

Client to Broadcast

Packet ID Field Name Field Type Example Notes
0x02 Ping ID int64 0x00000000003c6d0d Time since start in Milliseconds
MAGIC MAGIC
Total Size: 25 Bytes

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


ID_OPEN_CONNECTION_REQUEST_1 (0x05)

Client to Server

Packet ID Field Name Field Type Example Notes
0x05 MAGIC MAGIC
Protocol Version byte 5 Currently 5
Null Payload many 0x00 bytes 0x00 * 1447 MTU (Maximum Transport Unit)
Total Size: 18 Bytes + lenght of Null Payload

If the version is different than yours, reply with a [[#0x1A|ID_INCOMPATIBLE_PROTOCOL_VERSION (0x1A)]

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 Null Payload lenght of 1447 4 packets of Null Payload lenght of 1155 5 packets of Null Payload lenght of 531 If the server doesnt't reply the client, the client will display a "Connect Error" window


ID_OPEN_CONNECTION_REPLY_1 (0x06)

Server to Client

Packet ID Field Name Field Type Example Notes
0x06 MAGIC MAGIC
Server ID int64 0x00000000372cdc9e This value seems to be constant for an installation of PM, or differs between the demo and full version.
Server Security byte 0 Always 0
MTU Size short 1447 Lenght of 0x05. Used to determine packet loss and max UDP packet size (MTU)
Total Size: 28 Bytes

Sent from server after it receives packet 0x05.


ID_OPEN_CONNECTION_REQUEST_2 (0x07)

Client to Server

Packet ID Field Name Field Type Example Notes
0x07 MAGIC MAGIC
Security + Cookie 1 + 4 bytes 0x043f57fefd Unused, constant value
Server UDP Port short 19132
MTU Size short 1464
Client ID int64 0x00000000372cdc9e The Client / Server ID will be the same for a given device
Total Size: 34 Bytes

Sent from client in response to packet 0x06.


ID_OPEN_CONNECTION_REPLY_2 (0x08)

Server to Client

Packet ID Field Name Field Type Example Notes
0x08 MAGIC MAGIC
Server ID int64 0x00000000372cdc9e
Client UDP Port short 46946
MTU Size short 1464
Security byte 0 Always 0
Total Size: 30 Bytes

Sent from server in response to packet 0x07.


ID_INCOMPATIBLE_PROTOCOL_VERSION (0x1A)

Server to Client

Packet ID Field Name Field Type Example Notes
0x1A Protocol Version byte 5
MAGIC MAGIC
Server ID int64 0x00000000372cdc9e
Total Size: 26 Bytes


ID_UNCONNECTED_PING_OPEN_CONNECTIONS (0x1C)

Server to Client

Packet ID Field Name Field Type Example Notes
0x1C Ping ID int64 0x00000000003c6d0d Time since start in Milliseconds
Server ID int64 0x00000000372cdc9e
MAGIC MAGIC
Data string MCCPP;Demo;Steve Used to send the username (MCCPP;Demo; + username)
Total Size: 35 Bytes + lenght of string

Server sends this packet in response to a 0x02 packet. It may be either a 0x1d or a 0x1c, depending on version. If the Server is invisible, this packet will be sent without username


ID_ADVERTISE_SYSTEM (0x1D)

Same as ID_UNCONNECTED_PING_OPEN_CONNECTIONS (0x1C), but with the Packet ID changed. Depends of the version


ID_RESERVED_7 (0x84)

Two-Way

This packet is part of the real Minecraft PE implementation.


This packet has a partial unknown structure

Packet ID Field Name Field Type Example Notes
0x84 Unknown variable
Total Size: ? Bytes

Sent after 0x08, and 0xC0


Unknown (0xC0)

Two-Way

This packet is part of the real Minecraft PE implementation.

Packet ID Field Name Field Type Example Notes
0xC0 Ping ID 6 bytes 0x000101000000
Total Size: 7 Bytes

Sent by the Client after the first 0x84. Then, the Server replies with the same packet