Was looking into creating a proxy server for Server Port (so clients wouldn't have to reconnect with a client patch), so I had to look at the network protocol. Anyway, when you login or move/teleport to a new area, the server sends your client the chunk data for any nearby chunks. It is a single packet for each chunk (16x16x128). After that, if a block changes while you are near, it sends you a packet just to update that particular block. The chunk data uses the ID=0x33 packet. However, it has a few fields: Minimum position (minX, minY, minZ) Size of block( sizeX, SizeY, sizeZ ) Compressed size Compressed Data The key is that it can handle blocks of data that are less than a full chunk. The data is compressed via the gzip algorithm, so it would allow blocks to be sent to clients while creating much less latency. Anyway, I am thinking of something like getServer().updateRegion( Block[][][] blocks ); Just to give an example of the potential savings. I ran gzip -l */*/*.dat on a random world and it came back with 96% compression ratios. I am thinking that this could help with plugins like MoveCraft. A 40*40*40 craft updated one block at a time requires 64,000 packets. Each block has at least - type (1 byte) - data (0.5 bytes) - light from blocks(0.5 bytes) - light from Sun(0.5 bytes) This comes to 2.5 bytes per block, and that ignores other data due to network overhead. If the craft moved once per second, then that gives 160kB per second. If you have 10 players, then that is 1.5MB/s upload speed. The actual block update packet is actually 14 bytes, so nearly 1 MB/s upload per player. If region writes were possible, then this could be cut down substantially. Smaller blocks may not compress quite as much, but many crafts are likely mostly air, so there is room for compression.
I'd suggest a Set rather than an array, but this would be very useful for plugins that update large sections of blocks.
Cool. So, the server already kind of does this? It doesn't send blocks to clients immediately, it waits to see if nearby blocks will also be updated? The new process would be - suspend updates for the region - update the blocks using setBlockAt - resume updates It will detect that there is a massive change, and send it as one 0x33 packet? Since it is already partially happening, I guess that means that the benefit is less?
Well currently what I think (Haven't looked too much into it) happens is that it flags changed blocks as dirty, and every tick it goes through the dirty list and sends them as bulk updates to everyone near them.
Ahh, I see. There are a few packets that it can send. 0x33: -> sends a cuboid region (compressed) 0x34: -> multiple blocks in a chunk (4 bytes per block + header) 0x35: -> single block (11 bytes per block) If a plugin updates 100 blocks in the same chunk, then it might be using the 0x34 packet. Moving from 35 to 34 would reduce bandwidth by a factor of 3. However, moving to 0x33 could drop it by a factor of 20 (depending on how well the compression works). The 0x33 packets also seem to be the only ones that include lighting info, so it might only achieve a factor of 10. Maybe the expectation is that the client can recalculate lighting for a single block change, but would be expensive for a full chunk.
If I remember correctly, from the wiki, the thought was that Notch doesn't want the client to have to recalculate the lighting when a chunk is loaded, but after that, it's fine. (http://www.minecraftwiki.net/wiki/Alpha_Level_Format/Chunk_File_Format#NBT_Structure - the BlockLight tag).
I'm gonna go ahead and put this thread on watch, and if this gets working, whatever I need to do to make MoveCraft compatible will so be done.
