2002 completely a problem with the game itself?

I will admit I know nothing about coding and the back end of the internet, but my layperson's understanding of this is that the errors booting people from within queues midway through are completely due to a problem with the game client. I know this has been posted before, but to my knowledge this analysis has never had a thread dedicated to it. I would appreciate if people with greater understanding than myself chimed in here.

https://docs.google.com/document/d/1..._OdCBfejk/edit

They can't buy more servers, but they can fix this. Or can they? You tell me.

I wish they would acknowledge this, but I'm sure they'll just keep on continuing to blame us.

Your link returns "Sorry, the file you have requested does not exist."

It depends how the value of 15 minutes is stored. If it is a constant somewhere in the sourcecode then it should be easy "fixable" by increasing the value to a much higher value without many changes in the client. And i also doubt that it would break something. But this would not be a real fix but more a mitigation.

A real fix should remove the disconnects every 15 minutes completely and then there should be a reconnect mechanism with more than one try.

Quote:

---

Originally Posted by Brennus

Your link returns "Sorry, the file you have requested does not exist."

---

Here is the link:
https://docs.google.com/document/d/1..._OdCBfejk/edit

Cheers

I gotta admit their insistence on blaming people's internet is pretty insulting.

It seems to be issue on the server end of stuffs.

From my understanding by working on similar types of servers (emulators), their login and queue servers are paired together. Think WoW realm server.

Login server receives too many requests and becomes overloaded, queue server is already at peek capacity and will not process requests to enter the queue, thus your connection to both are dropped resulting in 2002.

Queue servers should never become overloaded in first place as this defeats the purpose of a queuing server. It is occurring because the world cannot permit your entry yet the queue server attempts to parse that request despite this. It probably is doing so because both world server and queue server are overloaded. Queue server goes umm, hey I have this person ready to enter the world! The world server says, hey wait I am full! The queue server is overloaded and does receive that message from world server so just well.. drops your connection as there is no more room in the queue for you anymore.

They did attempt resolving of this by expanding the number of slots the login server can accommodate but that is a solution most amateurish. Take this lala's words with many many grains of salt. I have not worked in this field for much time. This is umm also serious dumbing down of actual technical side of things. Attempting explaining in English is not fun either..

Edit; Hmmm! I have perused that most informative google doc, many thanks to whomever wrote that!

The only reason to have a client willingly terminate connections after prolonged periods of time that this Mia can think of would be that the server cannot communicate to the client that it may be overloaded. Fifteen minutes is quite lengthy for past queue times pre expansion and reasonable amount of time to assume something has gone wrong and retry connection. It is likely the client assuming the connection has "stalled" when it indeed has not. It is also amateurish..

I am not being mean in saying these things, I only speak the truth and even that doc explains that this is silly. There are simply things you do not do in this industry and have been known about for decades.

Edit 2; Actually there are many other reasons why one may wish to auto terminate a connection like this and interrupt the next payload of packets. None of the reasons that enter my mind are good coding.. it actually makes the brain hurt thinking about. I cannot believe I worked on this nonsense so many years ago nor how many commits I made to help resolve issues like this only to.. you know what I have said my bit.

Quote:

---

Originally Posted by Larirawiel

It depends how the value of 15 minutes is stored. If it is a constant somewhere in the sourcecode then it should be easy "fixable" by increasing the value to a much higher value without many changes in the client. And i also doubt that it would break something. But this would not be a real fix but more a mitigation.

A real fix should remove the disconnects every 15 minutes completely and then there should be a reconnect mechanism with more than one try.



Here is the link:
https://docs.google.com/document/d/1..._OdCBfejk/edit

Cheers

---

Ah thank you. Very interesting and illuminating Wireshark analysis. The evidence seems pretty overwhelming, that our client software is at fault, not the login server at SE's end. Ergo this could easily be patched, presumably lessening the end-user frustrations from 2002 errors and losing our spots in the queue.

I'd like to see SE respond to this explanation, and offer us their own, hopefully transparent and easily understood, reason for the current login situation.

Quote:

---

Originally Posted by Brennus

Ah thank you. Very interesting and illuminating Wireshark analysis. The evidence seems pretty overwhelming, that our client software is at fault, not the login server at SE's end. Ergo this could easily be patched, presumably lessening the end-user frustrations from 2002 errors and losing our spots in the queue.

---

The problem unfortunately exists on both ends.

Login server capacity is limited to a finite number of connections. When your connection attempts to reestablish client-side as noted in the doc, it creates a race condition wherein it's highly likely that someone else has already taken the slot you just created while reconnecting, which results in you then being unable to connect to the login server which is now at capacity. Every 15 minutes you essentially have to pray that there is a 'slot' available in the login server as well.

Quote:

---

Originally Posted by LittleImp

The problem unfortunately exists on both ends.

Login server capacity is limited to a finite number of connections. When your connection attempts to reestablish client-side as noted in the doc, it creates a race condition wherein it's highly likely that someone else has already taken the slot you just created while reconnecting, which results in you then being unable to connect to the login server which is now at capacity. Every 15 minutes you essentially have to pray that there is a 'slot' available in the login server as well.

---

But why is this necessary? If you're already in the login server, why are you being made to disconnect and reconnect again? From my perspective, that makes absolutely zero sense.

Quote:

---

Originally Posted by PredatoryCatgirl

But why is this necessary? If you're already in the login server, why are you being made to disconnect and reconnect again? From my perspective, that makes absolutely zero sense.

---

It is completely unnecessary for a properly implemented queuing system you are correct indeed.

Thinking more about it (and I wish I was not) it may be;
A.) Legacy code designed to accommodate issue that no longer exists.
B.) Code designed to accommodate currently existing issue with how the server and client resolve handshake requests.
C.) Something I am not considering from being out of practice or not coding in such ways as it is stoopid.

Actually it is worse then unnecessary. I made post in other threads about this.. Each time a client is booted with 2002 it must re-do the entire process of logging in and re-entering the queue which as may guess pings not only login server, but character database and queue server. Knowing it does this every 15 minutes boggles the mind.