Pocket Minecraft Protocol: Difference between revisions
imported>Huin (Notes on UDP nature of protocol.) |
imported>Huin (Created sections, filled out some more information.) |
||
| Line 1: | Line 1: | ||
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.). | 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. | |||
== 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 === | |||
0x02 - client broadcast query | |||
* int8 = 0x02 (packet type ID) | * int8 = 0x02 (packet type ID) | ||
| Line 21: | Line 21: | ||
UDP packet broadcast to port 19132, 25 bytes long. Connection ident changes each time - seems to increment by some amount that relates to time. | UDP packet broadcast to port 19132, 25 bytes long. Connection ident changes each time - seems to increment by some amount that relates to time. | ||
=== 0x05 - mtu sizing request === | |||
0x05 - mtu sizing request | |||
* int8 = 0x05 | * int8 = 0x05 | ||
| Line 42: | Line 30: | ||
this with reducing sizes until it successfully receives a reply. | this with reducing sizes until it successfully receives a reply. | ||
=== 0x06 - server mtu sizing response === | |||
0x06 - server mtu sizing response | |||
* int8 = 0x06 (packet type ID) | * int8 = 0x06 (packet type ID) | ||
| Line 52: | Line 39: | ||
Sent from server after it receives packet 0x05. | Sent from server after it receives packet 0x05. | ||
=== 0x1d - server query response === | |||
* int8 = 0x1d (packet type ID) | |||
* int64 = ping ID from client | |||
* int64 = server ID | |||
* MAGIC | |||
* string ("MCCPP;Demo;" + Username) | |||
UDP packet sent to port/address that sent query. Probably variable length given the strings. | |||
Revision as of 18:01, 15 October 2011
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.
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 (client seems to use time in milliseconds since the program was started)
- MAGIC
UDP packet broadcast to port 19132, 25 bytes long. Connection ident changes each time - seems to increment by some amount that relates to time.
0x05 - mtu sizing request
- int8 = 0x05
- MAGIC
- int8 = 0x04 (unknown meaning)
Sent from client after it receives packet 0x1d. The client will repeatedly send this with reducing sizes until it successfully receives a reply.
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.
0x1d - server query response
- int8 = 0x1d (packet type ID)
- int64 = ping ID from client
- int64 = server ID
- MAGIC
- string ("MCCPP;Demo;" + Username)
UDP packet sent to port/address that sent query. Probably variable length given the strings.