Difference between revisions of "Protocol FAQ"

From wiki.vg
Jump to navigation Jump to search
m (→‎What's the normal login sequence for a client?: Noted that you don't need to necessarily need to send a Client Status.)
(fix protocol links in status sequence)
 
(31 intermediate revisions by 18 users not shown)
Line 1: Line 1:
People very, very often have questions regarding the Minecraft Modern [[Protocol]], so we'll try to address some of the most common ones on this document. If you're still having trouble, join us on IRC, channel [irc://irc.freenode.net/mcdevs #mcdevs on irc.freenode.net].
+
People very, very often have questions regarding the Minecraft Modern [[Protocol]], so we'll try to address some of the most common ones on this document. If you're still having trouble, join us on IRC, channel [ircs://irc.libera.chat:6697/mcdevs #mcdevs on irc.libera.chat].
  
 
== Is the protocol documentation complete? ==
 
== Is the protocol documentation complete? ==
 
 
Depending on your definition, ''yes''! All packet types are known and their layout documented. Some finer details are missing, but everything you need to make functional programs is present. We also collect information on the [[pre-release protocol]] changes, allowing us to quickly document new releases.
 
Depending on your definition, ''yes''! All packet types are known and their layout documented. Some finer details are missing, but everything you need to make functional programs is present. We also collect information on the [[pre-release protocol]] changes, allowing us to quickly document new releases.
  
 
== What's the normal login sequence for a client? ==
 
== What's the normal login sequence for a client? ==
 
 
See [[Authentication]] for communication with Mojang's servers.
 
See [[Authentication]] for communication with Mojang's servers.
 
{{Warning|Information might not be totally up to date}}
 
  
 
The recommended login sequence looks like this, where '''C''' is the client and '''S''' is the server:
 
The recommended login sequence looks like this, where '''C''' is the client and '''S''' is the server:
 
 
# Client connects to server
 
# Client connects to server
# '''C→S''': [[Protocol#Handshake|Handshake]] State=2
+
# '''C'''→'''S''': [[Protocol#Handshake|Handshake]] State=2
# '''C→S''': [[Protocol#Login Start|Login Start]]
+
# '''C'''→'''S''': [[Protocol#Login Start|Login Start]]
# '''S→C''': [[Protocol#Encryption Request|Encryption Request]]
+
# '''S'''→'''C''': [[Protocol#Encryption Request|Encryption Request]]
 
# Client auth
 
# Client auth
# '''C→S''': [[Protocol#Encryption Response|Encryption Response]]
+
# '''C'''→'''S''': [[Protocol#Encryption Response|Encryption Response]]
 
# Server auth, both enable encryption
 
# Server auth, both enable encryption
# '''S→C''': [[Protocol#Login Success|Login Success]]
+
# '''S''' → '''C''': [[Protocol#Set Compression|Set Compression]] (Optional, enables compression)
# '''S→C''': [[Protocol#Join Game|Join Game]]
+
# '''S''' → '''C''': [[Protocol#Login Success|Login Success]]
# '''S→C''': [[Protocol#Spawn Position|Spawn Position]] (“home” spawn, not where the client will spawn on login)
+
# '''S''' → '''C''': [[Protocol#Login (play)|Login (play)]]
# '''S→C''': [[Protocol#Player Abilities|Player Abilities]]
+
# '''S''' → '''C''': [[Protocol#Custom Payload (clientbound)|Custom Payload]]: [[Plugin channel#minecraft%3Abrand|<code>minecraft:brand</code>]] with the server's brand (Optional)
# '''S→C''': [[Protocol#Player Position And Look|Player Position And Look]] (tells the client they're ready to spawn)
+
# '''S''' → '''C''': [[Protocol#Change Difficulty|Change Difficulty]] (Optional)
# '''C→S''': [[Protocol#Player Position And Look 2|Player Position And Look]] (to confirm the spawn position)
+
# '''S''' → '''C''': [[Protocol#Player Abilities (clientbound)|Player Abilities]] (Optional)
# '''C→S''': [[Protocol#Client Status|Client Status]] (sent either before or while receiving chunks, further testing needed, server handles correctly if not sent)
+
# '''C''' → '''S''': [[Protocol#Custom Payload (serverbound)|Custom Payload]]: [[Plugin channel#minecraft%3Abrand|<code>minecraft:brand</code>]] with the client's brand (Optional)
# '''S→C''': inventory, [[Protocol#Map Chunk Bulk|Map Chunk Bulk]], entities, etc
+
# '''C''' → '''S''': [[Protocol#Client Information|Client Information]]
 +
# '''S''' → '''C''': [[Protocol#Set Carried Item (clientbound)|Set Carried Item]]
 +
# '''S''' → '''C''': [[Protocol#Update Recipes|Update Recipes]]
 +
# '''S''' → '''C''': [[Protocol#Update Tags|Update Tags]]
 +
# '''S''' → '''C''': [[Protocol#Entity Event|Entity Event]] (for the {{Minecraft Wiki|Server.properties#op-permission-level|OP permission level}}; see [[Entity statuses#Player]])
 +
# '''S''' → '''C''': [[Protocol#Commands|Commands]]
 +
# '''S''' → '''C''': [[Protocol#Recipe|Recipe]]
 +
# '''S''' → '''C''': [[Protocol#Player Position|Player Position]]
 +
# '''S''' → '''C''': [[Protocol#Player Info|Player Info]] (Add Player action)
 +
# '''S''' → '''C''': [[Protocol#Player Info|Player Info]] (Update latency action)
 +
# '''S''' → '''C''': [[Protocol#Set Chunk Cache Center|Set Chunk Cache Center]]
 +
# '''S''' → '''C''': [[Protocol#Light Update|Light Update]] (One sent for each chunk in a square centered on the player's position)
 +
# '''S''' → '''C''': [[Protocol#Level Chunk With Light|Level Chunk With Light]] (One sent for each chunk in a square centered on the player's position)
 +
# '''S''' → '''C''': [[Protocol#World Border|World Border]] (Once the world is finished loading)
 +
# '''S''' → '''C''': [[Protocol#Set Default Spawn Position|Set Default Spawn Position]] (“home” spawn, not where the client will spawn on login)
 +
# '''S''' '''C''': [[Protocol#Player Position|Player Position]] (Required, tells the client they're ready to spawn)
 +
# '''C''' → '''S''': [[Protocol#Accept Teleportation|Accept Teleportation]]
 +
# '''C''' → '''S''': [[Protocol#Move Player Position and Rotation|Move Player Position and Rotation]] (to confirm the spawn position)
 +
# '''C''' → '''S''': [[Protocol#Client Command|Client Command]] (sent either before or while receiving chunks, further testing needed, server handles correctly if not sent)
 +
# '''S''' →  '''C''': inventory, entities, etc
 +
 
 +
== What does the normal status ping sequence look like? ==
 +
When a Notchian client and server exchange information in a status ping, the exchange of packets will be as follows:
 +
 
 +
# '''C''' → '''S''': [[Protocol#Handshake|Handshake]] with Next State set to 1 ([[Protocol#Status|Status]])
 +
# Client and Server set protocol state to [[Protocol#Status|Status]].
 +
# '''C''' → '''S''': [[Protocol#Status Request|Status Request]]
 +
# '''S''' → '''C''': [[Protocol#Status Response|Status Response]]
 +
# '''C''' → '''S''': [[Protocol#Ping Request|Ping Request]]
 +
# '''S''' → '''C''': [[Protocol#Pong Response|Pong Response]]
 +
# '''S''' → ❌: Server terminates connection to client
 +
 
 +
(Note that '''C''' is the Notchian client and '''S''' is the Notchian server).
 +
 
 +
== Offline mode ==
 +
If the server is in offline mode, it will not send the [[Protocol#Encryption Request|Encryption Request]] packet, and likewise, the client should not send [[Protocol#Encryption Response|Encryption Response]]. In this case, encryption is never enabled, and no authentication is performed.
 +
 
 +
Clients can tell that a server is in offline mode if the server sends a [[Protocol#Login Success|Login Success]] without sending [[Protocol#Encryption Request|Encryption Request]].
  
 
== I think I've done everything right, but… ==
 
== I think I've done everything right, but… ==
 
 
=== …my player isn't spawning! ===
 
=== …my player isn't spawning! ===
 
+
After sending the common-sense packets ([[Protocol#Handshake|Handshake]], [[Protocol#Login Start|Login Start]], [[Protocol#Window Items|inventory]], [[Protocol#Spawn Position|compass]], and [[Protocol#Chunk Data|chunks]]), you need to finally send the player their [[Protocol#Player Position And Look|initial position]] for them to leave the “Loading Map” screen.
After sending the common-sense packets ([[Protocol#Handshake|Handshake]], [[Protocol#Login Start|Login Start]], [[Protocol#Window Items|inventory]], [[Protocol#Spawn Position|compass]], and [[Protocol#Map_ Chunk Bulk|chunks]]), you need to finally send the player their [[Protocol#Player Position And Look|initial position]] for them to leave the “Loading Map” screen.
 
  
 
''Note that if the following steps are taken, a Minecraft client will spawn the player:''
 
''Note that if the following steps are taken, a Minecraft client will spawn the player:''
 
 
# Do Handshake (see [[Protocol Encryption]])
 
# Do Handshake (see [[Protocol Encryption]])
 
# Send [[Protocol#Spawn Position|Spawn Position]] packet
 
# Send [[Protocol#Spawn Position|Spawn Position]] packet
# Send [[Protocol#Player Position And Look|Player Position And Look]] packet
+
# Send [[Protocol#Player Position And Look (clientbound)|Player Position And Look (clientbound)]] packet
  
 
While the above steps are sufficient for Minecraft 1.4.5, it is good form to send packets that inform the client about the world around the player before allowing the player to spawn.
 
While the above steps are sufficient for Minecraft 1.4.5, it is good form to send packets that inform the client about the world around the player before allowing the player to spawn.
Line 49: Line 78:
  
 
=== …all connecting clients spasm and jerk uncontrollably! ===
 
=== …all connecting clients spasm and jerk uncontrollably! ===
 +
For newer clients, your server needs to send 49 chunks ahead of time, not just one. Send a 7×7 square of chunks, centered on the connecting client's position, ''before'' spawning them.
 +
 +
=== …the client is trying to send an invalid packet that begins with 0xFE01 ===
 +
The client is attempting a [[Server_List_Ping#1.6|legacy ping]], this happens if your server did not respond to the [[Server List Ping]] properly, including if it sent malformed JSON.
 +
 +
=== …the client disconnects after some time with a "Timed out" error ===
 +
The server is expected to send a [[Protocol#Keep Alive (clientbound)|Keep Alive]] packet every 1-15 seconds (if the server does not send a keep alive within 20 seconds of state change to Play, the client will disconnect from the server for '''Timed Out'''), and the client should respond with the serverbound version of that packet. If either party does not receive keep alives for some period of time, they will disconnect.
 +
 +
=== ...my client isn't sending a Login Start packet! ===
 +
By default, the Notchian server and client may group packets depending on if Nagle's TCP algorithm is enabled - the primary objective of Nagle's algorithm is to reduce the total number of packets needed to be sent over the network, increasing the efficiency. Nagle's algorithm is achieved by delaying each TCP packet to check if there are any more that are about to be sent to group them. You may not see a Login Start packet as you may not have parsed anything past the packet's length, because of this, you'll need to separate packets based off of the packet length.
 +
 +
== How do I open/save a command block? ==
 +
The process to actually open the command block window clientside is somewhat complex; the client actually uses the [[Protocol#Update Block Entity|Update Block Entity (0x09)]] packet to open it.
  
For newer clients, your server needs to send 49 chunks ahead of time, not just one. Send a 7×7 square of chunks, centered on the connecting client's position, ''before'' spawning them.
+
First, the client must have at least an {{Minecraft Wiki|Server.properties#op-permission-level|OP permission level}} of 2, or else the client will refuse to open the command block.  (The op permission level is set with the [[Protocol#Entity Status|Entity Status]] packet)
 +
 
 +
To actually open the command block:
 +
 
 +
# '''C'''→'''S''': [[Protocol#Player Block Placement|Player Block Placement (0x1C)]], with the position being the command block that was right-clicked.
 +
# '''S'''→'''C''': [[Protocol#Update Block Entity|Update Block Entity (0x09)]], with the NBT of the command block.
 +
 
 +
And to save it, use the [[Plugin channels#MC.7CAutoCmd|<code>MC|AutoCmd</code> plugin channel]].
  
 
[[Category:Protocol Details]]
 
[[Category:Protocol Details]]
 
[[Category:Minecraft Modern]]
 
[[Category:Minecraft Modern]]

Latest revision as of 13:25, 30 June 2022

People very, very often have questions regarding the Minecraft Modern Protocol, so we'll try to address some of the most common ones on this document. If you're still having trouble, join us on IRC, channel #mcdevs on irc.libera.chat.

Is the protocol documentation complete?

Depending on your definition, yes! All packet types are known and their layout documented. Some finer details are missing, but everything you need to make functional programs is present. We also collect information on the pre-release protocol changes, allowing us to quickly document new releases.

What's the normal login sequence for a client?

See Authentication for communication with Mojang's servers.

The recommended login sequence looks like this, where C is the client and S is the server:

  1. Client connects to server
  2. CS: Handshake State=2
  3. CS: Login Start
  4. SC: Encryption Request
  5. Client auth
  6. CS: Encryption Response
  7. Server auth, both enable encryption
  8. SC: Set Compression (Optional, enables compression)
  9. SC: Login Success
  10. SC: Login (play)
  11. SC: Custom Payload: minecraft:brand with the server's brand (Optional)
  12. SC: Change Difficulty (Optional)
  13. SC: Player Abilities (Optional)
  14. CS: Custom Payload: minecraft:brand with the client's brand (Optional)
  15. CS: Client Information
  16. SC: Set Carried Item
  17. SC: Update Recipes
  18. SC: Update Tags
  19. SC: Entity Event (for the OP permission level; see Entity statuses#Player)
  20. SC: Commands
  21. SC: Recipe
  22. SC: Player Position
  23. SC: Player Info (Add Player action)
  24. SC: Player Info (Update latency action)
  25. SC: Set Chunk Cache Center
  26. SC: Light Update (One sent for each chunk in a square centered on the player's position)
  27. SC: Level Chunk With Light (One sent for each chunk in a square centered on the player's position)
  28. SC: World Border (Once the world is finished loading)
  29. SC: Set Default Spawn Position (“home” spawn, not where the client will spawn on login)
  30. SC: Player Position (Required, tells the client they're ready to spawn)
  31. CS: Accept Teleportation
  32. CS: Move Player Position and Rotation (to confirm the spawn position)
  33. CS: Client Command (sent either before or while receiving chunks, further testing needed, server handles correctly if not sent)
  34. SC: inventory, entities, etc

What does the normal status ping sequence look like?

When a Notchian client and server exchange information in a status ping, the exchange of packets will be as follows:

  1. CS: Handshake with Next State set to 1 (Status)
  2. Client and Server set protocol state to Status.
  3. CS: Status Request
  4. SC: Status Response
  5. CS: Ping Request
  6. SC: Pong Response
  7. S → ❌: Server terminates connection to client

(Note that C is the Notchian client and S is the Notchian server).

Offline mode

If the server is in offline mode, it will not send the Encryption Request packet, and likewise, the client should not send Encryption Response. In this case, encryption is never enabled, and no authentication is performed.

Clients can tell that a server is in offline mode if the server sends a Login Success without sending Encryption Request.

I think I've done everything right, but…

…my player isn't spawning!

After sending the common-sense packets (Handshake, Login Start, inventory, compass, and chunks), you need to finally send the player their initial position for them to leave the “Loading Map” screen.

Note that if the following steps are taken, a Minecraft client will spawn the player:

  1. Do Handshake (see Protocol Encryption)
  2. Send Spawn Position packet
  3. Send Player Position And Look (clientbound) packet

While the above steps are sufficient for Minecraft 1.4.5, it is good form to send packets that inform the client about the world around the player before allowing the player to spawn.

…my client isn't receiving complete map chunks!

Main article: How to Write a Client

The standard Minecraft server sends full chunks only when your client is sending player status update packets (any of Player (0x03) through Player Position And Look (0x06)).

…all connecting clients spasm and jerk uncontrollably!

For newer clients, your server needs to send 49 chunks ahead of time, not just one. Send a 7×7 square of chunks, centered on the connecting client's position, before spawning them.

…the client is trying to send an invalid packet that begins with 0xFE01

The client is attempting a legacy ping, this happens if your server did not respond to the Server List Ping properly, including if it sent malformed JSON.

…the client disconnects after some time with a "Timed out" error

The server is expected to send a Keep Alive packet every 1-15 seconds (if the server does not send a keep alive within 20 seconds of state change to Play, the client will disconnect from the server for Timed Out), and the client should respond with the serverbound version of that packet. If either party does not receive keep alives for some period of time, they will disconnect.

...my client isn't sending a Login Start packet!

By default, the Notchian server and client may group packets depending on if Nagle's TCP algorithm is enabled - the primary objective of Nagle's algorithm is to reduce the total number of packets needed to be sent over the network, increasing the efficiency. Nagle's algorithm is achieved by delaying each TCP packet to check if there are any more that are about to be sent to group them. You may not see a Login Start packet as you may not have parsed anything past the packet's length, because of this, you'll need to separate packets based off of the packet length.

How do I open/save a command block?

The process to actually open the command block window clientside is somewhat complex; the client actually uses the Update Block Entity (0x09) packet to open it.

First, the client must have at least an OP permission level of 2, or else the client will refuse to open the command block. (The op permission level is set with the Entity Status packet)

To actually open the command block:

  1. CS: Player Block Placement (0x1C), with the position being the command block that was right-clicked.
  2. SC: Update Block Entity (0x09), with the NBT of the command block.

And to save it, use the MC|AutoCmd plugin channel.