So it's come to my attention that Minecraft servers are extremely chatty. Even a small one with just 5 or 6 lightly-active players can find itself uploading more than a Gigabyte each week. From the seems of things, this is because the server gives the chunks to the player far more times than necessary. It seems like each and every chunk is sent each and every time someone logs in or moves around, none of it gets stored locally except in RAM.
A single chunk is in excess of 32kB in size (this is assuming each block is only 1 byte in size, which I'm sure they're not), and essentially a 5x5 grid of chunks gets loaded around you. This means that simply logging in causes ~1MB (it's actually quite a bit more) of data to be uploaded each time. That's a lot, and there's no reason it needs to be sent each time.
Ways to rectify:
1. Keep a local copy of the map and load from that.
2. Only send chunks when the local copy differs from the remote copy.
3. Once loaded, chunks can be updated on a change-by-change basis.
Simple.
So how can you tell when someone's local copy differs from the remote copy? You compare them, of course.
How can you compare them without having to send the whole thing over? There's a few ways:
1. Add a "last updated" attribute to each chunk. The value (a date) will be generated by the server only and sent along with each chunk. Send the value from the client to the server to see if they differ.
The downside is that this opens the map up to a bit of tampering client-side. However, if the map is tampered with client-side, the server won't recognize it and will merely cause the client to desynch. The effect would be similar to falling into an unloaded chunk.
2. Checksums. Whenever a chunk is to be loaded, calculate the checksum of the local copy and compare to the remote copy.
The problem is the real-time distribution of checksum creation upon chunk modification. This can be done by either the client or the server. It depends on where you want to put the load since, on a busy server, there could potentially be a lot of checksums (fairly expensive operations) to calculate in a smallish amount of time. Can the server keep up with that? Can the client?
One way of doing this that could lessen the strain: Whenever a player modifies a chunk, the checksum is calculated locally and then sent to the server. Other players will then receive the updated checksum from the server.
This method assumes that we're operating in a thread-safe manner. Simultaneous updates to the same chunk should not be possible, but they'll mess with this method if they are. This method is resilient to tampering: Even if a checksum is incorrect, the worst that will happen is that the chunk will be resent upon loading.
For both of these methods, the handling of entities and items will remain the same. This suggestion is focused on reducing the needless transmission of chunk data.
As an added bonus, a local copy also means that we could, at some distance, release the chunks from memory (a novel idea, I know) without needing to have it resent to us again.
Here I thought this topic was on using the chat... still, great idea if it can be accomplished. From the sound of it, it could potentially fix or reduce occurences of the world hole issue people frequently get in SMP (where a chunk shows up completely empty). You have my support.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffA single chunk is in excess of 32kB in size (this is assuming each block is only 1 byte in size, which I'm sure they're not), and essentially a 5x5 grid of chunks gets loaded around you. This means that simply logging in causes ~1MB (it's actually quite a bit more) of data to be uploaded each time. That's a lot, and there's no reason it needs to be sent each time.
Ways to rectify:
1. Keep a local copy of the map and load from that.
2. Only send chunks when the local copy differs from the remote copy.
3. Once loaded, chunks can be updated on a change-by-change basis.
Simple.
So how can you tell when someone's local copy differs from the remote copy? You compare them, of course.
How can you compare them without having to send the whole thing over? There's a few ways:
1. Add a "last updated" attribute to each chunk. The value (a date) will be generated by the server only and sent along with each chunk. Send the value from the client to the server to see if they differ.
The downside is that this opens the map up to a bit of tampering client-side. However, if the map is tampered with client-side, the server won't recognize it and will merely cause the client to desynch. The effect would be similar to falling into an unloaded chunk.
2. Checksums. Whenever a chunk is to be loaded, calculate the checksum of the local copy and compare to the remote copy.
The problem is the real-time distribution of checksum creation upon chunk modification. This can be done by either the client or the server. It depends on where you want to put the load since, on a busy server, there could potentially be a lot of checksums (fairly expensive operations) to calculate in a smallish amount of time. Can the server keep up with that? Can the client?
One way of doing this that could lessen the strain: Whenever a player modifies a chunk, the checksum is calculated locally and then sent to the server. Other players will then receive the updated checksum from the server.
This method assumes that we're operating in a thread-safe manner. Simultaneous updates to the same chunk should not be possible, but they'll mess with this method if they are. This method is resilient to tampering: Even if a checksum is incorrect, the worst that will happen is that the chunk will be resent upon loading.
For both of these methods, the handling of entities and items will remain the same. This suggestion is focused on reducing the needless transmission of chunk data.
As an added bonus, a local copy also means that we could, at some distance, release the chunks from memory (a novel idea, I know) without needing to have it resent to us again.
-
View User Profile
-
View Posts
-
Send Message
Retired Staff-
View User Profile
-
View Posts
-
Send Message
Retired Staff