Join the new world

This is NOT an article meant to be red by admins or developers. They have shown not to give a damn about the community. Furthermore they seem to be utterly incompetent to write quality code, so writing this to the devs/admins would be a complete waste of time. This is an informative article aimed to educate the citizens of eRebuglik as to why they are experiencing problems. Any deletion of this article by admins (under the excuse of ill-placed communications with admins) would and should be viewed by every able-minded citizen as another attempt to save face by repression instead of working on improving eRepublik.

The troubles:
We all saw France fall yesterday, some savoring the success and sweet righteous revenge, some deeply saddened, some outraged. As an active participant in the war I witnessed an interesting event three days ago. Spain was attacking all five remaining French territories, The USA was doubling up the attacks on 2 of those 5, Great Brattain was attacked in some territories, and Northern Brasil was also under attack from Peru and it's allies. The French battles and the Brasil battle were started (and had ended) at roughly the same time, and they held a huge significance for all belligerents in the World War. As this was a regular eRebuglik day, the closing moments of the battles were riddled with server irresponsiveness, which prevented a lot of fighters on both sides from dealing all the damaged they intended. The French players complained vehemently and dubbed the Spanish 'masters of DDoS attacks', because the slowdown prevented them from winning a region they would easily win, and accordingly the Spanish (among other Eden citizens) were outraged at what they perceived to be a Russian hacker attack on the server carried out to foil their attempts at winning in Brasil.

So does two opposing sides blaming each other for the exact same thing which hurt them both seem a little bit odd to you? Not really, it's what happens in eRebuglik all the time, mostly as a result of developer incompetence. Sometimes it's bugs being abused (alchemist gold anyone?), other times it's poorly written code and poorly designed server architecture letting us down. The common theme is eRebuglik not working well.

The doubt:
I cannot and will not state that no DDoS attacks happened on that day. I lack access to logs which can shed light on the matter. I will make an educated guess that it didn't happen. My guess is based on the fact that these slowdowns are commonplace during the closing stages of battles, and that the eRebuglik staff are well versed in dealing with DDoS attacks by now. They even brag about solving most of them without us ever noticing anything in their ill-conceived eRebuglik Insider article celebrating the silly 800 day anniversary. One could argue that they are incompetent and can't deal with DDoS attacks, and that this occurs during the closing stages of major battles because someone is trying to get a tactical advantage these battles.

However, it is not logical for any of the waring states to engage in such behavior, and if you bare with me I'll offer a better explanation. The thing is, both sides commit the greater part of their armed services exactly during these slowdowns. If you were trying to win a battle by preventing the enemy accessing the server via DDoS attacks, you would instruct your own armies to fight BEFORE the attack. I insist that no such temporal discrepancy takes place, which makes a conscious and deliberate DDoS strategy improbable.

The demonstration:
Now I'd like all of you readers to type in the following: http://www.erepublik.com/en/battles/log/9040?how_many=1. At the time of writing there was 13 more hours to go until the battle closes, and if you're reading this later, please change 9040 with a battleID of an open battle. Now, you may not be able to understand the information contained in this link, but that's only because it's written in a way that makes it really easy for computers to read. In fact, it's not even meant to be used by people at all! It's designed to be used by 3rd party software that interfaces with eRebuglik (mostly scripts for Firefox). I know that at least one script exists which checks this every second, and one that checks every 15 seconds.

Now, for another demonstration, please type in the following address in your browser: api.erepublik.com/v1/feeds/battle_logs/9040/1. It is similar to the previous link, but there are two important differences. Both hold information on the battle in East Midlands, and both are intended to be read by computers, but the first one is on the live server (the one you use to play eRebuglik), and it has the current wall height, while the other one doesn't have this info and is stored in the so called 'API server'. There's another difference, which is not so easily notice😛 the first one is up-to-date, and gives you current information every time you refresh the page, while the other one changes only once per hour.

The explanation:
Since a lot of eRebuglik citizens aren't programmers I'll explain why this is important, and how it relates to the slowdowns. The live server is used to generate information for players,when they click on pages in their browsers, like you did when you clicked on this article. The API server is used to give information to computer programs and scripts. The difference between us humans and computers is that computers can read and analyse data a LOT faster. Before there were no feeds of information from the API server, and scripts (like eRep+) had to pretend to be humans and use the live (human) server to get information. They kept asking for information a lot faster then normal humans do and the live server didn't work so well (because it wasn't designed to communicate with computer scripts).

Then the eRebuglik team made the API server which was specially made for this role, and it banned scripts from using the live server. This worked well because the API server takes a snapshoot of the state of things only once per hour, and generates the information every hour. The same information is given to everybody for the next 60 minutes until a new information feed is created. This is good for programs keeping track of citizens, but not so good if you need market prices, monetary market prices or wall height (information which changes a lot faster then once in 60 minutes). Never the less, the scripts soon transfered to using the information feeds from the API server and all was fine.

Then, the dev team in all their wisdom, introduced two battle logs, the two pages I asked you to open in your browser. They knew full well that if computers ask the live server for information it will not be able to service all the requests, they created the API server for this exact reason! Yet, they created an information feed on the live server. Scripts were created to read this information, and all hell breaks loose.

The information generated on the live server isn't created once per hour. It isn't even created once per second. It's created EVERY single time someone request it. During the finishing stages of battles tanks use a script that, among other things, updates the wall information every second using this data from the live server. Imagine 500 tanks asking the live server every second to give them data on the wall. Every time a script asks for information, the server has to look it up (this means accessing a database), generate a web page (not directly, but by a PHP framework which is not optimized for such actions) and send the data to the script that requested it. It's not the network that can't handle this, it's the computer itself (CPU, RAM, HDD)!

And the persons using legal or illegal scripts are the least to blame for this situation. The programmers that work on eRebuglik are just awful. A good programmer would never create computer feeds on a live server. A mediocre programmer would do it, find out that it doesn't work, and then create a separate server for computers (like the API server). A god-awful utterly incompetent programmer would allow scripts to run on the live server, ban them and create a API server for feeds, then create feeds for scripts on the live server again like nothing happened. If we at least had mediocre programmers on the eRep developer team, I would explain to them that they need to create a static feed like they have on the API servers, have it refresh once per minute or so, and serve wall information in that way.

Unfortunately, this is not the case, and we will continue to experience slowdowns until they figure this out on their own, which might take a while. The point of this article is, I guess, to ask people to stop blaming each other for using DDoS attacks as a war tactic, and focus your anger on the real enemy: the eRebuglik staff.