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

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.

Quote:

---

Originally Posted by 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.

---

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.

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

Quote:

---

Originally Posted by RyuDragnier

Hasn't been happening on PS4, or at least to me. I got one crash after waiting an hour, immediately logged back in, and was back in my place in queue for another 30 minutes before I actually got in earlier today.

---

2002 along with other errors happen to me all the time. I just don't even try in the afternoon. It isn't possible for me to play. I'm PS4.

Quote:

---

Originally Posted by Puremallace

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.

Quote:

---

Originally Posted by 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.

---

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

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

Quote:

---

Originally Posted by 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"

---

How are you getting Kansas?
https://i.ibb.co/MC8M640/huh.png

Quote:

---

Originally Posted by Larirawiel

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.

Quote:

---

Originally Posted by 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"

---

it is in fact, the server IP of aether
https://arrstatus.com
https://www.reddit.com/r/ffxiv/comme...tal_server_ip/

Jepp, the DNS name of 204.2.229.9 is neolobby02.ffxiv.com

Cheers