Player Features and Ideas Discussion

B-R5RB topped out at 2,670 players active at the same time and the time dilation was horrible.

And players are still wanting larger fleet fights (or at least less time dilated). Also, the increasing number of drones leads to heavier server load.

The following solution is on my mind for a few months already, and I finally decided to share the thought with you.

Unfortunately, there are no deeper insides into the EVE cluster, so some things might be speculative, so correct me if I am wrong.


Current situation:

Currently each server handles one or more solarsystems, depending on the numbers of players in the system.

When a pilot traverses from one system to another, his current session data gets serialized and transfered to the new server.

This consumes time.

Also, the server handles and calculates the LOS for each ship (i.e. the grid), and also the data for that ship.

It also calculates damage and repair systems.

This causes heavy load on the server, multiplied by the use of drones, because those must be calculated as additional ships.


My Suggestion:

Move the handling of ships to dedicated servers!

This way, each system node could concentrate on other data, and only inform the other ship servers about a new ship in their space.

Calculations of the grid could be done by each node seperately, but also here, the nodes could exchange related data. Also damage and repairs would be easier handled by each node sending an information to the targeted ship node.

Drones could easily be handled by those nodes as well.

Also, the serialization of sessions would fall flat, because the only thing a system node needs to know is what ship ID entered the system, and broadcast it to all the other ship IDs in that system.


Also, from a monetary point of view, this could be a step forward for CCP, because this would greatly reduce the costs of new servers. Instead of spending several thousand dollars for a new and more powerful system-node, you could just plugin lets say a Raspberry PI for each new account, or more powerful servers and use it for more ships at once ( or use them for handling carriers and their drones).


As I said before, there is not enough information about the details of the EVE cluster to make more deep suggestions. Also, this would probably mean a major revamp of the server software (even though this might be easier than it seems).

Hope you like the idea, and maybe a dev could take a look into it.

Do you even know how data handling works when multiple IDs that are related to each other are handled by several nodes?

It's not as simple as you think.

There is also the issue of user side processing all that.

It depends on how you do the setup. In how far would you consider this a problem, if all that is done is basically exchanged between the ship nodes?

Actually, there's a wealth of information about EVE servers, and the first part of it is that it's single threaded, meaning "just move feature X to another box" isn't as straightforward as you might think.

For your specific idea, remember that ships will need to interact with each other in real time, with some things affecting multiple ships, some ships affecting multiple others, and a whole array of possible variations in-between. Essentially each of the mini servers you suggest would need to still do near on the same amount of work that a single server does now, just on top of that, they'd need to communicate with every other server and maintain a synchronised chain of events.

Beyond that, if they did choose to implement an idea like this, the first step would be rewriting the server software to be able to handle all of these components running asynchronously, which would pretty much require them to rewrite it in a manner that supports multithreading (or very close to it). If they did that, the problem would already be solved, as they could distribute the processes over multiple cores.

Essentially, if they were willing to rewrite their server software, the solution is incredibly simple. Since they aren't that's where systems like BiaB get developed to try to move the manageable parts off of the node.

But every other node would still need to know everything that node is doing in real time, since circumstances would be ever changing. Either each ship server would need to take in all of the information for every action for all other ships on grid and work out if/how it affect the ship its serving, then feed that back to the node server, or each server would have to constantly stream status updates to all other servers with all other servers taking that into account at exactly the right time so sequences of events aren't broken. It's not just a simple case of a ship ID being passed around once in a while.

I think the DEVs are already working on something akin to what the OP has described... it's called "Brain in a Box" (if I recall correctly) and the idea is to separate the "hard" ship and character information from the actual server calculations (or something like that) and put them on seperate nodes that are designed to pull from each other as needed rather than crunch it all in one go.

The main hurdle they are having (again, if I am recalling correctly) is straightening out the back-end legacy code without causing said code to wail in some unholy elder tongue and consume a DEV's brain.
Thankfully though the DEVs have a large supply of alcohol to help them in their work.... unfortunately this is also what resulted in the mess we see now as alcohol makes one give up half their brain for the unholy coding protection it provides.

God help us.

Which would be eliminated, because they wouldn't need to serialize session data anymore and transfer it to another server. Ship-nodes don't change!

It's basically exactly this! What I said in the OP was a suggestion. We strip out the ships from the system-node so that the data that needs to be transfered is minimized.

I see the point that a ship-node might not be handling all calculations. However, they could do calculations and stream them directly to the user. Especially damage/repair.

Thats not much, but that is server-load anyways!

Why should the system node be interested in more than the positions?

Even IF the system node should need more info: applied damage and repairs/cap/missile impacts, etc. could all be calculated by a ship-node and be given to the server as a result. No need fot the server to calculate it.

Why should other nodes be interested in the amount of shield/armor/hull a ship has left?

What would prevent the nodes from informing the user itself?