Socket Closure

Hey all. I am not very clued up on computer tech stuff but am wondering what causes the socket closures in eve. I counted around 12 socket closures with in a 4 hr play session of eve.

Thanks

Bubba

2 Likes

I too have been constantly suffering from this issue.

This tracert https://pastebin.com/3PNWbXM0 is typical when I run it. The conn seems to be timing out consistently. I am West Coast NA (Vancouver, BC) for the record.

The loglite tool only ever shows a forced socket closure. I came back to the game after a few years off a couple of weeks ago and it has been a constant sore spot since then.

Yea, I came back after a bit of a break too, regular socket closures. Sometimes in the middle of doing things, other times when itā€™s just sitting idle. yet other times I can forget to log out and its okay for hours.

Seems like the server is being a bit too strict on some packets, completely ignoring that the client is still replying to other packets.

Socket Closed is a generic error summarizing the fact that between point A and point B, your connection to eve futzed out. Sometimes, if youā€™re lucky, the game maintains a connection, or regains the connection, and you stay connected. That generally only happens if absolutely nothing is happening for you ingame- no chat, no mails, no UI changes, no combat/space stuff.

The client will only drop the connection if it fails to send or receive five consecutive packets.

I have just had socket close 3 times in a 30 min game session. the eve repair tool doesnā€™t solve it

I have had problems with Socket Closed before the most resent patch, however after the patch and the introduction to the standalone chat servers I have experienced increased frequency of DCs.
I now drop out of chats after about 6 minutes if I donā€™t actively type things every other minute. This means that I miss fleet informations such as warpins etc and have to reconnect to the chat server and ask for reposts - all the time! Iā€™m in the help channel in order to maybe mitigate this problem but with no real benefit.

I now also DC when on grid with others, which did not happen before, I could sometimes DC in wormholes when I was alone in the hole, wormholer btw, which ā€œmakes senseā€ since server traffic might be lower causing the DC. Example: I was DCd while cloaked on grid with a tasty Rorqual causing me to decloak and thus alert him to my presence. This makes me unusable in any intel situation. I use an alt account sitting in Jita (never DCs btw) to alert me when my main DCs, so when I hear the ā€˜friend logged ofā€™ sound I know that I DCd.

I have now contacted my ISP since this is clearly not a CCP issue , sorry for salt but at this point the game is unplayable. If I keep disconnecting 20+ times a day I will probably not play the game for much longerā€¦

You are not the only one experiencing this. The same has happened to me before the patch. Now the patch is live and after the fixes, I cant even log in. I have given up. Its not my ISP or my hardware/software. It is a CCP issue. All my other MMOā€™s are fine.

I myself wont be playing anymore due to this issue.

Well, Iā€™m getting it too now. Tried to log in 4 times today, each time was a failure. Can we roll back to the Feb release?

wish they do that but all that hard ā– ā– ā– ā– ā– ā– ā–  up the server would went to waste and now they have fix it this remember the old days of eve where you couldnā€™t play game for 4-5 days because of the patches ccp brought now it it back those days it seem but ccp not listen they havnt replied to a lot of forums posts

Having the exact same isue, getting socket closures daily. I can go a day with them spread out or you can get hit with a bunch in the space of an or two. It is very frustrating.

This has been a long standing issue with eve and deals entirely with how they handle packet loss.

If you want to see something fun that Iā€™ve been dealing with on a regular basis for over a year at this point launch a half dozen clients or more and wait. You wonā€™t always get socket closures, but when you do (and you will) the closures will occur across random clients with no bearing of when they were open or how active they are. Again, due to the strict handling of packet loss. Itā€™s always just interesting to me that I can play and Iā€™ll have 3 clients die on me while the others wonā€™t have a problem all day. Or Iā€™ll have 2 die, then 3 minutes later another dies, then 2 hours later theyā€™ll all die, and so on completely at random. Feels like the servers are playing a very slow game of wack-a-mole with my clients :smiley:

@GM_Mechanic yes, the same issue Iā€™ve ticketed a half dozen times. At least now I have images showing me where the loss is occurring (1 hop out from your servers). It seems thereā€™s packet loss there pretty often, and it doesnā€™t always knock out clients. However, when I detect an extended period of packet loss in that area is typically when all clients get knocked out. And yes, I can open yet another ticket if you want to see them - which I imagine you guys do.

1 Like

This has been happening to me every 5 minutes since the patch 2 days agoā€¦

Well its been a week and I still cant log in for more than a minute or 2 before Iā€™m kicked out. Frustrating

If you are on WiFi you might be getting Socket Closures due to atmospheric conditions causing the signal to degrade.

Trying resetting your WiFi to get a better signal.

So after some more digging around (ie tracert) it seems that my loss is coming from cloudfront, which is owned by Amazon. Hereā€™s the tracert results:

Starting traceroute diagnostics - this may take several minutes

Starting tracert for launcher.eveonline.com

Tracing route to d1hoqe10mv32pv.cloudfront.net [13.32.179.93]
over a maximum of 30 hops:

  1    14 ms     3 ms     1 ms  modem.example.org [192.168.0.1] 
  2    34 ms    30 ms    74 ms  blng-dsl-gw16.blng.qwest.net [67.42.227.16] 
  3    42 ms    30 ms    30 ms  blng-agw1.inet.qwest.net [65.100.79.121] 
  4    49 ms    50 ms    48 ms  tuk-edge-13.inet.qwest.net [67.14.4.210] 
  5    74 ms    49 ms    49 ms  65-122-235-170.dia.static.qwest.net [65.122.235.170] 
  6    51 ms    50 ms    51 ms  52.95.54.48 
  7    50 ms    50 ms    48 ms  52.95.54.61 
  8    54 ms    51 ms    50 ms  52.95.55.249 
  9     *        *        *     Request timed out.
 10     *        *        *     Request timed out.
 11     *        *        *     Request timed out.
 12    50 ms    49 ms    50 ms  server-13-32-179-93.sea19.r.cloudfront.net [13.32.179.93] 

Trace complete.

Starting tracert for binaries.eveonline.com

Tracing route to d17ueqc3zm9j8o.cloudfront.net [13.32.179.143]
over a maximum of 30 hops:

  1     4 ms     2 ms     1 ms  modem.example.org [192.168.0.1] 
  2    31 ms    32 ms    31 ms  blng-dsl-gw16.blng.qwest.net [67.42.227.16] 
  3    31 ms    32 ms    96 ms  blng-agw1.inet.qwest.net [65.100.79.121] 
  4    49 ms    52 ms    48 ms  tuk-edge-13.inet.qwest.net [67.14.4.210] 
  5    68 ms    65 ms    74 ms  65-122-235-170.dia.static.qwest.net [65.122.235.170] 
  6    54 ms    56 ms    50 ms  52.95.54.116 
  7    50 ms    50 ms    50 ms  52.95.55.135 
  8    50 ms    50 ms    51 ms  52.95.55.253 
  9     *        *        *     Request timed out.
 10     *        *        *     Request timed out.
 11     *        *        *     Request timed out.
 12    50 ms    51 ms    52 ms  server-13-32-179-143.sea19.r.cloudfront.net [13.32.179.143] 

Trace complete.

Starting tracert for resources.eveonline.com

Tracing route to dm794883twbxj.cloudfront.net [13.32.179.222]
over a maximum of 30 hops:

  1     3 ms     2 ms     1 ms  modem.example.org [192.168.0.1] 
  2    68 ms    34 ms    32 ms  blng-dsl-gw16.blng.qwest.net [67.42.227.16] 
  3    59 ms    34 ms    30 ms  blng-agw1.inet.qwest.net [65.100.79.121] 
  4    77 ms    48 ms    49 ms  tuk-edge-13.inet.qwest.net [67.14.4.210] 
  5    49 ms    53 ms    49 ms  65-122-235-174.dia.static.qwest.net [65.122.235.174] 
  6    59 ms    55 ms    58 ms  52.95.54.214 
  7    49 ms    48 ms    51 ms  52.95.54.227 
  8    72 ms    63 ms    49 ms  52.95.55.245 
  9     *        *        *     Request timed out.
 10     *        *        *     Request timed out.
 11     *        *        *     Request timed out.
 12    51 ms    49 ms    50 ms  server-13-32-179-222.sea19.r.cloudfront.net [13.32.179.222] 

Trace complete.

Traceroute diagnostics finished

So I followed up with a look at the internet health: https://www.akamai.com/us/en/solutions/intelligent-platform/visualizing-akamai/real-time-web-monitor.jsp

Well, I guess thatā€™s it then. Time to let my subsrciption lapse until Amazon (cloudfront) stabilizes their end.

I am having a similar results in my traceroute as well.

`Starting traceroute diagnostics - this may take several minutes

Starting tracert for launcher.eveonline.com

Tracing route to d1hoqe10mv32pv.cloudfront.net [52.84.35.195]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms xxxxxxxxxx
2 23 ms 63 ms 15 ms 69.63.254.70
3 11 ms 11 ms 11 ms 104-195-128-142.cpe.teksavvy.com [104.195.128.142]
4 10 ms 9 ms 9 ms 104-195-129-29.cpe.teksavvy.com [104.195.129.29]
5 10 ms 17 ms 10 ms ae1-0-bdr01-tor.teksavvy.com [206.248.155.13]
6 16 ms 17 ms 174 ms xe-0-0-0-2210-bdr01-mtl.teksavvy.com [192.171.63.162]
7 24 ms 31 ms 24 ms ae2-10-bdr01-nyc.teksavvy.com [206.248.140.218]
8 58 ms 24 ms 25 ms de-cix.nyc.amazon.com [206.130.10.99]
9 * * * Request timed out.
10 * * * Request timed out.
11 * * * Request timed out.
12 * * * Request timed out.
13 * * * Request timed out.
14 32 ms 30 ms 25 ms server-52-84-35-195.ewr50.r.cloudfront.net [52.84.35.195]

Trace complete.

Starting tracert for binaries.eveonline.com

Tracing route to d17ueqc3zm9j8o.cloudfront.net [52.84.35.155]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms xxxxxxxxxxx
2 21 ms 11 ms 11 ms 69.63.254.70
3 10 ms 19 ms 280 ms 104-195-128-142.cpe.teksavvy.com [104.195.128.142]
4 8 ms 11 ms 10 ms 104-195-128-141.cpe.teksavvy.com [104.195.128.141]
5 148 ms 16 ms 15 ms ae4-0-bdr01-tor.teksavvy.com [206.248.155.94]
6 17 ms 20 ms 16 ms xe-0-0-0-2210-bdr01-mtl.teksavvy.com [192.171.63.162]
7 24 ms 24 ms 25 ms ae2-10-bdr01-nyc.teksavvy.com [206.248.140.218]
8 23 ms 23 ms 27 ms de-cix.nyc.amazon.com [206.130.10.99]
9 * * * Request timed out.
10 * * * Request timed out.
11 * * * Request timed out.
12 * * * Request timed out.
13 * * * Request timed out.
14 25 ms 23 ms 29 ms server-52-84-35-155.ewr50.r.cloudfront.net [52.84.35.155]

Trace complete.

Starting tracert for resources.eveonline.com

Tracing route to dm794883twbxj.cloudfront.net [52.84.35.19]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms xxxxxxxxxxx
2 44 ms 38 ms 43 ms 69.63.254.70
3 10 ms 15 ms 11 ms 104-195-128-142.cpe.teksavvy.com [104.195.128.142]
4 29 ms 24 ms 11 ms 104-195-129-29.cpe.teksavvy.com [104.195.129.29]
5 11 ms 11 ms 11 ms ae1-0-bdr01-tor.teksavvy.com [206.248.155.13]
6 17 ms 16 ms 17 ms xe-0-0-0-2210-bdr01-mtl.teksavvy.com [192.171.63.162]
7 24 ms 23 ms 23 ms ae2-10-bdr01-nyc.teksavvy.com [206.248.140.218]
8 24 ms 25 ms 26 ms de-cix.nyc.amazon.com [206.130.10.99]
9 * * * Request timed out.
10 * * * Request timed out.
11 * * * Request timed out.
12 * * * Request timed out.
13 * * * Request timed out.
14 27 ms 28 ms 28 ms server-52-84-35-19.ewr50.r.cloudfront.net [52.84.35.19]

Trace complete.`

Here I am a week later and its the same thing. Come on Amazon, renforce the dam node!

So after reading this link about the russkies losing their service due to the govā€™t blocking amazon IPs, It seems that CCP is using Amazon for hosting. I could be wrong here, but if thats the case, why dont they put some pressure on Amazon to stop dropping their clients?

I am convinced the disconnects are not all random and are often tied to game events. For example I can play for hours with no issues but when running a Haven with two accounts I can almost guarantee a disconnect on one or both characters running the Haven while a third character who is docked up stays on line. Unless Amazon is actively monitoring my game and throwing in a spanner each time I reach the end of a Haven this suggests a problem in Eve itselfā€¦

1 Like