Issues, Workarounds & Localization

Is there perhaps a moderator or dev/gm that saw this issue rolling by and did a quick look at it if theres anything worth sharing that can be found in any logs for us to present to our ISP?

Have Ziggo, but no problem here.

Server reboot didn't solve anything.

ziggo too but as you can see per this post i have normal internet, yet after login i select my char, it goes to the station/whatever you call it, and before it gets there socket closed...

edit:

here is a new one...


Unable to connect to the selected server. Please check the address and try again.
wich i did (like 10 times) and then got:

The transport has not yet been connected, or authentication was not successful.<===i was on char selection screen, so im assuming authentication was k

Is this problem from Ziggo only ?
my socket issues started yesterday and still going.
re-installed game , rebooted modem,router no results.

seems there only ziggo users with this problem?

At this moment things seemed to have cleared up. I can login again with fast loads etc. No socket closed.

Now fingers crossed.

Somebody must have flipped a switch somewhere, I thank that person!

Also having socket closed problems. Have had them in the past as well, always after a patch and not ISP related.

head to http://winmtr.net/ and use it to trace your network path. It should help you identify whether the problem is local or with your ISP, and can create logs that you can send your ISP as part of a complaint.

To my knowledge, there have been no changes in our network infrastructure or connectivity whatsoever, so whatever caused BRooDJeRo to be able to properly connect again has been well beyond our circle of influence.

As for the "The Socket was closed" error message I would like to share a few words, though, as there appear to be quite some misconceptions about it....

The thing with that message is that it is as generic as "Apples are fruit" and it actually means nothing other than that the connection was lost (as in: "No data could be submitted successfully for some reason", not "the server kicked you"). It is in itself not very helpful and in almost all cases is the result of the TCP protocol having to resend the same package too many times (this error happens on the network protocol layer, not in the client or server). This can happen for each connection your computer makes independently and as such it is entirely possible that only one client gets this while another one is somehow still working at the same time as it gets at least some packages through (or did not have to send anything yet).

The exact reasons for those errors can range from squeezed network cables or interference on a wireless connection to other problems somewhere along the route that neither your ISPs nor us have any direct influence on. In rare cases, this may also be the result of bandwidth starvation (i.e. when BitTorrent clients with unlimited Bandwidth usage are gobbling up your upload bandwidth completely and the client doesn't get to send the few bytes it needs to) or even traffic shaping that randomly disrupts transmissions on port 26000 (in an attempt to thwart Peer to Peer downloads, as a lot of those applications use this as default port as well).

There are a few ways that can eventually alleviate those connectivity problems, albeit all of them are very dependent on the actual issue causing it:
* disconnect your router and modem from their power supplies for a few minutes to reset them and rule out problems there as much as possible, also check your network cables for any damage.
* If you have access to a VPN service that lets you connect via other parts of the world, try to connect to TQ via a different route through that. Oftentimes those services will use their own infrastructure and potentially use different peering partners than your ISP for their connections, and as such this can often circumvent routing issues.
* If traffic shaping on port 26000 is the case (oftentimes recognizable by the issue only popping up during a specific time of day), it is (still) possible to make the client connect to TQ through port 3724 rather than 26000. This can be changed within the "prefs.ini" that can be found in the settings folder of the client (change the line "port=26000" to "port=3724")
* see the following article on the EVElopedia that provides you with some guidance for a (very) basic diagnosis of your connection to TQ:
http://wiki.eveonline.com/en/wiki/Network_Guide

Last but not least I can only assure you that all of TQs connectivity hardware is heavily monitored for its performance and reliablity and that we have measures in place that will attempt to make sure that the server sends data to your client through the best available routes (there were also some dev blogs on this matter quite some time ago), as well as metrics that will inform us very early if anything in TQs connectivity that we can have an influence on is amiss. We are also constantly looking into new peering options with various providers in order to keep the routes to our servers as short as possible for everyone.

Thx for your answer and clarification GM Karidor. Things look still 100% and the Ziggo-socket problem seems resolved for more of these people. Personaly I think it was 'something' in the Ziggo systems regarding maintenance and upgrades performed earlier.

Ziggo seems to be in a transitional fase of a free WIFI network with almost full country coverage. For this they want to use the Ziggo customers routers.
The feature is already in the routermenu, but isn't functional yet and doesn't have any options. This would also need upgrades and stuff at the datacenters.

Only insiders know what they had to bypass during this upgrade round and contracts tell them to be discrete. When the helpdesklady isn't told anything in detail she can rely on plausible deny-ability.