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.