Suggested Revision of Architecture

I have some suggestions for Improving the multiplayer server engine.
Does anyone else experience the lag on Movements.

Generally to build real time multiplayer engines. The server should replicate actions and state, rather than replicating player position.

The client should have all the necessary Game State to render the actions as a results of doAction(action, playerstate, gamestate);

So quick little breakdown
Client:

• Entire Game State
• Renders Player Actions dependent on Current GameState & PlayerState
• All Players are considered Actors on a Scene. Even the current player who is running the client.

Engine (Where engine is a subset of client):

• Manages the SceneGraph.
• Iterates over Registered Actors Applying Actions from a Queue (Limit this complexity of this by iterating only over those actors who have registered actions since the last frame)

Server:

• Handles Client Connections.
• Replicates both the Client State and the Actions to Apply
• Actions must be replicated in FiFo order.
• Client State is eventually consistent so out of order packets may not be an issue.

Either the Server or Client or Both can handle optimizations such as RedBlack trees.
Server can restrict registered receivers based on a function of (gamestate, playerstate)
Client can do the same as well, but we lose the bonus of restricting network overhead.

As far as Voxel-* is concerned there needs to be a way to register plugins with the replication framework. Something similar to level-manifest probably

No files, tests, or entry points are named. Start by locating the server, client/engine, replication framework, and level-manifest code, then determine whether the repository has an existing movement or state-sync implementation. The issue does not define a scoped deliverable or acceptance criteria, so the architecture and meaning of “done” need maintainer agreement first.