Difference between revisions of "Protocol FAQ"

From wiki.vg
Jump to navigation Jump to search
(→‎Offline mode: Encryption is possible in offline mode now)
 
(45 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 [ircs://irc.libera.chat:6697/mcdevs #mcdevs on irc.libera.chat].
+
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 our [https://discord.gg/Tf4xwK3Ke7 discord] or our IRC channel [ircs://irc.libera.chat:6697/mcdevs #mcdevs on irc.libera.chat].
  
 
== Is the protocol documentation complete? ==
 
== Is the protocol documentation complete? ==
Line 5: Line 5:
  
 
== 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.
 
  
The recommended login sequence looks like this, where '''C''' is the client and '''S''' is the server:
+
(This is about joining a Minecraft server. See [[Microsoft Authentication Scheme]] for how to log in to a Minecraft account, and [[Protocol Encryption]] for details on player authentication during server login.)
# Client connects to server
+
 
 +
The recommended login sequence as of 1.21 looks like this, where '''C''' is the client and '''S''' is the server:
 +
# Client connects to the 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]] (optional)
# Client auth
+
# Client auth (Only if server sent Encryption Request)
# '''C'''→'''S''': [[Protocol#Encryption Response|Encryption Response]]
+
# '''C'''→'''S''': [[Protocol#Encryption Response|Encryption Response]] (Only if server sent Encryption Request)
# Server auth, both enable encryption
+
# Server auth, both enable encryption (Only if server sent Encryption Request)
# '''S'''→'''C''': [[Protocol#Set Compression|Set Compression]] (Optional, enables compression)
+
# '''S''' → '''C''': [[Protocol#Set Compression|Set Compression]] (Optional, enables compression)
# '''S'''→'''C''': [[Protocol#Login Success|Login Success]]
+
# '''S''' → '''C''': [[Protocol#Login Success|Login Success]]
# '''S'''→'''C''': [[Protocol#Join Game|Join Game]]
+
# '''C''' → '''S''': [[Protocol#Login Acknowledged|Login Acknowledged]]
# '''S'''→'''C''': [[Protocol#Plugin Message (clientbound) |Plugin Message]]: [[Plugin channel#minecraft%3Abrand|<code>minecraft:brand</code>]] with the server's brand (Optional)
+
# '''C''' → '''S''': [[Protocol#Serverbound Plugin Message (configuration)|Serverbound Plugin Message]] (Optional, [[Plugin channel#minecraft%3Abrand|<code>minecraft:brand</code>]] with the client's brand)
# '''S'''→'''C''': [[Protocol#Server Difficulty|Server Difficulty]] (Optional)
+
# '''C''' → '''S''': [[Protocol#Client Information (configuration)|Client Information]] (Optional)
# '''S'''→'''C''': [[Protocol#Player Abilities (clientbound)|Player Abilities]] (Optional)
+
# '''S''' → '''C''': [[Protocol#Clientbound Plugin Message (configuration)|Clientbound Plugin Message]] (Optional, [[Plugin channel#minecraft%3Abrand|<code>minecraft:brand</code>]] with the server's brand)
# '''C'''→'''S''': [[Protocol#Plugin Message (serverbound)|Plugin Message]]: [[Plugin channel#minecraft%3Abrand|<code>minecraft:brand</code>]] with the client's brand (Optional)
+
# '''S''' → '''C''': [[Protocol#Feature Flags|Feature Flags]] (Optional)
# '''C'''→'''S''': [[Protocol#Client Settings|Client Settings]]
+
# '''S''' → '''C''': [[Protocol#Clientbound Known Packs|Clientbound Known Packs]]
# '''S'''→'''C''': [[Protocol#Held Item Change (clientbound)|Held Item Change]]
+
# '''C''' → '''S''': [[Protocol#Serverbound Known Packs|Serverbound Known Packs]]
# '''S'''→'''C''': [[Protocol#Declare Recipes|Declare Recipes]]
+
# '''S''' → '''C''': [[Protocol#Registry Data|Registry Data]] (Multiple)
# '''S'''→'''C''': [[Protocol#Tags|Tags]]
+
# '''S''' → '''C''': [[Protocol#Update Tags (configuration)|Update Tags]] (Optional)
# '''S'''→'''C''': [[Protocol#Entity Status|Entity Status]] (for the {{Minecraft Wiki|Server.properties#op-permission-level|OP permission level}}; see [[Entity statuses#Player]])
+
# '''S''' → '''C''': [[Protocol#Finish Configuration|Finish Configuration]]
# '''S'''→'''C''': [[Protocol#Declare Commands|Declare Commands]]
+
# '''C''' → '''S''': [[Protocol#Acknowledge Finish Configuration|Acknowledge Finish Configuration]]
# '''S'''→'''C''': [[Protocol#Unlock Recipes|Unlock Recipes]]
+
# '''S''' → '''C''': [[Protocol#Login (play)|Login (play)]]
# '''S'''→'''C''': [[Protocol#Player Position And Look (clientbound)|Player Position And Look]]
+
# '''S''' → '''C''': [[Protocol#Change Difficulty|Change Difficulty]] (Optional)
# '''S'''→'''C''': [[Protocol#Player Info|Player Info]] (Add Player action)
+
# '''S''' → '''C''': [[Protocol#Player Abilities (clientbound)|Player Abilities]] (Optional)
# '''S'''→'''C''': [[Protocol#Player Info|Player Info]] (Update latency action)
+
# '''S''' → '''C''': [[Protocol#Set Held Item (clientbound)|Set Held Item]] (Optional)
# '''S'''→'''C''': [[Protocol#Update View Position|Update View Position]]
+
# '''S''' → '''C''': [[Protocol#Update Recipes|Update Recipes]] (Optional)
# '''S'''→'''C''': [[Protocol#Update Light|Update Light]] (One sent for each chunk in a square centered on the player's position)
+
# '''S''' → '''C''': [[Protocol#Entity Event|Entity Event]] (Optional, for the {{Minecraft Wiki|Server.properties#op-permission-level|OP permission level}}; see [[Entity statuses#Player]])
# '''S'''→'''C''': [[Protocol#Chunk Data|Chunk Data]] (One sent for each chunk in a square centered on the player's position)
+
# '''S''' → '''C''': [[Protocol#Commands|Commands]] (Optional)
# '''S'''→'''C''': [[Protocol#World Border|World Border]] (Once the world is finished loading)
+
# '''S''' → '''C''': [[Protocol#Update Recipe Book|Update Recipe Book]] (Optional)
# '''S'''→'''C''': [[Protocol#Spawn Position|Spawn Position]] (“home” spawn, not where the client will spawn on login)
+
# '''S''' → '''C''': [[Protocol#Synchronize Player Position|Synchronize Player Position]]
# '''S'''→'''C''': [[Protocol#Player Position And Look (clientbound)|Player Position And Look]] (Required, tells the client they're ready to spawn)
+
# '''C''' → '''S''': [[Protocol#Confirm Teleportation|Confirm Teleportation]]
# '''C'''→'''S''': [[Protocol#Teleport Confirm|Teleport Confirm]]
+
# '''C''' → '''S''': [[Protocol#Set Player Position and Rotation|Set Player Position and Rotation]] (Optional, to confirm the spawn position)
# '''C'''→'''S''': [[Protocol#Player Position And Look (serverbound)|Player Position And Look]] (to confirm the spawn position)
+
# '''S''' → '''C''': [[Protocol#Server Data|Server Data]] (Optional)
# '''C'''→'''S''': [[Protocol#Client Status|Client Status]] (sent either before or while receiving chunks, further testing needed, server handles correctly if not sent)
+
# '''S''' → '''C''': [[Protocol#Player Info Update|Player Info Update]] (Add Player action, all players except the one joining (the Notchian server separates these, you don't need to))
# '''S'''→'''C''': inventory, entities, etc
+
# '''S''' → '''C''': [[Protocol#Player Info Update|Player Info Update]] (Add Player action, joining player)
 +
# '''S''' → '''C''': [[Protocol#Initialize World Border|Initialize World Border]] (Optional)
 +
# '''S''' → '''C''': [[Protocol#Update Time|Update Time]] (Optional)
 +
# '''S''' → '''C''': [[Protocol#Set Default Spawn Position|Set Default Spawn Position]] (Optional, “home” spawn, not where the client will spawn on login)
 +
# '''S''' → '''C''': [[Protocol#Game Event|Game Event]] (Start waiting for level chunks event, required for the client to spawn)
 +
# '''S''' → '''C''': [[Protocol#Set Ticking State|Set Ticking State]] (Optional)
 +
# '''S''' → '''C''': [[Protocol#Step Tick|Step Tick]] (Optional, the Notchian server sends this regardless of ticking state)
 +
# '''S''' → '''C''': [[Protocol#Set Center Chunk|Set Center Chunk]]
 +
# '''S''' → '''C''': [[Protocol#Chunk Data and Update Light|Chunk Data and Update Light]] (One sent for each chunk in a circular area centered on the player's position)
 +
# '''S''' → '''C''': inventory, entities, etc.
  
== Offline mode ==
+
=== 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.
+
If the Notchian 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]].
 
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]].
 +
 +
Versions 1.20.5 and newer support protocol encryption in offline mode, in which case the [[Protocol#Encryption Request|Encryption Request]] packet can be sent with Should Authenticate set to false, and both the client and server should not authenticate with Mojang. However, it's currently not possible to configure the Notchian server to do this.
 +
 +
== 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 (status)|Ping Request]]
 +
# '''S''' → '''C''': [[Protocol#Ping Response (status)|Ping Response]]
 +
# Both sides close the connection
 +
 +
(Note that '''C''' is the Notchian client and '''S''' is the Notchian server).
  
 
== 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.
 
  
''Note that if the following steps are taken, a Minecraft client will spawn the player:''
+
The Minecraft client will wait at the "Loading Terrain..." screen until late in the login sequence. As of 1.21, in order for the client to spawn, it must have received a [[Protocol#Game Event|Game Event]] packet with event 13 ("Start waiting for level chunks"), and at least one of the following conditions must be met:
# Do Handshake (see [[Protocol Encryption]])
 
# Send [[Protocol#Spawn Position|Spawn Position]] 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.
+
* The player is in a loaded chunk (sent via [[Protocol#Chunk Data and Update Light|Chunk Data and Update Light]]).
 +
* The player is below the minimum world height or above the maximum world height (teleported via [[Protocol#Synchronize Player Position|Synchronize Player Position]]).
 +
* The player is in spectator mode.
 +
* The player is dead (set via [[Protocol#Set Health|Set Health]] or [[Protocol#Combat Death|Combat Death]]).
  
=== …my client isn't receiving complete map chunks! ===
+
The client will also spawn after spending 30 seconds in the loading screen, even if it never received Game Event 13.
''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 [[Protocol#Player|Player (0x03)]] through [[Protocol#Player Position And Look|Player Position And Look (0x06)]]).
+
In past versions, you could either (1.19.3 through 1.20.1) send the default spawn position packet or (pre-1.19.3) send the player position packet. In general, try sending packets that inform the client about the player's position in the world in order to get past the loading terrain screen.
  
=== …all connecting clients spasm and jerk uncontrollably! ===
+
In version 1.21, it became required to send the known packs packet with <code>minecraft:core</code> version <code>1.21</code>.
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.
+
 
 +
As of 1.21, the minimum packets that need to be received and sent by the server in order to get the client past the loading terrain screen and into the world appear to be:
 +
 
 +
# Receive [[Protocol#Handshake|Handshake]]
 +
# Receive [[Protocol#Login Start|Login Start]]
 +
# Send [[Protocol#Login Success|Login Success]]
 +
# Receive [[Protocol#Login Acknowledged|Login Acknowledged]]
 +
# Send [[Protocol#Clientbound Known Packs|Clientbound Known Packs]]
 +
# Receive [[Protocol#Serverbound Known Packs|Serverbound Known Packs]]
 +
# Send multiple [[Protocol#Registry Data|Registry Data]]
 +
# Send [[Protocol#Finish Configuration|Finish Configuration]]
 +
# Receive [[Protocol#Acknowledge Finish Configuration|Acknowledge Finish Configuration]]
 +
# Send [[Protocol#Login .28play.29|Login (Play)]]
 +
# Send [[Protocol#Game Event|Game Event]], Start waiting for level chunks
 +
# Send [[Protocol#Chunk Data and Update Light|Chunk Data and Update Light]] and/or [[Protocol#Synchronize Player Position|Synchronize Player Position]] (see above)
 +
 
 +
The most difficult part of this may be sending any necessary NBTs in the [[Protocol#Registry_Data|Registry Data]] packet. Note that if you tell the Notchian client you have 0 known packs, it will blatantly lie to you, so you will probably need to record one from the standard server and replay it. Or you can find someone who has done that already, for example in [https://gist.github.com/Norbiros/f604ce46821e68c50260a169a9921560 Norbiros' gist]. You can also find JSON representation of this packet in [https://github.com/PrismarineJS/minecraft-data/blob/master/data/pc/1.20.2/loginPacket.json PrismarineJS/minecraft-data repo on GitHub].
 +
 
 +
=== …chunks are randomly showing and disappearing! ===
 +
The Notchian client only reliably renders chunks surrounded by other loaded chunks on all sides. See [[Chunk Format#Tips and notes]].
  
 
=== …the client is trying to send an invalid packet that begins with 0xFE01 ===
 
=== …the client is trying to send an invalid packet that begins with 0xFE01 ===
Line 71: Line 113:
  
 
=== …the client disconnects after some time with a "Timed out" error ===
 
=== …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 second, 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.
+
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.
 +
 
 +
=== ...some of the packets I expect to receive seem to be missing or too short ===
 +
 
 +
You may be misusing the socket API. In particular, it is invalid to assume that the amount of data returned by calls to <code>recv</code> (or equivalent, depending on the API you're using) relates to packet boundaries in any way. There are no "borders" in a [[wikipedia:Transmission Control Protocol|TCP]] data stream, only bytes. Regardless of how any two consecutive packets are sent, the receiver may get one packet, then the other, both at once, half of one, then the rest of both, or any other permutation of buffer sizes adding up to the total size of the packets. The only correct way to know where one packet ends and another begins is the packet length field, and you need to be prepared to handle multiple packets in one buffer, packets split across multiple buffers, etc. (as well as length fields split across multiple buffers!)
 +
 
 +
Similarly, depending on the API being used, a <code>send</code> call may also not guarantee that its whole input buffer is sent (consult the relevant documentation for details). This may also cause the connection to appear to hang during the login process, since the server will be left waiting indefinitely for the rest of the packet to arrive.
 +
 
 +
One reason why packets sent separately may arrive at once is [[wikipedia:Nagle's algorithm|Nagle's algorithm]], a feature of many TCP implementations intended to improve efficiency particularly for applications making lots of small <code>send</code> calls. It is not the ''only'' reason, though, and disabling it should not be seen as a solution to the problem discussed here. Nonetheless, the delays it introduces are detrimental to real-time applications like Minecraft, so the Notchian client and server disable it, and you should too. This is typically done by enabling a socket option called <code>TCP_NODELAY</code>. Especially when disabling Nagle's algorithm, you should group multiple packets sent during the same tick in one send buffer for the best performance.
  
 
== How do I open/save a command block? ==
 
== How do I open/save a command block? ==

Latest revision as of 13:33, 9 October 2024

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 our discord or our 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?

(This is about joining a Minecraft server. See Microsoft Authentication Scheme for how to log in to a Minecraft account, and Protocol Encryption for details on player authentication during server login.)

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

  1. Client connects to the server
  2. CS: Handshake State=2
  3. CS: Login Start
  4. SC: Encryption Request (optional)
  5. Client auth (Only if server sent Encryption Request)
  6. CS: Encryption Response (Only if server sent Encryption Request)
  7. Server auth, both enable encryption (Only if server sent Encryption Request)
  8. SC: Set Compression (Optional, enables compression)
  9. SC: Login Success
  10. CS: Login Acknowledged
  11. CS: Serverbound Plugin Message (Optional, minecraft:brand with the client's brand)
  12. CS: Client Information (Optional)
  13. SC: Clientbound Plugin Message (Optional, minecraft:brand with the server's brand)
  14. SC: Feature Flags (Optional)
  15. SC: Clientbound Known Packs
  16. CS: Serverbound Known Packs
  17. SC: Registry Data (Multiple)
  18. SC: Update Tags (Optional)
  19. SC: Finish Configuration
  20. CS: Acknowledge Finish Configuration
  21. SC: Login (play)
  22. SC: Change Difficulty (Optional)
  23. SC: Player Abilities (Optional)
  24. SC: Set Held Item (Optional)
  25. SC: Update Recipes (Optional)
  26. SC: Entity Event (Optional, for the OP permission level; see Entity statuses#Player)
  27. SC: Commands (Optional)
  28. SC: Update Recipe Book (Optional)
  29. SC: Synchronize Player Position
  30. CS: Confirm Teleportation
  31. CS: Set Player Position and Rotation (Optional, to confirm the spawn position)
  32. SC: Server Data (Optional)
  33. SC: Player Info Update (Add Player action, all players except the one joining (the Notchian server separates these, you don't need to))
  34. SC: Player Info Update (Add Player action, joining player)
  35. SC: Initialize World Border (Optional)
  36. SC: Update Time (Optional)
  37. SC: Set Default Spawn Position (Optional, “home” spawn, not where the client will spawn on login)
  38. SC: Game Event (Start waiting for level chunks event, required for the client to spawn)
  39. SC: Set Ticking State (Optional)
  40. SC: Step Tick (Optional, the Notchian server sends this regardless of ticking state)
  41. SC: Set Center Chunk
  42. SC: Chunk Data and Update Light (One sent for each chunk in a circular area centered on the player's position)
  43. SC: inventory, entities, etc.

Offline mode

If the Notchian 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.

Versions 1.20.5 and newer support protocol encryption in offline mode, in which case the Encryption Request packet can be sent with Should Authenticate set to false, and both the client and server should not authenticate with Mojang. However, it's currently not possible to configure the Notchian server to do this.

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: Ping Response
  7. Both sides close the connection

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

I think I've done everything right, but…

…my player isn't spawning!

The Minecraft client will wait at the "Loading Terrain..." screen until late in the login sequence. As of 1.21, in order for the client to spawn, it must have received a Game Event packet with event 13 ("Start waiting for level chunks"), and at least one of the following conditions must be met:

The client will also spawn after spending 30 seconds in the loading screen, even if it never received Game Event 13.

In past versions, you could either (1.19.3 through 1.20.1) send the default spawn position packet or (pre-1.19.3) send the player position packet. In general, try sending packets that inform the client about the player's position in the world in order to get past the loading terrain screen.

In version 1.21, it became required to send the known packs packet with minecraft:core version 1.21.

As of 1.21, the minimum packets that need to be received and sent by the server in order to get the client past the loading terrain screen and into the world appear to be:

  1. Receive Handshake
  2. Receive Login Start
  3. Send Login Success
  4. Receive Login Acknowledged
  5. Send Clientbound Known Packs
  6. Receive Serverbound Known Packs
  7. Send multiple Registry Data
  8. Send Finish Configuration
  9. Receive Acknowledge Finish Configuration
  10. Send Login (Play)
  11. Send Game Event, Start waiting for level chunks
  12. Send Chunk Data and Update Light and/or Synchronize Player Position (see above)

The most difficult part of this may be sending any necessary NBTs in the Registry Data packet. Note that if you tell the Notchian client you have 0 known packs, it will blatantly lie to you, so you will probably need to record one from the standard server and replay it. Or you can find someone who has done that already, for example in Norbiros' gist. You can also find JSON representation of this packet in PrismarineJS/minecraft-data repo on GitHub.

…chunks are randomly showing and disappearing!

The Notchian client only reliably renders chunks surrounded by other loaded chunks on all sides. See Chunk Format#Tips and notes.

…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.

...some of the packets I expect to receive seem to be missing or too short

You may be misusing the socket API. In particular, it is invalid to assume that the amount of data returned by calls to recv (or equivalent, depending on the API you're using) relates to packet boundaries in any way. There are no "borders" in a TCP data stream, only bytes. Regardless of how any two consecutive packets are sent, the receiver may get one packet, then the other, both at once, half of one, then the rest of both, or any other permutation of buffer sizes adding up to the total size of the packets. The only correct way to know where one packet ends and another begins is the packet length field, and you need to be prepared to handle multiple packets in one buffer, packets split across multiple buffers, etc. (as well as length fields split across multiple buffers!)

Similarly, depending on the API being used, a send call may also not guarantee that its whole input buffer is sent (consult the relevant documentation for details). This may also cause the connection to appear to hang during the login process, since the server will be left waiting indefinitely for the rest of the packet to arrive.

One reason why packets sent separately may arrive at once is Nagle's algorithm, a feature of many TCP implementations intended to improve efficiency particularly for applications making lots of small send calls. It is not the only reason, though, and disabling it should not be seen as a solution to the problem discussed here. Nonetheless, the delays it introduces are detrimental to real-time applications like Minecraft, so the Notchian client and server disable it, and you should too. This is typically done by enabling a socket option called TCP_NODELAY. Especially when disabling Nagle's algorithm, you should group multiple packets sent during the same tick in one send buffer for the best performance.

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.