2002 completely a problem with the game itself?

[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.

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

[Brennus]

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.

[LittleImp]

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.

[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.

[Brennus]

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.

Aye, you're technically correct. But the root cause of the problem is the client voluntarily dropping the connection every 15 minutes. Eliminate that, and you don't need to attempt a new login, the server doesn't have to choose between you and a zillion other competing requests, you stay connected, waiting patiently in the queue, and will eventually get recompensed with being shown to the game, on your world server.