My main character is Tom Deal and…
… Yes …
… i was there in the great battle of Jan23 in 9-4RP2, between GoonSwarm Federation and Pandemic Horde (backed up by its allies of GOTG), where only in one system (9-4RP2) managed to fit almost 6000 players.
The conclusion of that fatidic night, besides our victory over Goons,is that it is practically impossible for one server with current technology, even the fastest and efficient one, to support 6000 client accounts interacting and changing massive information between them, on a decent time and required onlinebasis.
Even with the help of the famous and boring TIDI, server response times under these conditions are painful, at minimum, and almost all the time impossible to manage. For example, on the battle night we had to wait more than half an hour to complete the lock of an enemy ship and almost the same time to enter warp. In fact, it was almost a miracle that the server didn’t collapsed.
So, since that day, as a challenge to my self, I started to develop a concept that I share with you today, that can be the solution of the problem of crowded systems, solution that aims to dilute for multiple servers (mirror servers) the activity until here supported by a single main server.
Through the replication and division of the main server elements by two or more mirrored servers, this event which I called SYFRAG, happens when the number of customers in one system reach the maximum of 2000 clients.
In fact, as you can check on the diagrams I attached to this text, in general, the contend of a system are composed by two element types, the MDE (Main Duplicable Elements), like stations, gates, belts, and so, and RDCE (Regular Divisible Client Elements), like the name means, the clients inside their ships, and, whenever there is a SYFRAG event, the MDE identically replicates in the new servers (Mirror servers) while the RDCE are distributed in an equitable manner by the mirror servers.
Through this way, the original server clients are divided by two mirror servers, lowering the stress of processing the game, which, even not perceptible to the common player, distributes the game processment two servers (or even more if the client number rises) and the massive work that a server as to do under this conditions.
The first phase of the SYFRAG (SYFRAG 12 – 1st escalating – See the below schemes) occurs whenever the server reaches the maximum of 2000 customers, dividing this number by two mirror servers. The DEFRAG 21 process (that is the counter operation or the roll back of SYFRAG - De-escalating) occurs when the total sum of the two mirror servers lowers below 1250 customers.
The SYFRAG 24 (2nd phase of escalating) occurs whenever one of the two mirrored servers reaches the top number of 2000 clients, fact that triggers the event which divide the total customers from two mirror servers (SYFRAG 12 State) between four new mirrored servers. The DEFRAG 42 (operation contrary to the SYFRAG 24) occurs when the total number of clients in the four mirrors became less than 2500.
In summary, this escalating process can be even bigger as it is easy to understand (8, 16, 32 mirrors), which means that one crowded system can gather (theoretically) almost an infinite number of customers (32 * 2000 = 64 000 customers would be the condition for the SYFRAG 3264).
And the client?
The client continues to see on is monitor the total nº of RDCE, however they can only interact directly with the clients that are resident on the same server that they are, and this common server clients have to be properly tagged on the overview. By direct interaction I mean clients that can engage, kill or be killed between them self. Clients in different servers can’t interact between each other.
And the fleet?
The elements of the fleets (RDCE), when SYFRAG occurs, are divided equally (whenever possible) by the mirrored servers. When this is not possible (odd situations) the distribution is random.
And the FC?
FC, despite being a client resident only in one of the mirrored servers for direct interactions purpose (in this case FC acts like an RDCE), he can also see (separated by color tag) all the clients resident in the different servers, which allow him to give specific order per server. However all clients of diferent servers can interact with their fleet FC, for Anchour purposes or Fleet Warp to FC purposes. In this case the position of the FC is present on all servers (in this case FC is an MDE) and all the client elements of the fleet can use these functions regardless of the server where FC is hosted.
And the Stations? And the market?
The stations are MDE, so once SYFRAG occurs, they are replicated but their damage info is divided by the number of mirrored servers, process that require an Online Date Syncro (ODS) of these damage values between all servers. Market orders and contracts are divided equally by the number of mirrored servers (odds are random distributed).
And the inputs and outputs in the system?
The mirror server RDCE distribution occurs at the time of SYFRAG, but also when there are new client entries on the crowded system, and this entries can happens through gate, cyno, or login. In this case the distribution process of clients through mirrors is similar to SYFRAG.
The outputs of the mirrored systems occur in a normal way, being 1 less client to all the mirrored servers sum.
What happens when SYFRAG or DEFRAG occurs?
When SYFRAG or DEFRAG event triggers, the game stops for the players that are inside the systemor entering it. During this process (may take a few minutes), a message appears on screen that says (SYFRAG escalating process is running. Prepare for battle). Something like this also for DEFRAG de-escalating process).
I hope that the above explanation of the concept was clear enough, and that this idea can help you (dev community) and us (player community) to have an even better game than we already have today, especially in the case of massive client system battles / gatherings.
I’m also at your service if you have any doubt that I can help to clarify.
RFASantosaka Tom Deal
SYFRAG BIG PICTURE