Single Threaded (Hercules/rAthena) Vs Multithreaded Design (Horizon)

[Sephus]

So, what if I was to say that having a road with 5 lanes is better than having a road with 1. There is a lot more room for cars and they can pass through on different lanes. We can categorize roads by high speed or low speed vehicles. We can bring in more cars to move and pass through in other lanes. We can't do this if we have only 1 lane. That is the benefit of a multithreaded service or a multithreaded server. 

There are several reasons why multithreading is required for a server but a lot of them are complicated. I'm just stating what is simple to understand because most of the community will topple over if they begin to read what is the reason for multithreading and why use it. So to simplify it I've given you a basic example of a 5-lane road which can handle more cars than a 1 lane road can. Cars are just examples of users and users are just examples of players. To understand the analogy, try to picture a machine with only 1 lane for users. We design and develop software for users, to process the users we require a thread or a process which accepts multiple inputs and provides you with an output after some calculations. This thread or process has a single flow of execution. Within this flow of execution, the program calculates its output and provides it to you at the end of the execution cycle.

Just like that, a server has many thousands of calculations. Each time the server is provided an input, it has to compute and provide an output to send to the client. Similarly, the client has to provide an output to the server. But the client cannot provide an output to multiple servers, it only provides an input to one server. Similarly, the server cannot provide an output to one client, it provides an output to multiple clients. So, the basic design of a server is different from a client. 

Most servers today are single threaded and designed to facilitate only one client at a time. This means that if two clients were to concurrently access the server and send information to it, one client will be denied. This is unnoticeable because two clients may almost never access the server at the same time and also because the server handles connections very quickly. However, in the event that it does happen, if the server is not ready to accept the request, the client will be denied. Which is why server designs usually accept the request in one thread, and quickly pass it on to another thread before becoming ready again for another request. This strategy is known as a reactor pattern strategy.

In Horizon, we not only use a reactor pattern but also a multithreaded pattern for the game logic, scripting and persistence environments. So while the network is being accepted almost always with minimum margin for error, the game logic is also serving multiple maps in parallel, the script-vm thread is servicing multiple users in parallel, and persistence is doing its work in parallel to the other services that Horizon provides. Note here that parallel doesn't mean that the work is done sequentially. Parallel means that there is another flow of execution (thread or process) which does the job simultaneously, along with the other threads. This is not easy to picture or understand in the beginning but after a long time of research and study, you will begin to get the logic behind using parallel systems and why they are more beneficial in serving clients than other strategies or technologies.

So while we have multiple threads here, eAthena and other servers use one thread because they have been coded to be written for execution in one thread. Coding a server to execute in multiple threads requires very difficult and complicated locking strategies for example "one lane is **locked** so that a car from another lane can enter it". We need something like this to happen because once a car is done travelling a distance in one lane, it needs to switch lanes to get to another location so that it can further its journey. Simply put, if one user is processed in the network thread, the user needs to be passed on to the game logic thread so that it can further its journey in the server, before being provided an output. 

Coding a server is really a lot more complicated than how I've explained it above and it is because of this that I want to explain it in simple terms so that many and more people understand it. The primary reason why Horizon was coded was because we want multiple lanes in our servers and not just one lane which processes everything. We want to have different lanes doing different jobs and having them separate their strategies and resources from the other lanes. We want the more users to be processed in a single lane by allowing the 1st lane to pass its user to the game logic lane as soon as possible instead of having the 1st lane compute and deliver everything to the user. The "passing-along" strategy works effectively for many users as they are quickly retrieved from the network and quickly handled by the server. The output is quickly provided to the client or clients handled by the server and we are done processing the request from the network.

This is the simplest way I can describe how multithreading works in Horizon or in a server, with this strategy thousands of players can be quickly processed and in a better manner than how they are processed in Hercules or rAthena. This is quite fundamentally a great design for a server and will be suitable to facilitate 10s of thousands of players online, while Hercules or rAthena manage to serve only 500-1000 at most without lag or deterring performance. This kind of lag is __unnoticeable__ but prevalent in servers which have 1000 players where all of the software's processing depends on one core of the CPU. How much can one CPU handle? A really good quality server can at most handle 1000-2000 players in a single second of time. One second of time is a very long time in computer technology. How many players would have experienced this issue in your server and quit before you even understood the problem or how it affects the userbase? It takes a lot more power to process a player-base larger than 2000 users and we can't afford to wait for a long time before the application finishes and handles all requests, we can't depend on single core CPUs anymore. We need want to use to our advantage the remaining cores of the CPU and make sure that we process larger populations simultaneously rather than in one single core or process.

In Horizon we can configure the amount of cores used by each "lane" or each division of the **business architecture** - Networking, Script-VM, Game-Logic and Persistence. This architecture is scalable and provides enough processing power required to handle over 10s of thousands of users if used well. Not only is the architecture scalable but the code that has been written to create it is maintainable and done so using the best features and practices in C++.

With this technology, we can found our new server project and begin to think in terms of the costing benefits that this will provide to the user or server owner. Having to increase their server resources every time their population hits 2000 is now actually worth-while because we're able to utilize the different resources in our server. We can't do this in Hercules and rAthena. Even if we procure more than 1 vCPU we would still be using only one because the software restricts us from using them and our player base is what suffers. Have you seen any player base go above 2000 and maintain their players? No. In the past 10 years I haven't. 

Ergo, choose Horizon. Make sure we get the development support we need and make sure that we are given preference over the other projects because doing so will allow you to truly benefit from the vast and powerful world of computer technology that there is and is left undiscovered because of the software limitations that are constraining your abilities.

Lets make this software a great and powerful software like it should be. Lets make Horizon superior.

~ Sephus