How Cubes Should Be Rendered In Minecraft

Rendering something in Minecraft (currently) the multiplayer side won't load blocks because it doesn't render properly or sends too much data. The data sent isn't either received fast enough or the scene renders faster than the data is collected. My suggestion; for every multiplayer map keep the chuck data in temporary files. Only send data when a block is updated. Use checksums. Don't use compression unless initially loading. Compressing and decompressing takes more time when only a few or hundreds of blocks are loading. Perhaps make a protocol for compression like HTTP does with gzip. (some pages are loaded using compression and some aren't based on the server headers and which page is loaded) I did read somewhere that compression is used; I meant to not use compression all the time. (use headers to determine whether content is compressed) Also; to insure temporary files work with the server and client, have the client keep track of the data it has and where the player is so that it can request data from the server if it is in the correct area. I've been on a server that loads only a part of the spawn area, because the client probably doesn't tell the server it needs a refresh of it. I played a minigame where no blocks were loading for the rest of the game. I think that was about 5-10 minutes, and that means it wasn't the server lagging, because I still had a connection to it. Players were moving in the server and items worked, but no blocks were being loaded. (as in even if the temporary files are being used, the client thinks it has all the temporary files (chunks) that it needs to work). After all of this works; allow or disallow the client to save chunks that aren't temporary if that works better. This would be more like caching data. When you finish all of that (including the caching); make single player mode work like this. It would be best if single player mode worked like this, so that there could be a test of it. The server doesn't need to exist. If the program uses; CreateProcess() (Windows), fork() (Linux), or clone() (Mac OSX); then the process will be the same except you need to use pipes instead. Pipes in Linux and Mac OSX are just as reliable as creating a TCP/UDP socket. I don't know how well it works in Windows.