5017 Login Sequence

[Rezlind]

Hi everyone,

For some context I've been upgrading Cpt Sky's Copsv6 enhanced version from 4330 to 5017. It's been a really great learning experience thus far and actually having a server to practice on has helped fulfill my understanding of how conquer works faster and better than just reading about it.

So far I've upgraded pretty much every packet that was changed (and have some notes that I aim to add to the packet wiki.)

However, one annoying race condition has remained throughout the process and I've managed to pinpoint where it's happening but I'm not entirely certain why or how to fix it:

Sometimes, when logging into the server my client will stay on the Logging into the server.... Please wait a moment screen.

Spirited's Comet source has a useful Login sequence doc which helped me pretty conclusively determine that this is not a problem with the handshake between the AccServer <-> Client <-> Gameserver.

It's thanks to the Comet 5017 source and original CopsV6 non enhanced source that I am pretty certain the handshake is working properly. What I think is happening is that the client is sending the MsgConnect packet to the game server before a worker can be properly assigned to handle incoming packets from the client.

The reason I believe this is the case is because sometimes, I can login just fine, and can actually break on the MsgConnect packet being received. When the login fails and I am stuck on the black logging into the server screen the worker assigned to handle the connection for the game client does not detect any incoming packets at all.

I also found a post Spirited made on another forum that suggested the following:

Client hangs on "Logging into the game server".

If the client hangs here, then the DH Key Exchange wasn't handled correctly, and packet 1052 was never received. This might also be a problem with the game cipher. If you first receive a packet other than the authentication receive packet (1052) after receiving the exchange data, then most likely, your game cipher or exchange is invalid or out of date. This could also be the result of not sending "ANSWER_OK" to the client. It's waiting for that message.

I ruled out that any of the above could be happening because sometimes I am able to login successfully, I assume that if the DH Key exchange is working it will always work correctly or always fail.

If anyone has knowledge of this particular source do you have any suggestions on how I could troubleshoot it further? Also, if my understanding of what is happening on the exchange seems incorrect I would also appreciate any corrections made so I don't make the wrong assumptions.

One of my primary assumptions here is that the Client, upon receiving the token, game server ip and port from the account server, immediately connects and IMMEDIATELY sends the MsgConnect packet. I truly suspect that the worker assignment is happening too slowly and the MsgConnect packet is getting lost in some cases.

Summary, tl;dr:

Source: CopsV6 Enhanced

Target Patch: 5017

Problem: Race condition where GameServer thread sometimes does not get the MsgConnect packet from the client

Requesting: Sanity check on my assumptions about what is happening in the login process.

Thanks in advance :)

-----------------------------------------------------------------------

Solution:

Credits to a friend of mine, Opticalza for spotting this.

There appears to be a race condition in the base copsv6 enhanced edition which can result in the client being allowed to BeginReceiving packets before its actually instantiated. The solution proposed by a friend of mine was to move the client.BeginReceive function here

and instead add client.BeginReceive(); after onConnect(client) located here

This ensures that won't run into an instance where this if statement fails and the client packets are never processed.

Hopefully this helps someone else in the future :).

Edited May 7, 2021 by Rezlind

[Spirited]

In patch 5017, you don't have to worry about the DH Key Exchange. That was added in patch 5018 (which is why 5017 was so popular until that was reverse engineered for newer servers). I suppose it's possible that the game server isn't ready when it makes that request. In Comet, I accounted for that using RPC. When the game server is ready for players, it registers with the account server, and that server gets opened up for players (it would otherwise send "Server offline" or something of that nature. I'm not sure how COPS V6 handles handshake between the account and game servers. It might not at all (which I've seen in most servers).

[Rezlind]

I feel like an idiot. The reason this was happening was because early on, before I understood how the packets worked I ran into something that made me add a temporary 1051 switch case fall through like this:

This was probably day one of learning conquer and it stayed there until now. As you can imagine this completely messed up how packet 1051, MsgAccount was getting handled.

Since removing this blunder I've yet to experience the login hanging.

It appears I spoke too soon. Not really sure whats causing it still but will continue to debug;

[Spirited]

Ahhhhh, all good. It happens, man. I had a bug that caused players to drop randomly. Turned out it was an off-by-one error with the packet length back when I wrote packets into static buffers rather than using byte streams. That was absolutely agonizing. Anyways, glad you figured it out!

[Rezlind]

Ahhhhh, all good. It happens, man. I had a bug that caused players to drop randomly. Turned out it was an off-by-one error with the packet length back when I wrote packets into static buffers rather than using byte streams. That was absolutely agonizing. Anyways, glad you figured it out!

Heh, that definitely sounds maddening to track down when you assume everything is working correctly. May I ask what server you use to own back in the day?

[Spirited]

Ahhhhh, all good. It happens, man. I had a bug that caused players to drop randomly. Turned out it was an off-by-one error with the packet length back when I wrote packets into static buffers rather than using byte streams. That was absolutely agonizing. Anyways, glad you figured it out!

Heh, that definitely sounds maddening to track down when you assume everything is working correctly. May I ask what server you use to own back in the day?

I never really "owned" a server, I more prototyped server architecture and my close friends would hop on to test features / stability. Technically, I think I started with CoFuture in Dec 2009 and then tried building on top of Impulse's base source in Aug 2010, but I started writing my own servers after about a year after doing that in Jan 2012? Now I work in the game industry, so I don't really get a lot of time / motivation to work on my old projects again. Maybe I'll get back to Chimera though (my "current" project on the back burner). I've had the itch to for a while.

[Rezlind]

Ahhhhh, all good. It happens, man. I had a bug that caused players to drop randomly. Turned out it was an off-by-one error with the packet length back when I wrote packets into static buffers rather than using byte streams. That was absolutely agonizing. Anyways, glad you figured it out!

Heh, that definitely sounds maddening to track down when you assume everything is working correctly. May I ask what server you use to own back in the day?

I never really "owned" a server, I more prototyped server architecture and my close friends would hop on to test features / stability. Technically, I think I started with CoFuture in Dec 2009 and then tried building on top of Impulse's base source in Aug 2010, but I started writing my own servers after about a year after doing that in Jan 2012? Now I work in the game industry, so I don't really get a lot of time / motivation to work on my old projects again. Maybe I'll get back to Chimera though (my "current" project on the back burner). I've had the itch to for a while.

Ah yeah I'm sure its difficult to find the energy/desire to code after working on code all day. Especially the same kind of code lol.

Note to anyone else in the future reading this thread - the actual solution has been edited in at the end of the first/original post in this thread!