Dear forum visitor,
It looks as though you have not registered for a forum account, or are not signed in. In order to participate in current discussions or create new threads, you will need to register for a forum account by clicking on the link below.
DeletedUser61
Guest
Overview
This thread is a very deep dive into how distributed Client/Server applications obscure latency. We'll address several closely related issues, and will then provide a few links if you want to dig even deeper.
Network Latency and Throughput
A great many of our Stream Errors are caused by, or aggravated by, a fragile network connection. Ookla provides one of the more effective connectivity tests, and especially so for the connection between your location and your Internet Service Provider, aka The Last Mile.
In game, your Trade window is an effective way to check the integrity of your internet connection, and your latency. All of the change of state requests (mouse clicks) are sent to the server and it's the server reply that provides you with the changed images.
Congestion and Denial of Service Attacks
You have no doubt realised that early evening is when we see the most lag and congestion. Rush hour on the internet is no different than rush hour on the freeway. Similarly, if a server is seeing more requests than it can handle, it will start shedding users and delaying additional connection requests, as it attempts to keep up with the remaining users.
Network attacks are far more common than you might suppose. They can range from flooding a Domain Name Server, to timed attacks on a particular server in order to deny your opponent the opportunity to make defensive responses to your actions.
Firewalls, Virus Protection, and Ad Blockers
These types of programs monitor your incoming data stream, and "protect" you from some of the more nefarious internet miscreants. Some of the concern is hype, some of it's idle mischief, and some of it is malicious. As the various Flash, Javascript, and html5 widgets are used on a great many websites, those applications are juicy targets for the hackers.
We're not going to tell you HOW to do this, merely that you should. To err is human, but to really mess things up you need a computer. You may discover that you can add the Elvenar domains to your list of approved sites, and thereby avoid the delays associated with the additional processing and buffering of incoming data packets.
Cached Objects
Your browser and, to a lessor extent, your Flash client, stores objects that it might be able to reuse, such as the background of your city, the graphics for your buildings, and the background for forum pages.
The code objects are typically serialized and validated with a hash code. When the server needs to build a page, it sends the Client the Serial Numbers of the objects that it needs, and where it needs them, and it's up to the Client to ask for a fresh copy if there's not yet a local copy. You can easily observe this behavior by clearing your browser cache, and noting that it takes substantially longer to build your own city, and the cities that you visit, during the next pass.
If you have several corrupted objects (with bad hash codes), from either partial downloads or local storage problems, then it will take the client longer to wade through the pile. Also, the more time that you spend preparing and checking hash codes, the longer it will take to do anything useful. Games are typically optimized for quick response times, on a fairly stable network, so the hash signatures are usually pretty small. Indeed, there may be no hash code protection at all, in which case the user will need to recognize that something has "gone wrong" and clear their cache in order to get rid of the corrupted objects.
Client Side Exploits and Bots
Other than the cached objects, very little information about the STATE of your city is stored locally. Several years ago it was fairly common to see automated "user" programs and cheater programs that directly manipulated the memory area that was, in theory, only accessible through the game interface. You may have heard of Gold Farmers.
Predictive Client actions
Modern Client/Server applications, including Elvenar, use a very different approach. When you click on something, TWO things happen.
Server Updates and Checkpoints
As soon as the Server gets the action packet, it will update the server status accordingly and will reply to the Client regarding the new status of the city AS OF a certain client packet. Let's look at another example:
To prevent folks from cheating (by manipulating local memory) and also to mask latency, the client PREDICTS what's going to happen, but the server state is the only reality that actually matters. The Client reality is a mere convenience.
This thread is a very deep dive into how distributed Client/Server applications obscure latency. We'll address several closely related issues, and will then provide a few links if you want to dig even deeper.
- Network Latency and Throughput
- Congestion and Denial of Service Attacks
- Firewalls, Virus Protection, and Ad Blockers
- Cached Objects
- Client Side Exploits and Bots
- Predictive Client actions
- Server Updates and Checkpoints
- Synchronization with the Server
- Buggy Code
- Task Manager - Network Activity
- Further reading
Network Latency and Throughput
A great many of our Stream Errors are caused by, or aggravated by, a fragile network connection. Ookla provides one of the more effective connectivity tests, and especially so for the connection between your location and your Internet Service Provider, aka The Last Mile.
In game, your Trade window is an effective way to check the integrity of your internet connection, and your latency. All of the change of state requests (mouse clicks) are sent to the server and it's the server reply that provides you with the changed images.
- Open your Trade window and select the Place Offer tab
- Place and CONFIRM a few small trades
- Open the Your Offers tab and DELETE the offers. Your browser client does NOT delete your trade, but rather waits for instructions from the server.
Congestion and Denial of Service Attacks
You have no doubt realised that early evening is when we see the most lag and congestion. Rush hour on the internet is no different than rush hour on the freeway. Similarly, if a server is seeing more requests than it can handle, it will start shedding users and delaying additional connection requests, as it attempts to keep up with the remaining users.
Network attacks are far more common than you might suppose. They can range from flooding a Domain Name Server, to timed attacks on a particular server in order to deny your opponent the opportunity to make defensive responses to your actions.
Firewalls, Virus Protection, and Ad Blockers
These types of programs monitor your incoming data stream, and "protect" you from some of the more nefarious internet miscreants. Some of the concern is hype, some of it's idle mischief, and some of it is malicious. As the various Flash, Javascript, and html5 widgets are used on a great many websites, those applications are juicy targets for the hackers.
We're not going to tell you HOW to do this, merely that you should. To err is human, but to really mess things up you need a computer. You may discover that you can add the Elvenar domains to your list of approved sites, and thereby avoid the delays associated with the additional processing and buffering of incoming data packets.
Cached Objects
Your browser and, to a lessor extent, your Flash client, stores objects that it might be able to reuse, such as the background of your city, the graphics for your buildings, and the background for forum pages.
The code objects are typically serialized and validated with a hash code. When the server needs to build a page, it sends the Client the Serial Numbers of the objects that it needs, and where it needs them, and it's up to the Client to ask for a fresh copy if there's not yet a local copy. You can easily observe this behavior by clearing your browser cache, and noting that it takes substantially longer to build your own city, and the cities that you visit, during the next pass.
If you have several corrupted objects (with bad hash codes), from either partial downloads or local storage problems, then it will take the client longer to wade through the pile. Also, the more time that you spend preparing and checking hash codes, the longer it will take to do anything useful. Games are typically optimized for quick response times, on a fairly stable network, so the hash signatures are usually pretty small. Indeed, there may be no hash code protection at all, in which case the user will need to recognize that something has "gone wrong" and clear their cache in order to get rid of the corrupted objects.
Client Side Exploits and Bots
Other than the cached objects, very little information about the STATE of your city is stored locally. Several years ago it was fairly common to see automated "user" programs and cheater programs that directly manipulated the memory area that was, in theory, only accessible through the game interface. You may have heard of Gold Farmers.
Predictive Client actions
Modern Client/Server applications, including Elvenar, use a very different approach. When you click on something, TWO things happen.
- Your action will be serialized, queued up, and sent to the server within a few seconds.
- Your client will "predict" what the server is going to do, and will update the client display accordingly.
Server Updates and Checkpoints
As soon as the Server gets the action packet, it will update the server status accordingly and will reply to the Client regarding the new status of the city AS OF a certain client packet. Let's look at another example:
- In the trade window every single click goes to the server and the status doesn't change until the server replies. That's why you will be occasionally notified that "Someone else has already accepted this trade."
- A typical bug occurs when the Client is NOT updating a field or (it's tricky to tell the difference) when the server is not responding with an updated value. Expansions have been an on-going source of confusion, as have been the quests that were completed while the client was off-line. In either case the user will see a mismatch that clears up when they force a browser tab reload, by clicking on the circle icon that's just to the left of the URL field.
- Checkpoints are actually fairly obvious. If you reload your browser tab during a battle, or at any other time, the server will return you to wherever it thinks you SHOULD be, according to the most recent information that it has actually received from the client, regardless of how much further you've actually gotten.
To prevent folks from cheating (by manipulating local memory) and also to mask latency, the client PREDICTS what's going to happen, but the server state is the only reality that actually matters. The Client reality is a mere convenience.
- The Client sends a stream of serialized packets to the server
- The Server receives those packets and updates the server accordingly
- BOTH communications lag and server lag will slow things down, and it's tricky to tell which is which
- Meanwhile, the Client has sent more packets and the user is well ahead of the server.
- The Server then replies with a status packet AS OF a certain received packet
- The Client then displays the "real" information, rather than its prediction.
- The Client then discards the acknowledged packets.
- The Client has a timer, and expects to see an appropriate response within a very few seconds.
- The Client MAY try to resend the ignored packets, depending on whether the likely problem is communications lag AND/OR server lag.
- After 30 seconds or so, the user will get some variation of "Stream Error, we were unable to reach the server. Please reload your browser tab."
- This activity is quite apparent during Auto-Fight, as the Server actually controls the fight while the client merely positions the units where it's told to put them. The characteristic high latency behavior will be that the OPPONENT takes forever to attack when it's their turn, because they have to WAIT to hear that your Client has finished moving stuff around, and the damage that was done, and THEN the Server can tell the Client what to do next.
Last edited by a moderator: