guide [Guide/Article] A better understanding of client-server communication of WT

[Vonarian 2,888]

Hi!

Well... I will directly go for the main topic " A better view over server communications ": I shortly want to explain when and how we can say there is a server issue.

Before everything, I have to describe a few things:

Ping : Latency and delay between the communication of two machines, usually server-client.

PL : Packet Loss--> client and server have to communicate with each other in a real-time form. A very simple example is a WS or Web-socket connection, this connection needs a very stable and good connection because both sides are "listening" to each other... By listening I mean waiting for a command/message/packet from each other, what happens if we lose some packets? There are a few packets usually transmitted to maintain the connection, they are only a few bytes but are very important, they are like a bridge between the two sides, if the bridge's structure gets destroyed or gets wobbly the sides will fail to maintain the connection and communicate with each other.

So let's have the connection between WT client (aces.exe on Windows) and servers explained in detail (at least the detail I can give!):

1. Keeping the connection alive: Similar to what I have explained above, there are some packets of data transmitted to maintain a connection, like an indication of "I am still waiting for a command".
2. The player commands: I click on "purchase" to buy a modification... let's say this command has two parts: The command the client sends, the response the server gives, the PL part can have a real impact on this part, you send a command and want a response to finish the process of buying the modification. *... (Explained at the first *).
3. Player's real-time actions: Somewhat the most important sort of data transmission is here. "Every" action made by the player has to be sent to the server and a response is requested as well.  ***...
4. Other player's actions: Pretty similar to the one above, there are sometimes over 23 other players and each of them has their own data and packets.
5. Processing the request/received data: This is what makes hamsters sweat! I need to decode and understand the received data, and imagine so many of them are damaged ****...
6. Processing some other client-side data: Online games, including WT, require a very high rate of data transmission between both sides (client/server), they have to keep track of player's location, etc.  #...
7. Confirming the data: Sides have to know each other's states  ##...
8. Showing the connection info: Simple, Ping and PL at the bottom-left of the screen ###...

 

*...  Imagine the client fails to send the command, 100% PL out, which means you didn't even send the request, the "Processing operation" message comes up and nothing happens, the loading indicator keeps turning around the circle and the client keeps trying to send the command. Usually, this packet is easily trackable if it's not sent or is sent because it's client-side and the machine has to send the command if the issue is on the machine itself, then the client keeps sending the packet 'til it gets to know it is sent to the router/data source, if it's the modem router/data source which is failing to send the packet, two things happen:

1. The data source indicates I cannot send the data
2. The data source does not indicate properly

• In the first case, the client sends the data again and waits for a response (can get into a loop and a timeout *$*  at last)
• In the second case, the client waits for the response, if it doesn't get the response after the required time, timeout (Usually cancel button appears).

The issue is on the cables: It's the data source which needs to check this part, either indicates there is a problem and notifies clients, or smth similar to the second case above happens.

*$*  Timeout: I set a meeting for 5 minutes later, the person comes 20 minutes when I already have "timed out".

For a WT example, it's the cancel button, if both client and server do not indicate anything and fail to communicate with each other this will end up in a timeout situation, there is a maximum waiting time for the response and if the game doesn't receive the response on time, it will cancel requesting and cancel button appears.

***...  Imagine we hold "D" in our plane to roll in the right direction, the transmitted data is simply like this: The key pressed, the vehicle,  what pressed the key , how long the key is held, on what altitude, speed, map, weather, etc. it is...

I have simplified the packets! There are much more that needs to be transmitted and a response is requested, what I have found so far is WT is dividing a packet that can contain all the data I have said above, in multiple packets, so if one of them is not sent, others can be sent and the amount of PL is decreased, this will decrease the "pressure" on connection and makes it more stable and healthy, I have said all of this to indicate that the usual >0 - 10% PL can be because of this (one of the reasons), packets have different sizes and types, so all connections do not handle them in the same way, for example, my useless modem will fail to handle WT connection's packets and die but the mobile hotspot I use doesn't fail to handle the connection (This is why connection type is asked)

What pressed the key : EAC and WT are in touch with each other under the hood, EAC prevents access of unknown applications from accessing RAM values and prevents modification of them, and also, keeps track of data sent to WT (pressing a key sends a command which is data), if the data is unusual and abnormal and is some sort of "modified", you get disconnected from the server and get "Disconnected: EAC violation" warning. So "what pressed the key" is also important for the server, maybe EAC is not enabled

****....  Processing all the received data, giving a proper response, handling damaged packets, and requesting them again:

Sounds simple? Nope! I guess it's obvious for everyone that the data sent to servers is not just a "raw" sort of data, they are encoded, compressed (usually), and then sent. The server needs to decode the data and make them "readable" and decompress them, then read them, understand them and prepare a proper response, encode, compress and send them (the same happens on the client).

Now the damaged / improper data: This can sometimes lead to crashing a server, fortunately, WT servers are prepared for such a situation and they "handle" the damaged packets, they indicate the missing data and request the client to send them again (this will double the ping), a damaged packet is usually caused by high packet loss or a semi-stable/semi-dead connection, like when your ping immediately goes to 999 and PL is about 70-90%, so what happens here is (for example) the movement command is not completely executed and both client and server wait for the proper response/request from each other.

#...  It may sound funny but your FPS in WT when you're in an online match is also dependent on your connection quality with the server!

How? So let's say we're in point A having 60FPS and our connection has a hiccup, both server, and client "predict" the location of the player, which means when you are moving forward at 20 kph, your next frame's location is already processed by the game  and server , so the GPU/CPU can have a lower latency in processing the next frame. But if the server and client are in conflict between frames, FPS drops and freezes "can" happen. Because you're simply giving different data to Processing Units and they fail to process the proper frame and sometimes wait for the proper data (freeze) or have a delay in processing that frame (FPS drop or freeze). (This is why performance log is requested)

##...  I am the server, I want confirmation. I am a client, I want confirmation!

I would call this synchronization, I'm sure you have seen flying vehicles and or planes hitting the ground without damage, this is because of an unsynced connection between server and client (WT), the client is processing frames and its own data that the vehicle has to go forward or plane has to fly, but the confirmation is done by the server, the server needs to indicate to the client that the vehicle should be destroyed after hitting the ground, but when the connection is dead this doesn't happen at all.

###... The client has to be aware of its connection quality with the server and at least make the user aware of the state. But there is something to note: The indicators do not show everything and can miss some moments. This is why a tracert is also requested in a lot of reports, that shows everything in detail and shows what the packet passes to reach the server. So if you see lag and other connection-related stuff, do not really expect to see everything right after the issue, the Ping/PL down there can show everything's fine but there actually is something wrong the game is not showing.

 

 

Let's explain what happens if there are problems in connection:

• Lag / Abnormal behavior of my/other vehicles :

Somewhat the most common issue, usually caused by high Ping/PL but is not always "visible".

How can we know if it's the server or it's our side? --> If we say each server handles a match, and that match has 24 players (12 on each side), the issue "should happen for multiple players" to say it's the server, why? Well, a server is not like a person who tries to understand your words if you can't speak that well, like a baby who is learning to speak but is not yet ready and is not to possible understand, but is instead like a machine asking for proper data and packets, if it fails to "understand" the packets, then it has to make some up and vehicles fly and immediately go crazy, goes away... comes back...goes away ...comes back

What actually happens with high PL/Ping is somewhat similar to this one, your machine and client are trying to communicate with the game servers but they fail to give proper data (packets) or give packets/data with delay and not on time, what happens now?

1. Your vehicle doesn't move properly like you hold "D" to go right but it happens with sometimes up to 10s delay (this is 10,000 ms ping).
2. Your vehicle is dead, you get to know it after 5s or even later
3. You fire a shot, nothing happens, you hear the client-side sound and your vehicle looks like it's reloading, but it's not doing anything because there is something very important, "synchronization" between server and client
4. You destroy someone, you sometimes see the game log saying you destroyed someone but nothing on the screen and the enemy vehicle stays alive
5. You hold "F" to repair, the repair indication circle gets filled multiple times but nothing happens as the server is not yet aware of the command.
6. Etc. etc. so many more examples can be given

• Ghost shells :

Both server and client-related.

What actually happens is still similar to the previous one, but I will explain it separately.

What happens here, is shortly a combination of high Ping/PL, for example, you turn your turret to shoot someone, the turret is turned and fire, goddammit nothing happens! If you check client replay, you will see what you saw the moment of the "Ghost shell", but if you check server replay, there are four cases:

1. You didn't turn the turret at all
2. You didn't fire at all
3. You turned the turret but didn't fire
4. You turned the turret but fired in the air.

Not saying this is all up to the client to handle these cases and it's not a server issue at all, but you already know that if the client fails to have a proper connection, the above cases can happen which lead to a ghost shell

• I'm dead or not :

I'm sure many of us have seen this case, I see my name in the log that someone destroyed me, but I can still move my turret, look around and Oops... everything starts to get synced, the damage indicator indicates a fully blacked-out vehicle and I am on fire

• Cannot go back to hangar :

WT has to indicate I want to go back to the hangar from the current match and close the connection with the current server, but both PL/Ping doesn't let us do that, because you are either not sending a request or not receiving a request (PL in/out).

Is there any way we can decrease these connection issues and prevent their results? Yes!

1. Restart your machine
2. Keep your drivers up-to-date, especially the ones related to Wi-Fi, GPU/CPU (and iGPU on some laptops)
3. Keep your OS updated, some updates can help fix some connection issues
4. Avoid using VPNs, proxies, and similar stuff, War Thunder is not VPN-friendly that much, it fails to make so many connections both through the internet and in a local form, this will lead to so many errors and crashes)
5. Reboot/Reset your data source, this can re-initialize the connection between your machine and the source, leading to the end of some errors
6. Add WT to firewall whitelist
7. Stay close to Wi-Fi and data source
8. Close useless applications in your machine
9. Clear WT's cache and check the integrity of game files (Check my signature)
10. I don't know everything

Just a tiny note for VPNs: VPNs in WT are NOT supported, mainly because of security and maintaining proper connectivity.

 

So this is it, this was what I knew while writing all of this, I hope it can be useful / informing for everybody!

Thanks for reading,

Vonarian.

Edited January 15, 2022 by VonarianTheGreat