Difference between revisions of "Protocol FAQ"

From wiki.vg
Jump to navigation Jump to search
(Updated to 1.3.1)
Line 13: Line 13:
 
The recommended login sequence looks like this, where C is the client and S is the server:<br /><br />
 
The recommended login sequence looks like this, where C is the client and S is the server:<br /><br />
  
C S : Connects<br />
+
#Client connects to server
C → S : Sends handshake<br />
+
#'''C->S''' 0x02 handshake
C S : Sends handshake response<br />
+
#'''S->C''' 0xFD encryption request - server sends its public key and 4 random bytes
C S : After authenticating (if needed), sends the login packet<br />
+
#Client generates symmetric key (shared secret)
C ← S : Either kicks (invalid login) or sends a login response<br />
+
#Client authenticates via session.minecraft.net
C ← S : Sends pre-chunks and chunks and entities<br />
+
#Client encrypts these 4 bytes with the servers public key.
C ← S : Sends spawn position<br />
+
#'''C->S''' 0xFC encryption response - client encrypts shared secret with server's public key and sends along with encrypted 4 bytes
C ← S : Sends inventory [Need to verify this since inventory changed] (beta 1.1_02: looks like Window items with type=0, then a Set slot with window id = -1 and slot = -1)<br />
+
#Server checks that the encrypted bytes match
C ← S : Tell the client they're ready to spawn by sending a position + look packet. '''Note''': The stance and Y should be swapped when the server sends it to the client (See [[protocol#player_position_look_0x0d|Protocol Page]])!<br />
+
#Server decrypts shared secret with its private key
C S : Sends a position + look packet to confirm the spawn position, with the stance and Y swapped back to the correct positions<br />
+
#Server checks player authenticity via session.minecraft.net
 +
#'''S->C''' 0xFC encryption response - empty payload meaning two zero length byte arrays and two zero shorts
 +
#Server enables AES stream encryption
 +
#Client enables AES stream encryption
 +
#'''C->S''' 0xCD - Payload of 0 (byte)
 +
#'''S->C''' 0x01 login
 +
#'''S->C''' : Either kicks (invalid login) or sends a login response
 +
#'''S->C''' : Sends pre-chunks and chunks and entities
 +
#'''S->C''' : Sends spawn position
 +
#'''S->C''' : Sends inventory [Need to verify this since inventory changed] (beta 1.1_02: looks like Window items with type=0, then a Set slot with window id = -1 and slot = -1)
 +
#'''S->C''' : Tell the client they're ready to spawn by sending a position + look packet. '''Note''': The stance and Y should be swapped when the server sends it to the client (See [[protocol#player_position_look_0x0d|Protocol Page]])!
 +
#'''C->S''' : Sends a position + look packet to confirm the spawn position, with the stance and Y swapped back to the correct positions
 
</blockquote>
 
</blockquote>
  

Revision as of 05:25, 7 August 2012

People very, very often have questions regarding the Minecraft Beta 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.freenode.net.

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 have a script that monitors for new versions of the client and notifies us, allowing us to quickly document new packets.

What's the normal login sequence for a client?

See Authentication for communication with minecraft.net

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

  1. Client connects to server
  2. C->S 0x02 handshake
  3. S->C 0xFD encryption request - server sends its public key and 4 random bytes
  4. Client generates symmetric key (shared secret)
  5. Client authenticates via session.minecraft.net
  6. Client encrypts these 4 bytes with the servers public key.
  7. C->S 0xFC encryption response - client encrypts shared secret with server's public key and sends along with encrypted 4 bytes
  8. Server checks that the encrypted bytes match
  9. Server decrypts shared secret with its private key
  10. Server checks player authenticity via session.minecraft.net
  11. S->C 0xFC encryption response - empty payload meaning two zero length byte arrays and two zero shorts
  12. Server enables AES stream encryption
  13. Client enables AES stream encryption
  14. C->S 0xCD - Payload of 0 (byte)
  15. S->C 0x01 login
  16. S->C : Either kicks (invalid login) or sends a login response
  17. S->C : Sends pre-chunks and chunks and entities
  18. S->C : Sends spawn position
  19. S->C : Sends inventory [Need to verify this since inventory changed] (beta 1.1_02: looks like Window items with type=0, then a Set slot with window id = -1 and slot = -1)
  20. S->C : Tell the client they're ready to spawn by sending a position + look packet. Note: The stance and Y should be swapped when the server sends it to the client (See Protocol Page)!
  21. C->S : Sends a position + look packet to confirm the spawn position, with the stance and Y swapped back to the correct positions

I think I've done everything right, but…

…my player isn't spawning!

After sending the common-sense packets (Handshake, Login, Inventory, Compass and Pre-chunk/Chunk pairs) you need to finally send the player their initial position for them to leave the "Loading Map" screen.

…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 (0x0A) through Player Position & Look (0x0D)).

…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 7x7 square of chunks, centered on the connecting client's position, before spawning them.