simcity-status.net - Under The Hood

This post will describe how the website I recently built for monitoring the statuses for the SimCity servers. As many already know, the SimCity servers has often been disconnecting and reconnecting during game-play. I have already been working on gameservers where latency can have a critical impact on the end-users experience of the game, as the client relies on updates each 500th millisecond from the server. Having any large latency in a system like this would let the users experience lag (and would get annoyed in most cases, as we all hate lag). The monitoring tool I made there was a windows program which communicated over a special protocol designed just for server monitoring. It provided me with information such as user statistics, database activity and other information that could be of my interest. It was all a simple windows desktop application displaying all the information on a diagram: 

 

 

 

 

 

 

 

 

 

 

 

This was one of my thoughts on how to monitor the servers, but I would rather provide this information to other users. The entire website is running on Windows Azure and is easily scalable by adding more web-worker-roles to push out information. In general, it consists of three parts: A web-worker role, the database and a background worker.

The worker role

The worker may be the most complicated part of the system, as it is in general the module which does everything, or at least large parts of the job. It has a update cycle of 60 seconds where it downloads a JSON file from EA's web-servers (http://worlds.simcity.com/parallelworlds.json) This file gives us information about which servers are available and their current statuses. Any update to a previous added server would be saved to the database. Each server would then get two HTTP requests. One on the "game" field, and one on the "websocket" field in the JSON file. Each request goes over HTTPS, as it is this protocol which the game is running over. And when the requests are either timed out or answered, the results are stored to the database.

The web-worker role

Having many people accessing the status page or repediatly pressing F5 in order to see if their server has any updates on its ping would be a nightmare for the SQL server. It is reasonable to cache the ping statistics in the background, as well as loading them (loading the servers per user request would cause a long wait for the website to load). Each host and its statistics for the last hour is stored to the web-servers memory and it will not nagg the database for new statistics within the next 60 seconds.

This has been a fun project where I have been able to explore new platforms (Windows Azure and the Azure SQL Servers), however, I would not have been able to end up with this result thanks to my friends helping me out on web-design and designing the cache part on the web-worker role, so big thanks to them!