Optimize servers

[Rafale25]

servers it could be the client running all of the collisions check and loading. That way server should be less loaded.

 

[jayman38]

This might help, but clients already need to load resources like blueprints and textures.

1. You'd need to farm the calculations out to three random clients at least, and run a comparison to make sure that they all agree (to avoid any one client from cheating or otherwise poisoning results.)
2. If any clients return a disagreeing value, you have to either accept the quorum/popular vote, which is subject to poisoning, or else just calculate the result on the server, which is what you wanted to avoid in the first place, to avoid further lag on that particular calculation. (versus sending out a whole new set of data to process to a new set of random clients, which may result in the same return)
   
3. The calculation thread IDs (or whatever you use to identify the calculation) will need to be random to avoid prediction and manipulation by the clients. (A client cannot be allowed to know, for example, if a given collision check is related in any way to that client's activity.)
4. The server will need to monitor average throughput and only use clients that have a good, speedy connection to the server. Otherwise, the time saved to have the client run a complex calculation will be spent on transmitting a spreadsheet's worth of data. In short, along with a random ID, the server will need to upload, in real-time, complete blueprints to the client.
5. Furthermore, to avoid hinting at whether the client is involved in its own calculations, multiple, unrelated blueprints need to be uploaded at once and all calculated, with only one result being the "true" result that is needed. For example, the server will need to upload three different collisions to be calculated, given (sample) designations of A, B, and C, with collisions between blueprint 1234 and blueprint 4321 for A, blueprint 2345 and blueprint 5432 for B, and blueprint 3456 and blueprint 6543 for C, with C being the only required blueprint (maybe the other blueprints are random planets, space stations, or pirate ships).

The end result: We have slightly reduced the server load (the collision check load has been replaced by a hopefully-less-intense load of blueprint tracking, id tracking, and a few random numbers, plus the data needed to pull data from the other clients with the same calculations, to agree upon the same result), and have massively increased the load on the network. It might be worth it in cases where a server has massive bandwidth to trade for a lighter processing load.

The catch: If a coordinated troll group or a single troll with multiple client connections can coordinate an attack when few or no other clients are online, they can identify the "real" calculations and what collisions are being referenced, and can then manipulate the results to their benefit.

Generally, network bandwidth is the more serious bottleneck in any real-time-action game, so it will probably be a rare situation where this computation-client-farm will be useful for Starmade. I personally feel that it would be a better investment of Schine's time to optimize the server code to either make better use of multiple nodes and cores (cloud processing/server farm) or else optimize it to use some sort of OpenCL code to farm out calculations to any available onboard GPUs (This would be a big boost to single-player games, where the CPU tends to be used more than the GPU, but could also take advantage of servers that have a lot of GPUs, such as former Bitcoin farms).

 

[nightrune]

You can't do it on the client since the server must be authoritative to stifle cheating and exploits. You never trust the client. If people didn't cheat it would be fine, but you can't.

 

[Valiant70]

This might help, but clients already need to load resources like blueprints and textures.

1. You'd need to farm the calculations out to three random clients at least, and run a comparison to make sure that they all agree (to avoid any one client from cheating or otherwise poisoning results.)
2. If any clients return a disagreeing value, you have to either accept the quorum/popular vote, which is subject to poisoning, or else just calculate the result on the server, which is what you wanted to avoid in the first place, to avoid further lag on that particular calculation. (versus sending out a whole new set of data to process to a new set of random clients, which may result in the same return)
   
3. The calculation thread IDs (or whatever you use to identify the calculation) will need to be random to avoid prediction and manipulation by the clients. (A client cannot be allowed to know, for example, if a given collision check is related in any way to that client's activity.)
4. The server will need to monitor average throughput and only use clients that have a good, speedy connection to the server. Otherwise, the time saved to have the client run a complex calculation will be spent on transmitting a spreadsheet's worth of data. In short, along with a random ID, the server will need to upload, in real-time, complete blueprints to the client.
5. Furthermore, to avoid hinting at whether the client is involved in its own calculations, multiple, unrelated blueprints need to be uploaded at once and all calculated, with only one result being the "true" result that is needed. For example, the server will need to upload three different collisions to be calculated, given (sample) designations of A, B, and C, with collisions between blueprint 1234 and blueprint 4321 for A, blueprint 2345 and blueprint 5432 for B, and blueprint 3456 and blueprint 6543 for C, with C being the only required blueprint (maybe the other blueprints are random planets, space stations, or pirate ships).

The end result: We have slightly reduced the server load (the collision check load has been replaced by a hopefully-less-intense load of blueprint tracking, id tracking, and a few random numbers, plus the data needed to pull data from the other clients with the same calculations, to agree upon the same result), and have massively increased the load on the network. It might be worth it in cases where a server has massive bandwidth to trade for a lighter processing load.

The catch: If a coordinated troll group or a single troll with multiple client connections can coordinate an attack when few or no other clients are online, they can identify the "real" calculations and what collisions are being referenced, and can then manipulate the results to their benefit.

Generally, network bandwidth is the more serious bottleneck in any real-time-action game, so it will probably be a rare situation where this computation-client-farm will be useful for Starmade. I personally feel that it would be a better investment of Schine's time to optimize the server code to either make better use of multiple nodes and cores (cloud processing/server farm) or else optimize it to use some sort of OpenCL code to farm out calculations to any available onboard GPUs (This would be a big boost to single-player games, where the CPU tends to be used more than the GPU, but could also take advantage of servers that have a lot of GPUs, such as former Bitcoin farms).

You are quite correct, and this is a pretty good explanation. There are some things that can be completely client side, like debris physics for example, but on the whole the meaningful things need to be server-side. Only calculations that have no impact on other players whatsoever can reasonably be moved client-side.