Difference between revisions of "Server List Ping"
Thinkofdeath (talk | contribs) |
Thinkofdeath (talk | contribs) (→1.7) |
||
Line 93: | Line 93: | ||
| rowspan=1 | 0x01 | | rowspan=1 | 0x01 | ||
| Time || Long || | | Time || Long || | ||
− | |} | + | |} |
+ | === Examples === | ||
+ | [[https://gist.github.com/zh32/7190955 Java]] | ||
== 1.6 == | == 1.6 == |
Revision as of 13:58, 2 November 2013
Minecraft supports querying the MOTD, player count, max players and server version via the usual port. Unlike Query, the server list ping interface is always enabled.
Contents
1.7
The server ping process changed in 1.7 in a non-backwards compatible way but the 1.7 server does support both (see below)
The packets have a length prefix which is a VarInt (Java example). The data contained in the next length bytes is as followed:
Field Name | Field Type | Notes |
---|---|---|
Packet ID | VarInt | |
Data |
Where data depends on the packet.
Ping Process
Firstly a Handshake packet must be sent with its state set to 1. The layout of the handshake packet is as followed
Packet ID | Field Name | Field Type | Notes |
---|---|---|---|
0x00 | Protocol Version | VarInt | (4 as of 1.7.2) |
Server Address (hostname or IP) | String | A string is a VarInt length followed length bytes which make an UTF-8 string | |
Server Port | Unsigned Short | A short has 2 byte size. It should be read in Big-endian order | |
Next state | VarInt | 1 for status |
Followed by a Status Request packet. The request packet has no fields
Packet ID | Field Name | Field Type | Notes |
---|---|---|---|
0x00 |
The server should respond with a Status Response packet
Packet ID | Field Name | Field Type | Notes |
---|---|---|---|
0x00 | JSON Response | String | A string is a VarInt length followed length bytes which make an UTF-8 string |
The response is a json object which has the following format
{ "version": { "name": "1.7.2", "protocol": 4 }, "players": { "max": 100, "online": 5, "sample":[ {"name":"Thinkofdeath", "id":"4566e69fc90748ee8d71d7ba5aa00d20"} ] }, "description": {"text":"Hello world"}, "favicon": "data:image/png;base64,<data>" }
The sample and favicon sections are optional.
The favicon should be a png image that is Base64 encoded and prepended with 'data:image/png;base64,'
The client sends another packet to help calculate the server's latency but if you only wanted the above information you can stop here.
The client will then send a Ping packet containing the time that the ping was sent.
Packet ID | Field Name | Field Type | Notes |
---|---|---|---|
0x01 | Time | Long |
The server will respond with the same packet and then close the connection
Packet ID | Field Name | Field Type | Notes |
---|---|---|---|
0x01 | Time | Long |
Examples
[Java]
1.6
Client -> Server
The client initiates a TCP connection to the minecraft server on the standard port. Instead of doing auth and logging in (as detailed in Protocol Encryption), it sends the following data, expressed in hexadecimal:
FE
- packet identifier for a server list ping01
- server list ping's payload (always 1)FA
- packet identifier for a plugin message00 0B
- length of following string, in characters, as a short (always 11)00 4D 00 43 00 7C 00 50 00 69 00 6E 00 67 00 48 00 6F 00 73 00 74
- the string "MC|PingHost" encoded as a UTF-16BE stringXX XX
- length of the rest of the data, as a short. Compute as7 + 2*len(hostname)
XX
- protocol version - currently 74 (decimal)XX XX
- length of following string, in characters, as a short...
- hostname the client is connecting to, encoded the same way as "MC|PingHost"XX XX XX XX
- port the client is connecting to, as an int.
All data types are big-endian.
Packet dump:
0000000: fe01 fa00 0b00 4d00 4300 7c00 5000 6900 ......M.C.|.P.i. 0000010: 6e00 6700 4800 6f00 7300 7400 1949 0009 n.g.H.o.s.t..I.. 0000020: 006c 006f 0063 0061 006c 0068 006f 0073 .l.o.c.a.l.h.o.s 0000030: 0074 0000 63dd .t..c.
Server -> Client
The server responds with a 0xFF kick packet. The packet begins with a single byte identifier ff
, then a two-byte big endian short giving the length of the proceeding string in characters. You can actually ignore the length because the server closes the connection after the response is sent.
After the first 3 bytes, the packet is a UTF-16BE string. It begins with two characters: §1
, followed by a null character. On the wire these look like 00 a7 00 31 00 00
.
The remainder is null character (that is 00 00
) delimited fields:
- Protocol version (e.g.
47
) - Minecraft server version (e.g.
1.4.2
) - Message of the day (e.g.
A Minecraft Server
) - Current player count
- Max players
The entire packet looks something like this:
<---> first character 0000000: ff00 2300 a700 3100 0000 3400 3700 0000 ....§.1...4.7... 0000010: 3100 2e00 3400 2e00 3200 0000 4100 2000 1...4...2...A. . 0000020: 4d00 6900 6e00 6500 6300 7200 6100 6600 M.i.n.e.c.r.a.f. 0000030: 7400 2000 5300 6500 7200 7600 6500 7200 t. .S.e.r.v.e.r. 0000040: 0000 3000 0000 3200 30 ..0...2.0
1.4 - 1.5
Prior to the Minecraft 1.6, the client -> server operation is much simpler, and only sends FE 01
, with none of the following data beginning FA ...
Beta 1.8 - 1.3
Prior to Minecraft 1.4, the client only sends FE
.
Additionally, the response from the server only contains 3 fields delimited by §
:
- Message of the day (e.g.
A Minecraft Server
) - Current player count
- Max players
The entire packet looks something like this:
<---> first character 0000000: ff00 1700 4100 2000 4d00 6900 6e00 6500 ....A. .M.i.n.e. 0000010: 6300 7200 6100 6600 7400 2000 5300 6500 c.r.a.f.t. .S.e. 0000020: 7200 7600 6500 7200 a700 3000 a700 3100 r.v.e.r.§.0.§.1. 0000030: 30 0