Registration Code (Part 1): w%kQ6
Registration Code (Part 2): b<#$1[*(cw~
In order to register on this forum, you must use the codes above. Combine them into one code (copy paste).

Tom Clancy's The Division - Networking Disaster

A place to rant about something, give constructive criticism or otherwise soft-flamming. (Direct hate, extensive flamming or similar will be removed. Keep it friendly.)
Post Reply
User avatar
Site Admin
Posts: 388
Joined: Sun Jan 04, 2015 11:23 pm

Tom Clancy's The Division - Networking Disaster

Post by atom0s » Fri May 06, 2016 9:58 am

In the recent times, a few websites released articles covering how horrid the networking model was in The Division. Mainly the fact that the server trusts the client too much about data that should not be trusted. Ubi took to their social media to try and downplay the problem and said they would have a response shortly. That said, their response was this manufactured blog interview between two employees of the same company: ... -gameplay/

Some of the more interesting things in this article is their admission to how some of their server side things work as well as what they have anti-cheat detection for. (Mind you, that is only server-side anti-cheat detection. There is no protection on the client currently.)

In the blog post, the employee being questioned admits to various data that is not handled by the server, which from their wording includes:
  • Position data (player movement).
  • RPM data (rounds per minute of the players weapon(s)).
  • Ammo data.
  • Aiming data.
  • Gun fire data.
From the article, players can easily assume that the data about their weapons is entirely handled on the client. However, they do mention there are server side checks for some things such as the RPM value. Which in the last weeks we have seen a few ban waves go out that players are all basically confirming were due to RPM hacking. Something interesting though is that the employee said that the timing of when your bullet hits is also on the client which is fairly confusing to hear. Essentially this means that you hitting someone or something is done on the client and then sent to the server. So you could effectively tell the server you shot someone without ever doing so by their wording.

Things like ammo and rate of fire are pretty weird to see handled by the client and just lead to exploits like the ones that we've seen already.
Along with the types of hacks out there that abuse other things like talents to achieve unlimited ammo.

The only thing here I understand being client sided is positional data. Especially given that this is not a simple FPS game, but is really an MMO behind the scenes. Something people often don't think about is what all the server is actually doing. Most gamers that have no concept of how coding works or how networking works all assume and call this game an FPS and refuse to include the MMO part in the name when actually the game is definitely an MMO.

Just because you are running around solo does not mean you are not connected to a server that is processing data for thousands of other players. Things are being processed in the background constantly on The Divisions servers about you and other players. Be it simple movement data, to shooting and killing enemies. Every player also has their own instance of AI information that the server is handling with some client sided cooperation.

Never Trust The Client
This is one of the biggest things to remember though when developing an online game. (Or really online anything.) The client should never be trusted for information. Even down to the basic login information, the client is not trusted. That data may be stolen, or contain malicious code attempting at a blind SQL injection. The data coming from a client should be treated as third-party data and nothing more.

Generalizing things down, there are two models of networking when it comes to gaming. (I understand there are thousands of under-the-hood layers and such, but this is just a generalized overview of the up-front face value.)
  • 1. Client Trusted Networking
    2. Server Enforced Networking
In a client trusted networking model, the clients data is considered valid and trustworthy to be applied to the servers local information. While there may be some validation on that data, it is ultimately used in the environment and can affect others. For example with a game, a player may tell the server "I just healed myself for 100 hp." and the server assumes this is ok and valid. However, that player may actually not have even done anything. Instead, they sent the server a health update packet to just tell the server "heal me" and the server obeys the request. Various games followed this model such as Phantasy Star Online back in 2000-2002 all the way up to recent titles like Terraria released back in 2011.

The client basically tells the server what to do which ultimately can destroy a game overnight. In Phantasy Star Online's case, the PC version of the game never made it out of beta overseas in the eastern part of the world. The game was riddled with problems and never got to see the day of light under Sega's ruling. The community later revived the game and created private servers to be able to play cross-platform. And again in Terraria's case, playing on a stock server that has no protections implemented is ultimately a disaster waiting to happen. The networking is so poorly implemented, a single player can join a server and destroy the entire map in seconds. Other things such as killing players without being near them, killing players without pvp turned on, and so on just ruin the game. The community around Terraria came to the rescue and built a server plugin system that implements anti-cheat systems and preventions from allowing these things to happen. But again, the community fixed it, not the game developers.

In a server-enforced networking setup, the server dictates everything that happens and approves requests by clients. Games like Minecraft make use of this type of environment for networking. The client is merely a UI sitting on top of network code that makes requests to the server. The client reacts to the responses given back from the server. While this is a much more secure method of networking it does come with its own downsides too.

For one, lag is almost always a thing on a networking model like this. And the larger scale you go in terms of players, the larger the lag. Because the server is handling every single request from every single player, there is some processing lag on the server due to resource requirements. However, this is when multithreading really shines in a networking model. Another fault of this model with lag is the ability to flood a server with small tasks that eat up processing time and resources. Depending on how the game is coded, simple movements can be a request. Simply pressing 'W' to move forward on your keyboard can be a request to the server. When this is the case, spamming the movement keys can cause lag on the server when done in large groups of people.

Another concern is rubberbanding. Syncing data between the client and server to ensure a seemly gameplay is rough to do on a server-enforced environment. While you will be moving, you may "snap" back to a previous location due to server lag. Client lag can also play a factor into problems here. Your slow connection can lead to processing delay and jumps in data returned from the server causing you to wobble in-game between movements and actions. This is when client-prediction comes in and helps the server assume what is going to happen and process based on that assumption. This can greatly improve performance and has been a massive part of many games such as the Half Life series, Counter-Strike series, Team Fortress series and so on.

Meeting In The Middle

While both situations have their ups and downs, meeting somehwere in the middle is more than likely a favorable option. Extensive data that is important, critical, and sensitive should NEVER be trusted by the client. In an FPS game things like ammo, rate of fire, bullet percision and hit location should never be trusted from the client. In an MMORPG such as WoW, things like your gold, items and so on should never be trusted from the client. Things that are resource intensive should be placed in a less secure transmission system but still have checks and balances in place to help ensure things are not being abused.

In The Division, a lot of what they covered that is handled by the client shouldn't be. Especially when the game includes pvp gameplay. I will agree that player positioning shouldn't be on the server as this is massively resource intensive, but there should definitely be checks in place. Some things in mind would be:
  • Player Positioning
    • While movement data is client sided, it should be validated on the server to some degree.
    • A player jumping large amounts of distance should be validated to be considered 'legit'.
    • A player moving faster than possible by the games mechanics should be validated. (As it stands now only 1 thing in the game increases movement speed, and not by much.)
  • Player Inventories / Items
    • A players weapon ammo and RPM should NOT be on the client. Players being able to effectively edit their weapons is absurd to ever allow.
    • A players talent calculations should not be handled on the client. Players being able to give themselves infinite ammo due to an exploit (within the client code) via a talent is absurd.
Something that Ubi / Massive need to realize is that their current checks and balances systems are not enough. A player should not have to "deal" with a hacker in the Dark Zone for weeks on end til a ban is finally placed. Let alone a 2 week slap on the wrist that does nothing. Someone new to the game that enters the Dark Zone and gets destroyed by a hacker abusing things like RPM hacking, infinite ammo, teleporting/speed hacking, no clipping, etc. like we see the most now is not going to stay. If a hacker is abusing these things, an instant ban needs to be happening or at least a kick from the game. If the game detects the player is RPM hacking, kick them. If the game detects the player has fired more bullets than their gun can hold (minus the talent to give ammo back on headsets etc.) and has yet to reload in the last minute, kick them. Players should not have to suffer at the hands of hackers because you are too afraid to get things wrong and kick someone innocent.

There is a huge difference between someone with a gun that is 3000 RPM vs. someone hacking with 9999 RPM. I'm sure the server can differentiate between who is the legit player and who isn't. Let alone the server knows everything the player has equipped, be it items, talents, buffs / debuffs, etc. It is impossible to say that the server can't make a valid and accurate calculation of what the players exact RPM should be compared to what it is currently.

As it stands now, this blog post basically confirms the problem people have with Ubi / Massive's handling of hackers. Unless you /report them, nothing is going to happen. They clearly don't look at their collected data otherwise. And to top that off, people that have been reported for hacking countless times, from WEEK 1 of the game are STILL running around the DZ hacking.

Let's not forget that the games CM Hamish Bode was on stream via Twitch and was in the DZ and was killed by a hacker. Guess what? That hacker is still running around the DZ playing. Surprise surprise...
Need a great web host? Check out:

Donations can be made via Paypal: ... Q2GRT6KUJN
Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest