Server List Ping

Server List Ping (SLP) is an interface provided by Minecraft servers which supports querying the MOTD, player count, max players and server version via the usual port. SLP is part of the Protocol, so unlike Query, the interface is always enabled. The Notchian client uses this interface to display the multiplayer server list, hence the name. The SLP process changed in in a non-backwards compatible way, but current servers still support both the new and old process.

Current
This uses the regular client-server protocol. For the general packet format, see that article.

Handshake
First, the client sends a Handshake packet with its state set to 1.

Request
The client follows up with a Request packet. This packet has no fields.

Response
The server should respond with a Response packet. Note that Notchian servers will for unknown reasons wait to receive the following Ping packet for 30 seconds before timing out and sending Response.

The JSON Response field is a JSON object which has the following format:

The description field is a Chat object. Note that the Notchian server has no way of providing actual chat component data; instead section sign-based codes are embedded within the text of text of the object.

The favicon field is optional. The sample field must be set, but can be empty.

The favicon should be a PNG image that is Base64 encoded (without newlines:, new lines no longer work since 1.13) and prepended with.

After receiving the Response packet, the client may send the next packet to help calculate the server's latency, or if it is only interested in the above information it can disconnect here.

If the client does not receive a properly formatted response, then it will instead attempt a legacy ping.

Ping
If the process is continued, the client will now send a Ping packet containing some payload which is not important.

Pong
The server will respond with the Pong packet and then close the connection.

Examples

 * C#
 * Java
 * Python
 * Python3
 * PHP

1.6
This uses a protocol which is compatible with the client-server protocol as it was before the Netty rewrite. Modern servers recognize this protocol by the starting byte of  instead of the usual.

Client to server
The client initiates a TCP connection to the server on the standard port. Instead of doing auth and logging in (as detailed in Protocol and Protocol Encryption), it sends the following data, expressed in hexadecimal:


 * 1)   — packet identifier for a server list ping
 * 2)   — server list ping's payload (always 1)
 * 3)   — packet identifier for a plugin message
 * 4)   — length of following string, in characters, as a short (always 11)
 * 5)   — the string   encoded as a UTF-16BE string
 * 6)   — length of the rest of the data, as a short. Compute as , where   is the number of bytes in the UTF-16BE encoded hostname.
 * 7)   — protocol version, e.g.   for the last version (74)
 * 8)   — length of following string, in characters, as a short
 * 9)   — hostname the client is connecting to, encoded as a UTF-16BE string
 * 10)   — port the client is connecting to, as an int.

All data types are big-endian.

Example 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 to client
The server responds with a 0xFF kick packet. The packet begins with a single byte identifier, then a two-byte big endian short giving the length of the following 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:, followed by a null character. On the wire these look like.

The remainder is null character (that is ) delimited fields:


 * 1) Protocol version (e.g.  )
 * 2) Minecraft server version (e.g.  )
 * 3) Message of the day (e.g.  )
 * 4) Current player count
 * 5) 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

Note:  When using this protocol with servers on version 1.7.x and above, the protocol version (first field) in the response will always be  which is not a real protocol number, so older clients will always consider this server incompatible.

Examples

 * Ruby
 * PHP

1.4 to 1.5
Prior to the Minecraft 1.6, the client to server operation is much simpler, and only sends, with none of the following data.

Examples

 * PHP
 * Java
 * C#

Beta 1.8 to 1.3
Prior to Minecraft 1.4, the client only sends.

Additionally, the response from the server only contains 3 fields delimited by :


 * 1) Message of the day (e.g.  )
 * 2) Current player count
 * 3) 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