Graphs, Graphs, and Data; an expansion of Wildfire

As you guys may know, I haven’t exactly been on the ball with updates to the Wildfire system, until now that is.
I’ve been working on an update to the system that utilizes an external database system instead of SQLite, but the biggest part of the update is to recording of statistics.

‘Recording of statistics?’ I hear you say; fear not for it’s actually for a greater purpose- public server tracking.
The ‘biggest part’ of the update I mentioned before is actually adding tracking & server browser functionality to All servers will be tracked (when a connect request is made, Wildfire will store the server name, time, and other stuff), and this tracking will be reflected on the website as graphs.

The server browser isn’t finished yet (which is why those exclamation triangles are there- the data can’t be retrieved at the moment as the data is not present).
I’m hoping to add direct connect functionality (aka, launch straight into a server from the site).
There will also be graphs similar to those on the Overall Network Activity page (perhaps in more detail).

All this is done via the new Wildfire API, which I will also be making public on (or shortly after) the new update is applied.

Any ideas for graphs that you’d like to see?
Let me know!

Wildfire: 6 Month Review

The current instance of Wildfire has been running for 6 months now, so I thought I’d compile a small review of Wildfire so far…

There are currently 248 registered users, with an average of 54.3 new users each month (up from <30 in January, February, and March) in the last three months.

This statistic alone is impressive seeing as Crysis Wars is almost dead.

44.8% of players are Russian, while 39.9% use anonymous addresses:

  • Russia: 44.8%;
  • Unknown: 39.9%;
  • Poland: 7.3%;
  • Hungary: 0.8%;
  • Europe (General): 0.4%;
  • Spain: 0.4%

Wildfire sees around 50 billion queries each month from its users and servers!

I was surprised at this one too, but it makes sense given that each query is around 32 bytes with 200 or so of them coming in each second (can rise to around 10,000 per second on a busy day):

Thoughts on Game Design: Why use UDP for multiplayer?

It’s common knowledge in the games design industry that many online multiplayer games transfer data via UDP instead of TCP, but why?

To answer this, we’ll have to dig deeper into how TCP & UDP work, and the specific scenarios that online gaming has to deal with. To start with, TCP is slower than UDP; this is because UDP is a continuous data-stream and doesn’t care if the other end exists or not, meaning that UDP doesn’t have to wait for a response from the other end in order to send the next packet. TCP is ‘polite’ and waits for a response from the other end of the connection, and as a result is more reliable as data is guaranteed to arrive(with UDP there’s no guarantee that data will reach its destination) from one end of the connected socket to the other.

In an online game, do players with high latency seem to jump around the place? That’s UDP. What’s happening here is that the data the player’s client is sending isn’t complete (or packets are congested), and as a result the server makes it seem like the player is ‘teleporting’ in the world. With TCP, this wouldn’t happen but on-wait sockets will consume CPU time and as such it is theoretically possible to crash a server that uses TCP in this way. Remember that the number one rule is to never assume the client is well-behaved- program in some protection!

With TCP, the operating system handles the connection in its entirety; if the destination is unreachable the connection is instantly dropped. This is practically useless for online gaming as connection hiccups are common; if TCP was used just a single ‘dead’ packet will result in a disconnection.  In UDP, the application decides when to ‘drop’ the connection; this is useful as it allows the game to wait for more data if the connection is intermittent. This however turns into a disadvantage as it is possible for an unprotected server to crash if a client sends a packet of greater than 65,535 bytes. Implement DDoS protection to scan the size of a packet before it enters the server properly.

This vulnerability exists in Crytek’s Crysis 1 and Wars online multiplayer games (unsure about Crysis 2 and 3); this meant that any UDP packet sent to the server’s IP and port resulted in the server crashing. With online gameserver trackers this lead to a widespread spree of attacks in 2010-2011 where someone (might add that I know exactly who this person is…) kept crashing Crysis servers via this vulnerability,
Via the game SDK I was able to patch this by adding a function that dropped packets greater than 65,535 bytes, which instantly protected my servers from this attack. Please, if you’re going to develop an online multiplayer game, ensure this vulnerability is patched.

Also remember that if we had 16 players connected to a gameserver, every time something happens to a player the 15 other players need to know about it; imagine if we were using TCP and one of the packets dropped. Yes exactly, we’d have to wait until that packet is resent and the server gets a reply for the gameserver to continue processing data, and this in turn holds up all the other players. The packets coming in while the dead packet is dealt with will have to be dealt with too, resulting in congestion. With UDP, we have none of that (the most recent packet is dealt with, and the older ones are simply dropped).