Unstable connection to the TSO domain

[Posolsvetla]

Hi,

it has happened also in the past, but the problem started to pop up quite often:
The big portion of the packets sent to and/or from the TSO domain are lost.
As a result, the game is heavily unresponsive.
The problem seems to be at the Ubisoft ISP in France. Please see tracert reports in the attachments for the reference.
Please let me know if you need any further information.
Thanks.

BR

EDIT: The problem appeared around 19:00 CEST 15. 9.

[Thejollyone]

I too have been having a really unstable connection lately - chat server keeps resetting, hammerman, non reloads between adventure island servers forcing refreshes...

However, I have found it more reliable/constant with a wired connection over wifi but do still encounter the issues

EDIT - pls BB, do not respond with clear cache DNS etc suggestion, as that is the 1st thing I always do when i have issues with the game

[Fexno]

Hello Posolsvetla,

Unfortunately you traced the url used for the homepage, however internally the game uses a different url to communicate. This url differs per gameworld.

It might be worthwhile to clear your cache (http://forum.thesettlersonline.com/threads/25422) and flush your dns (http://forum.thesettlersonline.com/threads/27696-Connection-Failed?p=253583&viewfull=1#post253583) to see if that helps you.

@jollyfog2012 don't forget that other players might not know that some issues can be solved by clearing cache and/or flushing dns. Instead of assuming everyone knows about this I rather repeat it.

[Thejollyone]

Hello Posolsvetla,

@jollyfog2012 don't forget that other players might not know that some issues can be solved by clearing cache and/or flushing dns. Instead of assuming everyone knows about this I rather repeat it.


Fair comment, but I rather meant that for the benefit of this particular issue in my case, it has not worked - therefore there is something else affecting the connection. Whether this is a BB server error or a home one, I wanted to let people know that on this occasion the cache and DNS did not resolve it.

[Durin_d]

This is just my speculation and reasoning why the connection is/can be unstable.

By following the traffic that the game generates with Chrome Developer tools I've noticed that the game traffic and chat traffic uses unencrypted http with keep-alive connection. That means that the same TCP connection will be kept open for a long time and used for multiple packet transfers.

Keeping the TCP connection open for a long time can lead to problems with firewalls and network configurations. Some networks will drop the connections after they've been up for some predefined time (for example 1h), but usually the drop happens only on idle connections and the max time I've noticed in the traffic is 20s in chat connection. Of course as the traffic goes through multiple networks they all have different configuration even for different times of day.

Then the unencrypted http traffic. This is not about the security but how some networks might handle this unencrypted http traffic and more precisely proxys. Proxys capture plain http traffic and try to respond to those request from their memory and thus lowering the uplink data transfer. Of course they can't respond to TSO traffic as every response is generated in the server but they add latency to the traffic. Why this wouldn't happen with encrypted https is because the traffic is unreadable between the server and client and thus the proxy can't respond to the requests. Encryption would increase the server load when all the packages would have to be encrypted thus presenting new problems.

[Posolsvetla]

Things are back to normal atm. without any action from my side.

Thanks all for the replies.

The game world I play differs only at the last point in packet path, while packet lost was detected even earlier in the path. So it makes no difference.
As for the TCP connection stuff described by Durin_d, it's not the case, as the problem persisted even after Firefox restart.
I didn't try clearing DNS cache, will do so the next time the problem occurs (although I'm sceptical it will solve the problem).
Unfortunatelly, I cannot test the connection on a secondary machine or using different ISP in order to better localize the source of the issue.