Difference between revisions of "Pocket Minecraft Protocol"
(Doing MAGIC) |
|||
Line 111: | Line 111: | ||
| class="col1 centeralign" | byte | | class="col1 centeralign" | byte | ||
| class="col2 centeralign" | 5 | | class="col2 centeralign" | 5 | ||
− | | class="col3" | | + | | class="col3" | Protocol version, currently 5 |
|- class="row2" | |- class="row2" | ||
| class="col0 centeralign" | Null Payload | | class="col0 centeralign" | Null Payload | ||
Line 155: | Line 155: | ||
| 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" | | + | | class="col0 centeralign" | Unused |
| class="col1 centeralign" | byte | | class="col1 centeralign" | byte | ||
− | | class="col2 centeralign" | | + | | class="col2 centeralign" | 0 |
− | | class="col3" | | + | | class="col3" | |
|- class="row4" | |- class="row4" | ||
| class="col0 centeralign" | Null Payload Lenght | | class="col0 centeralign" | Null Payload Lenght | ||
Line 191: | Line 191: | ||
| class="col4" | | | class="col4" | | ||
|- class="row2" | |- class="row2" | ||
− | | class="col0 centeralign" | | + | | class="col0 centeralign" | Unused |
| class="col1 centeralign" | 5 bytes | | class="col1 centeralign" | 5 bytes | ||
| class="col2 centeralign" | 0x043f57fefd | | class="col2 centeralign" | 0x043f57fefd | ||
− | | class="col3" | | + | | class="col3" | Always 0x043f57fefd |
|- class="row3" | |- class="row3" | ||
− | | class="col0 centeralign" | | + | | class="col0 centeralign" | Port |
| class="col1 centeralign" | short | | class="col1 centeralign" | short | ||
− | | class="col2 centeralign" | | + | | class="col2 centeralign" | 19132 |
− | | class="col3" | | + | | class="col3" | |
|- class="row4" | |- class="row4" | ||
− | | class="col0 centeralign" | | + | | class="col0 centeralign" | MTU Size |
| class="col1 centeralign" | short | | class="col1 centeralign" | short | ||
− | | class="col2 centeralign" | | + | | class="col2 centeralign" | 1464 |
| class="col3" | | | class="col3" | | ||
|- class="row5" | |- class="row5" | ||
− | | class="col0 centeralign" | | + | | class="col0 centeralign" | Client ID |
− | | class="col1 centeralign" | | + | | class="col1 centeralign" | int64 |
| class="col2 centeralign" | 1061862405 | | class="col2 centeralign" | 1061862405 | ||
| class="col3" | | | class="col3" | | ||
|- class="row6" | |- class="row6" | ||
− | |||
− | |||
− | |||
− | |||
− | |||
| class="col0" | Total Size: | | class="col0" | Total Size: | ||
| class="col1 rightalign" colspan="4" | 39 Bytes | | class="col1 rightalign" colspan="4" | 39 Bytes | ||
Line 242: | Line 237: | ||
| class="col4" | | | class="col4" | | ||
|- class="row2" | |- class="row2" | ||
− | | class="col0 centeralign" | | + | | class="col0 centeralign" | Client ID |
− | | class="col1 centeralign" | | + | | class="col1 centeralign" | int64 |
| class="col2 centeralign" | 0xffffffff | | class="col2 centeralign" | 0xffffffff | ||
| class="col3" | | | class="col3" | | ||
|- class="row3" | |- class="row3" | ||
− | | class="col0 centeralign" | | + | | class="col0 centeralign" | Unused |
− | |||
− | |||
− | |||
− | |||
− | |||
| class="col1 centeralign" | 5 bytes | | class="col1 centeralign" | 5 bytes | ||
| class="col2 centeralign" | 0x043f57fefd | | class="col2 centeralign" | 0x043f57fefd | ||
| class="col3" | | | class="col3" | | ||
− | |- class=" | + | |- class="row4" |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
| class="col0" | Total Size: | | class="col0" | Total Size: | ||
− | | class="col1 rightalign" colspan="4" | | + | | class="col1 rightalign" colspan="4" | 30 Bytes |
|} | |} | ||
Revision as of 15:05, 18 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.
Contents
- 1 Terminology
- 2 Types
- 3 Packets
- 3.1 ID_UNCONNECTED_PING_OPEN_CONNECTIONS (0x02)
- 3.2 ID_OPEN_CONNECTION_REQUEST_1 (0x05)
- 3.3 ID_OPEN_CONNECTION_REPLY_1 (0x06)
- 3.4 ID_OPEN_CONNECTION_REQUEST_2 (0x07)
- 3.5 ID_OPEN_CONNECTION_REPLY_2 (0x08)
- 3.6 ID_ADVERTISE_SYSTEM (0x1d)
- 3.7 ID_UNCONNECTED_PING_OPEN_CONNECTIONS (0x1c)
- 3.8 Unknown (0x84)
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 | 0x0000000000301dfb
|
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 | ||
Version | byte | 5 | Protocol version, currently 5 | |
Null Payload | many 0x00 bytes | 0x00 * 1447 | MTU (Maximum Transport Unit) | |
Total Size: | 18 Bytes + lenght of Null Payload |
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 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. 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 |
0x05 | MAGIC | MAGIC | ||
Server ID | int64 | This value seems to be constant for an installation of PM, or differs between the demo and full version. | ||
Unused | byte | 0 | ||
Null Payload Lenght | short | 1447 | Lenght of Null Payload in 0x05. Used to determine packet loss and max UDP packet size | |
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 | ||
Unused | 5 bytes | 0x043f57fefd | Always 0x043f57fefd | |
Port | short | 19132 | ||
MTU Size | short | 1464 | ||
Client ID | int64 | 1061862405 | ||
Total Size: | 39 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 | ||
Client ID | int64 | 0xffffffff | ||
Unused | 5 bytes | 0x043f57fefd | ||
Total Size: | 30 Bytes |
Sent from server in response to packet 0x07.
ID_ADVERTISE_SYSTEM (0x1d)
See 0x1c
ID_UNCONNECTED_PING_OPEN_CONNECTIONS (0x1c)
Server to Client
Packet ID | Field Name | Field Type | Example | Notes |
0x1c | Ping ID | int64 | 0x0000000000301dfb
|
Time since start in Milliseconds |
Server ID | int64 | |||
MAGIC | MAGIC | |||
Host Info | string | MCCPP;Demo;Steve | Used to send the 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.
Unknown (0x84)
Client to Server
Packet ID | Field Name | Field Type | Example | Notes |
0x84 | Count | byte | 2 | Count of 0x84 packets sent |
Unknown | 9 bytes | Only seen 0x000040009000000009 | Unknown, could be split in more fields | |
Unknown | int | Only seen 0xffffffff | ||
Session ID? | int | 0xb2e9b623 | Same as last field of 0x07 | |
Unknown | 5 bytes | Only seen 0x0000000000 | ||
Unknown | 4 bytes | 0xa6b42b00 | Last byte only seen as 0x00 | |
Total Size: | 28 Bytes |
Sent after 0x08. The client will send 5 0x84 packets, incrementing the count every time (starting at 0)