4 ms·

One thing they’re not mentioning is the queues being unstable - being kicked out of the queue by their 2002 errors. I’d love to see them address this beyond “it

One thing they’re not mentioning is the queues being unstable - being kicked out of the queue by their 2002 errors. I’d love to see them address this beyond “it’s likely a client networking issue”. Once you’re in the game it’s rock solid, which leads me to question the “client networking issue” explanation. The large and unstable queues are leading to the use of mouse jigglers and such, so people can log in in the morning just so they can play at night. An interesting, but not helpful, emergent behavior.

jdknezek 5y ago
I haven't verified myself, but [1] & comments assert that the client attempts to open a new lobby server connection periodically based on time or byte count, which causes your client to bump into the lobby server limit even mid-queue. [1] https://www.reddit.com/r/ffxiv/comments/r9r25a/error_2002_issue_not_related_to_your_internet/ https://www.reddit.com/r/ffxiv/comments/r9r25a/error_2002_is...
virtue3 5y ago
My pro-tip here is to use the XIVLauncher (get it from github). Logs you in much faster than the default launcher. They brought in dev machines to address this. The issue is the queue is for your data center. And it maxes out at 15k. I think they're going to be operating at 17,500 now? There's most likely some really long open socket connection with no retry logic. So anytime you get a hint of packetloss it's over. Polling would be better but would also require a lot more hardware? I'm not sure how I'd design a better system. As soon as the queue hits 15k people get booted and you end up with about 2-3 minutes to get back in and keep your spot.
derefr 5y ago
> Once you’re in the game it’s rock solid, which leads me to question the “client networking issue” explanation. Could be different architectures between the "queue" and the in-game session. Presumably with the in-game backends, the client gets told to connect to a specific backend (or through an LB with a sticky session), which keeps some of your active player state in-memory; and because of that, they'd want those backends to be robust to disconnection, allowing the client to reconnect and resume the existing backend session on the same server. The queue, on the other hand, is the first-in-line protection for the game — equivalent to Cloudflare for an HTTP site. It has to deal with bots, DDoS attacks, etc. I would guess that they "solved" this by requiring a kind of proof-of-work — that "work" in this case being "keeping a socket open and responding to pings for the whole time you're in the queue." If this were true, "client networking issues" would technically be the proximate cause of a client falling out of the queue and having to get back in line at the end. It'd be a problem the devs created for themselves, but it would indeed be the problem.

jdknezek 5y ago

I haven't verified myself, but [1] & comments assert that the client attempts to open a new lobby server connection periodically based on time or byte count, which causes your client to bump into the lobby server limit even mid-queue. [1] https://www.reddit.com/r/ffxiv/comments/r9r25a/error_2002_issue_not_related_to_your_internet/ https://www.reddit.com/r/ffxiv/comments/r9r25a/error_2002_is...

virtue3 5y ago

My pro-tip here is to use the XIVLauncher (get it from github). Logs you in much faster than the default launcher. They brought in dev machines to address this. The issue is the queue is for your data center. And it maxes out at 15k. I think they're going to be operating at 17,500 now? There's most likely some really long open socket connection with no retry logic. So anytime you get a hint of packetloss it's over. Polling would be better but would also require a lot more hardware? I'm not sure how I'd design a better system. As soon as the queue hits 15k people get booted and you end up with about 2-3 minutes to get back in and keep your spot.

derefr 5y ago

> Once you’re in the game it’s rock solid, which leads me to question the “client networking issue” explanation. Could be different architectures between the "queue" and the in-game session. Presumably with the in-game backends, the client gets told to connect to a specific backend (or through an LB with a sticky session), which keeps some of your active player state in-memory; and because of that, they'd want those backends to be robust to disconnection, allowing the client to reconnect and resume the existing backend session on the same server. The queue, on the other hand, is the first-in-line protection for the game — equivalent to Cloudflare for an HTTP site. It has to deal with bots, DDoS attacks, etc. I would guess that they "solved" this by requiring a kind of proof-of-work — that "work" in this case being "keeping a socket open and responding to pings for the whole time you're in the queue." If this were true, "client networking issues" would technically be the proximate cause of a client falling out of the queue and having to get back in line at the end. It'd be a problem the devs created for themselves, but it would indeed be the problem.