Source CandyConquer BUG

[liqicong]

Hello anyone
I'm using candyconquer and trying to complete the missing features. I found a serious problem.

If level >= 70 and re-login 2 or 3 times, the client will disappear.


I think the problem is here.

I remove player.UpdateClientNobility(); problem no longer occurs.

The NobilityPacket seems to have no problem, Nobility works fine.

I not donate, The problem still arises.
I didn't get any exception messages.
please help me.


my english bad, sorry

[Super Aids]

Are you sure you're using the correct client version?

also please log all packets send to the client and received by the server and post the log here.

Because when the client "disappears" it's usually because it receives either an invalid packet or an invalid packet size.

[liqicong]

The client version is correct.
I checked these packets and it seems that there is no problem.

'10.0.0.2' has connected to the server.
packetId：35237 Length：43185
packetId：2079 Length：8
packetId：2078 Length：264
packetId：1004 Length：52
packetId：1006 Length：124
packetId：1033 Length：36
packetId：10010 Length：37
packetId：1110 Length：20
packetId：1016 Length：20
packetId：10010 Length：37
packetId：10010 Length：38
packetId：1008 Length：68
packetId：1015 Length：19
packetId：10010 Length：38
packetId：10010 Length：38
packetId：10010 Length：38
packetId：10010 Length：38
packetId：10010 Length：38
packetId：10017 Length：28
packetId：10017 Length：28
packetId：10017 Length：28
packetId：1040 Length：136
packetId：10017 Length：28
packetId：10017 Length：28
packetId：10017 Length：28
packetId：1040 Length：136
packetId：10017 Length：28
packetId：10017 Length：28
packetId：10017 Length：28
packetId：1040 Length：136
packetId：10017 Length：28
packetId：10017 Length：28
packetId：10017 Length：28
packetId：1040 Length：136
packetId：10017 Length：28
packetId：10017 Length：28
packetId：10017 Length：28
packetId：1040 Length：136
packetId：10017 Length：28
packetId：10017 Length：28
packetId：10017 Length：28
packetId：2064 Length：58
packetId：10017 Length：28
packetId：10017 Length：28
packetId：1004 Length：91
'taoist' has successfully logged in...
packetId：10005 Length：24
packetId：10005 Length：24
packetId：10005 Length：24
packetId：10005 Length：24
packetId：10005 Length：24
'10.0.0.2' has disconnected from the server Reason: [N-6]The socket has been disconnected.
'10.0.0.2' has connected to the server.
packetId：11980 Length：54906
packetId：2079 Length：8
packetId：2078 Length：264
packetId：1004 Length：52
packetId：1006 Length：124
packetId：1033 Length：36
packetId：10010 Length：37
packetId：1110 Length：20
packetId：1016 Length：20
packetId：10010 Length：37
packetId：10010 Length：38
packetId：1008 Length：68
packetId：10010 Length：38
'10.0.0.2' has disconnected from the server Reason: [N-2]The client has been disconnected.

The first login send packet 2064
There will be problems with the second login.

packet 2064 no problem

[Super Aids]

packetId：35237 Length：43185
packetId：11980 Length：54906

Are wrong.

I think you need to debug that.

Did you make sure the account etc. was entirely clean and the data too.

It looks like something is corrupt in it.

(I can't reproduce it and nobody else seem to have the issue either.)

[Spirited]

Originally Posted by Super Aids

packetId：35237 Length：43185
packetId：11980 Length：54906

Are wrong.

I think you need to debug that.

Did you make sure the account etc. was entirely clean and the data too.

It looks like something is corrupt in it.

(I can't reproduce it and nobody else seem to have the issue either.)

Those incorrect packet Ids and lengths are probably the DH key exchange.
But yeah, as you said, it needs to be debugged.

[liqicong]

Originally Posted by Super Aids

packetId：35237 Length：43185
packetId：11980 Length：54906

Are wrong.

I think you need to debug that.

Did you make sure the account etc. was entirely clean and the data too.

It looks like something is corrupt in it.

(I can't reproduce it and nobody else seem to have the issue either.)

I use the new clean source, found that the problem also exists

Originally Posted by Spirited

Those incorrect packet Ids and lengths are probably the DH key exchange.
But yeah, as you said, it needs to be debugged.

I have been debugging for a long time and can't find the problem.

[liqicong]

I fixed it, send packet 2064 in here.

I don't know why.

[Spirited]

Originally Posted by liqicong

I fixed it, send packet 2064 in here.

I don't know why.

I don't understand, can you clarify? How did you fix it? What was the issue?
Thanks.

[liqicong]

Originally Posted by Spirited

I don't understand, can you clarify? How did you fix it? What was the issue?
Thanks.

I'm not sure what the problem is.
I found that changing the location of player.UpdateClientNobility(); can avoid this problem.

[Asphy×ia]

Arco and I worked with this source for upwards of 6 months and never had this issue. Not sure why that's causing problems.

[liqicong]

Originally Posted by Asphy×ia

Arco and I worked with this source for upwards of 6 months and never had this issue. Not sure why that's causing problems.

It looks like my problem, but I use the clean source and new client, found that the problem also exists.

[Spirited]

It's possible that it's some race condition that's just now being spotted due to varying hardware. I took a lot at the source, but the abstraction of everything still makes it difficult to read that source and follow the code... Especially when you don't have Visual Studio installed on your tablet. I couldn't see anything out of the ordinary. I can try installing Visual Studio when I get home... But it's such a huge program...

[liqicong]

Originally Posted by Spirited

It's possible that it's some race condition that's just now being spotted due to varying hardware. I took a lot at the source, but the abstraction of everything still makes it difficult to read that source and follow the code... Especially when you don't have Visual Studio installed on your tablet. I couldn't see anything out of the ordinary. I can try installing Visual Studio when I get home... But it's such a huge program...

If it is hardware varying what should I do?

[turk55]

I remember having the same issue. I believe I fixed it by adding condition checks to the packet reader/writer class. As the source is now, there are no conditions.

[Super Aids]

Originally Posted by turk55

I remember having the same issue. I believe I fixed it by adding condition checks to the packet reader/writer class. As the source is now, there are no conditions.

A wild guess is that the virtual size of a packet doesn't match the actual size of the packet.

Ex.

{
    ushort: 6 (size)
    ushort: 2
    uint: 1
    uint  1
}

Has a virtual size of 6.

But a physical size of 12.

That means when the client receives the packet it will read the first 6 bytes and then the second half of the first uint will be a new packet to the client and will most likely be read as an invalid size since it obviously isn't the size of a packet.

Instead that packet should have been:

{
    ushort: 12 (size)
    ushort: 2
    uint: 1
    uint  1
}

---

That's also why I said debug and log the packets. Check what the server is actually sending to the client.

Originally Posted by Spirited

It's possible that it's some race condition that's just now being spotted due to varying hardware. I took a lot at the source, but the abstraction of everything still makes it difficult to read that source and follow the code... Especially when you don't have Visual Studio installed on your tablet. I couldn't see anything out of the ordinary. I can try installing Visual Studio when I get home... But it's such a huge program...

Definitely not a race condition, or at least it shouldn't be since it doesn't send anything across threads to the client during login which is when this happens.

And even when it does it's concurrent and shouldn't cause any race conditions.