Server:BlakeScape
Introduction
BlakeScape was the first (known) multiplayer RuneScape emulator ever released to the public. It was based on the Winterlove release by wL, and was created by Daiki (and others?). It is estimated to have been created on 29 October, 2005.
Contents
The Listener - "server"
The listener is a thread that isn't paid much attention to in BlakeScape, but infact if it weren't there, BlakeScape simply wouldn't work. The Listener is something that listens for incoming connections to the server, and accepts them when one comes in. Once accepted, the listener instructs the PlayerHandler to make, store, and run a new client object. The listener is part of the "server" class, and operates as a standalone thread. The listener is structured like so:
loop:
1. wait for an incoming connection
A. accept when one comes in
B. notify the PlayerHandler to create a new client
2. loop back to the beginning
Game Engine - "PlayerHandler"
The engine of the entire system is called the PlayerHandler. It is run in the server classes main processing loop, and runs at a rate of approximately 500 milliseconds. Packet processing has been thrown in with the engine and this creates problems when people spam the server with packets. The engine is structured like so:
loop:
1. loop through every player
A. process packets for each player (this is where game logic is handled - process() and parseIncomingPackets())
a. loop and process each packet indefinitely until we have no more packets to process for this player, then move to the next player
B. set necessary appearance/player-updating flags
2. loop through every player (a second time)
A. prepare update packet for this player
B. loop through every player (inside this players loop)
a. prepare update packet for this player for each player
3. loop through every player (again)
A. reset all updating flags that were set in loop 1
4. wait 500ms minus the time it took to process (so timing stays accurate)
5. loop back to the beginning and start all over again
That entire process happens twice per second in BlakeScape, however BlakeScape servers have their timing tuned to operate slightly faster than the protocol was designed for - 500ms instead of 600ms. When the cycle time exceeds 600ms, players will experience server lag. Take a look at loop 1, step A->a, you will notice that it processes every packet that each player has at a time - this means that, if the player has 1,000 packets coming in (because somebody is spamming), it will process 1,000 times before it even moves onto the next player and eventually to the rest of the cycle. This is why spamming a BlakeScape server can cause immense lag for every player, because you disrupt the timing system of the engine.
I/O Processors - "client"
When a connection is accepted by the listener, it starts a dedicated "client" thread for that player, which handles the login of the player and then processes all reading/writing with the socket stream. This means that every player has a dedicated thread for communicating with the game client end of the connection. A thread can be seen as a platform on which code can run independent of other code in the same computer process. This is an inefficient approach seeing as the threads use a lot of memory and they are sitting idle most of the time while the rest of the server is processing.
Miscellaneous Explanations
I will now take some time to explain some common things about how the BlakeScape server operates and some of its problems.
Source of Crashes
If you are familiar with BlakeScape servers, you know that they are incredibly unstable and unreliable because they suffer from server-wide crashes and therefore they need a restarter to restart the server every 30/60 minutes just incase it crashes. The common source of this problem is as follows:
When data is transmitted over the internet, it is sent in the form of "packets", or chunks of data that, in the RuneScape protocol, contain the following information:
opcode, size, data
Sometimes, however, random things will happen when the packet goes across the internet where it becomes "malformed", or messed-up. The server was not programmed with the capability to handle malformed packets in mind, so the server will attempt to treat the malformed packet as a regular packet, and chances are that the server will run into an error when it parses data that it doesn't expect. This would normally be okay, except for the fact that the engine has no handling of errors, also known as "exception handling" programmed into it - when the engine encounters an error, because it is not handled (which can be easily done), the engine thread will exit entirely and the server will crash.
Scalability
The BlakeScape engine itself is relatively scalable, though it's implementation of processes are not very efficient (i.e. runs on a single thread while updating is read-only and therefore can be dispatched to a threadpool, update packet blocks are not cached when they easily could be, packet processing could be put into the IO threads to prevent the engine from being exploited with spamming packets, etc.) it is fast because it uses low-level resources to store players (an array instead of an arraylist) and is very procedural in nature. The design of having one dedicated thread for every player causes the server to use a lot of unnecessary memory and processing power, something known as "overhead", to manage all of the threads and this IO design counteracts the reasonably fast engine. In modern implementations of BlakeScape servers (i.e. devo, etc) all of the game logic is piled on top of the packet processing, which exponentially increases the drawbacks of having packet processing handled inside the engine instead of making use of the dedicated IO threads (which should be used for packet processing anyways, seeing as they are networking threads). I would rate the original BlakeScape source with a scalability of 6/10, but I would rate current implementations scalability as 2/10.
Extendibility
The server itself is not very easy to add onto, because it is not a very object-oriented design. The base itself is messy and very procedural, while it is written in a highly object-oriented language. This makes it difficult to work and develop with because the design is not very flexible. It only has one implementation of inheritance, and that is between the "Player" and "client" classes. On the plus side, the base itself has quite a lot of comments about how it works and about the protocol that one can learn from, although some of the comments on the protocol are incorrect.
Potential to Learn
Because the BlakeScape base is very procedural (straight-forward) in design, it is easy to use as a tool to learn from, because instead of focusing on how objects work together and relate with each other, you can focus on the protocol and server design implementations and therefore I can say that the BlakeScape base is a very good source to learn from through studying and tinkering-with.
Significance
The BlakeScape base is very significant to the RuneScape Private Server community as a whole. It was the first multiplayer server ever released, and also included quite a bit of information about the (at the time of release) quite unknown RuneScape protocol. The BlakeScape server is also the most common server base in use today, seeing as it is the core of 95% of running server projects. I believe the server was more of a proof of concept and research application instead of a commercial grade server. You can compare the BlakeScape base and it's extensions (i.e. whitescape, cheezscape, etc etc etc) to the Linux kernel and it's distributions (i.e. Ubuntu, Fedora, etc etc etc) except for the fact that BlakeScape was a proof of concept and was not made to run in a commercial scale environment while Linux is indeed the opposite. I believe it is being misused by being used as the base of almost every server that has ever existed, but it is not completely useless seeing as you can learn quite a bit from it.
