Concrete proof finally provided that the 2002 error has NOTHING is server side issue

[Vukimukinukiduki]

I think devs just can't fix this, my profession lies far from programming, but I have feeling that part of code responsible for dropping connection and other things with 2002 error is patched so many times that they can't do something about it, if they would do than they gonna broke another thing.

[Larirawiel]

I think devs just can't fix this, my profession lies far from programming, but I have feeling that part of code responsible for dropping connection and other things with 2002 error is patched so many times that they can't do something about it, if they would do than they gonna broke another thing.

We don't know how it is implemented. If it is simple constant like:

int32_t minutes = {15};

Then it is very easy to fix and i doubt that this will break other things. You could mitigate it with:

int32_t minutes = {1500000};


Cheers

[Komarimono]

Oh hey, I just tested something myself. I interrupted my connection to simulate a packet loss, for 0.10 ms. Queue was at 46. Guess what? I got an Error 2002.

So, guess they weren't lying, huh? Guess packet loss does lead to 2002 when waiting on queue.

[Shougun]

Oh hey, I just tested something myself. I interrupted my connection to simulate a packet loss, for 0.10 ms. Queue was at 46. Guess what? I got an Error 2002.

So, guess they weren't lying, huh? Guess packet loss does lead to 2002 when waiting on queue.

That's really sensitive though. There are so, so, many things that do adjust for that scenario. Why can't the login queue? .10ms loss, BACK OF THE LINE! lol.

Imo that is still their issue, if such a tiny loss causes everything to be thrown into disarray, though I assume there are other more complicated issues behind that smaller more simple issue.

It may still be a user causing some of this problem but honestly the program /should/ be more robust than that. Packet loss is pretty common in a variety of situations (not saying it's good, but this is just a reality for many situations). For example the game itself is, you can R0 and it'll be able to recover it doesn't just go "MINOR DISRUPTION, GET OUT OF HERE". Some games can even hold you in the game for a second incase your connection returns, not kicking you out during that period (I like New World can do this, though that game shouldn't be used as a shining example of code probably..... lol).

[Catwho]

I think devs just can't fix this, my profession lies far from programming, but I have feeling that part of code responsible for dropping connection and other things with 2002 error is patched so many times that they can't do something about it, if they would do than they gonna broke another thing.

There's two scenarios:

1. This part of the net code came from a borrowed library originally from another company, and they are at the mercy of that other company identifying and fixing the problem. In this case, a fix may never be forthcoming, especially if that company no longer exists. My office has a persistant bug from our framework company ZK that is like this, and while it only becomes apparent under extremely complex web pages (ours is a hospital schedule...), it's a bug our users are seeing daily. However, as far as the company is concerned, it's a low priority bug because only a handful of their clients are reporting it.

2. This part of net code is so archaic but also so fundamentally woven into the server and library system that adjusting it would entail a full rewrite of the entire login and lobby system to change. This doesn't mean that they can't eventually find a solution to fix it, but it does mean that the fix isn't going to be a one-liner in the lobby server queue code. Sometimes a company needs to bite the bullet and do these full rewrites; my office had to rewrite our entire client facing portal because of a fatal design flaw ten years ago that didn't link clients across different business units, which sucked away four months of development time from the new features we really wanted to add. Such a code rewrite would likely result in the delay of 6.1 since it's not the kind of thing they can outsource, and even if they hire a consultant firm to assist, they'd still have to actually write the code themselves for security and knowledge reasons.

I suspect it's the latter. They're stuck in a rock and a hard place.

[Larirawiel]

There are more propabilities:

There are not aware of this behavior because that person who implemented it is no longer in the company and this behavior is not documented.

They know this but maybe this behavior mitigates another bug. Even if it is hard imaginable.

It was a quick & dirty hack and now they have not the ressources to fix this.


Cheers

[Packetdancer]

They know this but maybe this behavior mitigates another bug. Even if it is hard imaginable.

It's very easy for connections passing through NAT to end up silently dropping; the client side doesn't see that the connection is dead until it tries to send something, but the server side sees that the client has disconnected. It's due to how a number of home routers/modems will handle NAT.

If they saw an issue back in ARR with the connections from behind a NAT setup dropping, I can easily see adding a safety measure where it refreshes the connection every so often to make sure the connection doesn't silently go 'poof'. I'm not sure it's the approach I'd personally have used in a scenario like that, though FFXIV's network code may have made it the most appropriate one for whatever reason, but it's an approach to things like that... and one I've seen used by other software elsewhere. So if the game is doing that, it absolutely could be an attempt to fix that issue.

After all, the 2002 errors are frustrating, but it'd be even worse if your connection got dropped silently and you sat there thinking you were still in queue, only to get unexpectedly disconnected the next time the game tried to refresh the connection. Holding your spot in queue and manually disconnecting you to make the connection get refreshed strikes me as the equivalent of going after a particularly persistent mosquito with a howitzer, but it will (generally) get rid of the mosquito.

And even if that isn't the reasoning, it could still be addressing something else. it could be that it's a load-balancing scenario, where when it bounces you it has the potential to ask you to reconnect to a different login server instead, and that provides a method to shuffle people around to keep any one login server in a pool from being too overloaded, or whatever.

But if that's the situation, I'd argue that still falls into 'archaic netcode' as listed by Catwho, or a closely-adjacent area. And is probably something where reworking the entire login system (and making sure the change it doesn't re-introduce whatever original quirk prompted the scenario) would likely be a not-small undertaking.

[IdowhatIwant]

Someone on reddit was nice enough to do a full technical analysis of the cause of the 2002 error and JUST LIKE everyone has been saying.

The server is resetting you client every 15 minutes and if it desyncs during this client reset it crashes the client.

This has nothing to do with your internet but an internal server side check done once that causes you client to crash.

Fix this now and stop blaming your consumers for internal coding issues.

https://docs.google.com/document/u/0...jk/mobilebasic

Source: reddit user u/pitiful-marzipan

If you know anything about how the internet works you would have already known this was a server side issue. It is common sense to most if you know anything about computers. Sure there are people that do get 2002 because of internet issues. But a majority of it is related to loss of packets from the server to you when it gets over loaded. Nice research project but a waste of time.

[Kes13a]

so... I have a concern about this experiment...

the IP address that is in this "proof" is 204.2.229.9
this IP is not based out of California, which is where the NA data center is located. (I doubt somehow that the login server for -anywhere- is going to be located in Kansas...)

that tends to raise a few concerns about the validity and the methodology of this "proof"

updated

not going to delete since I hate when people do that, but this was incorrect and my whois was incorrect. my sincere apologies

[MiaShino]

so... I have a concern about this experiment...

the IP address that is in this "proof" is 204.2.229.9
this IP is not based out of California, which is where the NA data center is located. (I doubt somehow that the login server for -anywhere- is going to be located in Kansas...)

that tends to raise a few concerns about the validity and the methodology of this "proof"

How are you getting Kansas?

We don't know how it is implemented. If it is simple constant like:

int32_t minutes = {15};

Then it is very easy to fix and i doubt that this will break other things. You could mitigate it with:

int32_t minutes = {1500000};


Cheers

I like the valve employee approach!
//int32_t minutes = {15};
//Why did we code this? This is terrible, never do this.