2002 completely a problem with the game itself?

[PredatoryCatgirl]

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.

[MiaShino]

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.

[LittleImp]

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 isn't necessary. It's lazy programming.

[Larirawiel]

It isn't necessary. It's lazy programming.

For me it looks like a quick & dirty hack to mitigate something that was a possible problem 8 years ago. And they never fixed it because it never hit them hard enough. Now with the very long queues this "fix" is very contra productive. And it is a good example why every software company should work on technical debt.

Cheers

[Saefinn]

I think it raises a fair issue and I hope they're aware of this issue if it is as the link in the OP suggests. It seems to have only presented itself now that the server load is unreasonably high. If it has to re-establish a connection with the server every so often then it makes sense if it hits its cap then it disconnects from the server. I'd suspect this is in place to prevent any server connections from hanging, but I am not knowledgeable enough to suggest a better alternative to that problem or why it may work that way. Or how big the solution to this is or what problems might be caused by a fix. It'd also perhaps explain why when I get a 2002 and reconnect and it retains my position in the queue because it retains that position on refresh but the server may refuse the connection if load is too high.

The fact they've managed to increase the cap to 23,000 per data center by using their backup development servers I think should alleviate the problem, because it's less likely to hit that cap when it has to drop and reconnect.