High-Level Client/Server Design

The server has to be able to send things like player updates at a relatively high rate, with a relatively low latency. Ideally, the "reaction time" between a keypress and movement is <10ms (a nice round number for human-noticeable latency), not counting network latency. That would mean we could just run a local one-player server for singleplayer.

The idea of tiered priorities to organize async IO is becoming more and more appealing. Each tier holds a priority queue of closures, ordered by completion deadline. We do not process lower-tier actions before a higher tier is complete. (Note that actions may schedule other actions).

Warnings should be added for when the queue is growing too quickly, or when too many things are being processed too late.

We should also audit these actions for things that can be processed greedily (i.e. before their actual deadline). Interval-based actions (e.g. rendering) can be responsible for scheduling their next iterations, so that the overall rate of an action is unaffected by greedy processing.

Client

• Priority 0
• Receives blocks from the server.
• Queues blocks for loading. 
• Receives world updates.
• Moves the client.
• Removes obsolete surroundings from render state.
• Requests blocks from the server.
• Updates the render state.
• Receives entity updates.
• Updates the render state.
• Receives user input events.
• Sends the server player updates.
• Updates the render state.
• Priority 1
• Renders at a regular interval.
• Priority 2
• Loads queued blocks.

Server

• Priority 0
• Acks new clients.
• Register client listen addresses.
• Open a new connection.
• Sends clients initial world state.
• Queues terrain block requests.
• Applies player updates from clients.
• Priority 1
• Updates the world at a regular interval.
• Sends world updates to clients.
• Unload blocks from the octree.
• Requests terrain blocks.
• Priority 2
• Loads/generates queued blocks.
• Sends blocks to client.
• Loads blocks into octree.