- Joined
- Feb 17, 2012
- Messages
- 1,552
- Reaction score
- 2,604
Hello players,
this pre-build has a completely new system to request and manage segment (chunk) transportation between client and server.
get it here: http://files.star-made.org/build/pre/starmade-build_20131010_001721.zip
EDIT: new one available: http://files.star-made.org/build/pre/starmade-build_20131010_023211.zip
(as always the user/pass is "dev". Be extra careful with pre-builds if you install them on game servers. It will be installed on the test server play.star-made.org:4242)
Technical:
The segment request method is one of the first things I have implemented for the game, as StarMade was coded for multiplayer from the beginning. With the addition of lots of core features and extensions, the code became ugly. I wanted to do a redesign for a long time to improve performance, and kill bugs that were hard to find in that code. Other parts of the code were already updated more often. As I learn more and more by coding, I hold myself to a higher standard accordingly, so parts of code, that were fine a few month before become ugly in my eyes.
Besides better synchronization between 6 basic threads, the network protocol for requests has also improved.
The threads are:
Network protocol:
The old method was to send a request for a signature to the server for each segment. The server would answer with a timestamp and if the segment is empty. Then the client would check with its cache if it already has a segment on that position that is as new as the timestamp in the signature. If yes, the segment is loaded from the cache, if not it is requested from the server (if not empty).
The new method combines signature and segment request: The client checks the cache-timestamp of the requested position, and sends a request containing that timestamp. The server will now compare the received timestamp with the one in the database, and will directly send back the segment if it's not empty, and newer in the server database. If it is empty, or if the timestamp sent to the server as new as the one in the server-database, the server will send back only a notice, so the client can either add an empty segment, or load the segment from cache. This new method gets rid of a complete round trip to the server which is a lot of overhead, and IO (network) waits.
The system needs testing though as it is one of the most crucial system of the game.
Thanks for playing StarMade,
- schema
this pre-build has a completely new system to request and manage segment (chunk) transportation between client and server.
get it here: http://files.star-made.org/build/pre/starmade-build_20131010_001721.zip
EDIT: new one available: http://files.star-made.org/build/pre/starmade-build_20131010_023211.zip
(as always the user/pass is "dev". Be extra careful with pre-builds if you install them on game servers. It will be installed on the test server play.star-made.org:4242)
Technical:
The segment request method is one of the first things I have implemented for the game, as StarMade was coded for multiplayer from the beginning. With the addition of lots of core features and extensions, the code became ugly. I wanted to do a redesign for a long time to improve performance, and kill bugs that were hard to find in that code. Other parts of the code were already updated more often. As I learn more and more by coding, I hold myself to a higher standard accordingly, so parts of code, that were fine a few month before become ugly in my eyes.
Besides better synchronization between 6 basic threads, the network protocol for requests has also improved.
The threads are:
- The request thread: periodically checks the surrounding of the player by intersecting bounding boxes to start new request chains
- The request manager thread: It determines which objects have work to do. It wakes up for a list of objects that have a non-empty request queue, works down those queues and goes to sleep again to minimize overhead. A thread per object is not an option since it would not scale with the overhead. The work includes determining if a segment already exists, sorting the requested segments by distance to the viewer, loading the timestamp from disk, and making the request to the server.
- The main thread: Called from the main update method, and basically does all the delicate stuff that needs to be done synchronized, for example adding/removing segments to the structure. No IO is done here to eliminate lag from IO waits
- The creator thread: This server only thread takes requests for segments that are not found in the database and generates the segment
- The network thread: Each client has a thread on the server. All requests, signatures, and answers are delegated to this thread, it transports the data over the network and stores it for the other threads to access
Network protocol:
The old method was to send a request for a signature to the server for each segment. The server would answer with a timestamp and if the segment is empty. Then the client would check with its cache if it already has a segment on that position that is as new as the timestamp in the signature. If yes, the segment is loaded from the cache, if not it is requested from the server (if not empty).
The new method combines signature and segment request: The client checks the cache-timestamp of the requested position, and sends a request containing that timestamp. The server will now compare the received timestamp with the one in the database, and will directly send back the segment if it's not empty, and newer in the server database. If it is empty, or if the timestamp sent to the server as new as the one in the server-database, the server will send back only a notice, so the client can either add an empty segment, or load the segment from cache. This new method gets rid of a complete round trip to the server which is a lot of overhead, and IO (network) waits.
The system needs testing though as it is one of the most crucial system of the game.
Thanks for playing StarMade,
- schema
