The Minecraft Protocol

The Minecraft Protocol is a PITA to work with.

Let me first describe it for those of you who don't know: "packets" are simply a single-byte packet identifier followed by specific data structures, your primitives: bytes, shorts, ints, strings, floats, doubles.

There is no packet length prefixed.

That may be fine if every packet has a static length. But there are strings. How are they implemented? A unsigned short denoting the length, followed by the string encoded in UTF8.

The Notchian server implements this protocol using (>four) thread(s)-per-connection: it simply reads the packet using blocking calls. That works, but it doesn't scale very well. So now we have to think of a way to implement this using some form of asynchronous networking: async sockets, NIO, MINA...

My approach on my (now scrapped and deleted) Minecraft emulator project was to attempt to read out the entire packet every time we receive data. That worked, but it felt hacky.

I haven't been able to think of better ways.

For more information on the Minecraft Protocol, http://mc.kev009.com/Protocol

Use some form of network I/O that lets the OS notify you when data is available (I/O completion ports on Windows? Dunno what Unix/Linux has. All I know is there's something in .NET for it). Read whatever data is available. If there's a complete packet in there, handle it. If you have an incomplete packet left over, keep it around and use it the next time data from that client is read.

Wait, why are you worrying about scaling? I thought Minecraft servers require massive amounts of resources so you won't be scaling anyway.

That's my method. But it basically means parsing the packet every time data is received, which can be quite expensive.

And no, in the end Minecraft is just a bunch of blocks with 3d position.

How often are you left with an incomplete packet?

How often are you left with an incomplete packet?

In local testing, of course none, but you never know how bad the connection can get. Why does this matter anyway? That I could be left with an incomplete packet is good reason enough.

Enough reason to make the program correct in the face of fragmented packets, sure. But not enough reason to worry about its impact on performance if it only rarely happens in practice. They may never get fragmented if they're small enough.

If it actually is a performance problem, you could avoid reparsing the partial packet if you kept track of the parsing state along with the partial packet.

Enough reason to make the program correct in the face of fragmented packets, sure. But not enough reason to worry about its impact on performance if it only rarely happens in practice. They may never get fragmented if they're small enough.

If it actually is a performance problem, you could avoid reparsing the partial packet if you kept track of the parsing state along with the partial packet.

That would complicate things a lot.