Register for your free account! | Forgot your password?

Go Back   elitepvpers > MMORPGs > Conquer Online 2 > CO2 Private Server
You last visited: Today at 02:50

  • Please register to post and access all features, it's quick, easy and FREE!

Advertisement
Bitcoin Dice Game


[Question] Comet ! Can You Explain This Snippet

Discussion on [Question] Comet ! Can You Explain This Snippet within the CO2 Private Server forum part of the Conquer Online 2 category.

Reply
 
Old   #1
 
elite*gold: 0
Join Date: Jun 2017
Posts: 9
Received Thanks: 0
Question [Question] Comet ! Can You Explain This Snippet

i'm currently studying network programming , i use comet as a reference as it's well documented

but i can't understand

here is my thoughts:

- client sends bytes for the first time => let's say 80 bytes (3 packets each 32bytes length, third one will be received completely on next loop)

- server on receive sets consumed = 0, examined = 80
- server decrypts bytes from 0 to 80
- server splits the bytes to 2 packets and sends them to a queue so now consumed = 64, examined = 80

my question is what will this snippet do? copying the unprocessed bytes to what ?
Code:
 actor.Buffer.Slice(consumed, examined).CopyTo(actor.Buffer);



Vapx is offline  
Old 05/09/2020, 07:40   #2
 
elite*gold: 12
Join Date: Jul 2011
Posts: 7,699
Received Thanks: 3,805
Quote:
Originally Posted by Vapx View Post
i'm currently studying network programming , i use comet as a reference as it's well documented

but i can't understand

here is my thoughts:

- client sends bytes for the first time => let's say 80 bytes (3 packets each 32bytes length, third one will be received completely on next loop)

- server on receive sets consumed = 0, examined = 80
- server decrypts bytes from 0 to 80
- server splits the bytes to 2 packets and sends them to a queue so now consumed = 64, examined = 80

my question is what will this snippet do? copying the unprocessed bytes to what ?
Code:
 actor.Buffer.Slice(consumed, examined).CopyTo(actor.Buffer);
To itself at offset 0.

It copies the unprocessed bytes to the front of the buffer. That way, the next receive can write its bytes starting from that offset and complete the packet.


Spirited is offline  
Thanks
2 Users
Old 05/09/2020, 07:58   #3
 
elite*gold: 0
Join Date: Jun 2017
Posts: 9
Received Thanks: 0
Does CopyTo clean out the buffer before writing at offset 0 ?

Sorry for such questions i can't find any useful documentation about it
Vapx is offline  
Old 05/09/2020, 08:17   #4
 
elite*gold: 12
Join Date: Jul 2011
Posts: 7,699
Received Thanks: 3,805
Quote:
Originally Posted by Vapx View Post
Does CopyTo clean out the buffer before writing at offset 0 ?

Sorry for such questions i can't find any useful documentation about it
No, it doesn't clear the buffer. It's not the most secure solution in the event that there's a bug which leaks the buffer, but it is the more efficient solution.


Spirited is offline  
Thanks
1 User
Old 05/09/2020, 08:45   #5
 
elite*gold: 0
Join Date: Jun 2017
Posts: 9
Received Thanks: 0
I really like your design. Thanks Alot ❤ !
Vapx is offline  
Old 05/11/2020, 07:23   #6
 
elite*gold: 0
Join Date: Sep 2007
Posts: 601
Received Thanks: 125
Quote:
Originally Posted by Spirited View Post
To itself at offset 0.

It copies the unprocessed bytes to the front of the buffer. That way, the next receive can write its bytes starting from that offset and complete the packet.
It copies far more bytes than just the unprocessed bytes. If you receive 70 bytes, and only consume 50 of them, it will still copy 70 bytes from index 50, which will eventually cause you an issue. Also, if you happen to have left over bytes from the last receive call it will decipher them a second time, causing an even larger issue.

I must have been looking at this the same guy OP was, but I haven't had a chance to test what I think is a decent solution. I can submit a merge request once I test it out.

Should note that I determined this was an issue with a static analysis because I'm far to lazy to wait for a partial packet to be received. Was trying to get fancy with the exchange packet and realized there are a couple other issues.
StarBucks is offline  
Old 05/11/2020, 19:14   #7
 
elite*gold: 12
Join Date: Jul 2011
Posts: 7,699
Received Thanks: 3,805
Quote:
Originally Posted by StarBucks View Post
It copies far more bytes than just the unprocessed bytes. If you receive 70 bytes, and only consume 50 of them, it will still copy 70 bytes from index 50, which will eventually cause you an issue. Also, if you happen to have left over bytes from the last receive call it will decipher them a second time, causing an even larger issue.

I must have been looking at this the same guy OP was, but I haven't had a chance to test what I think is a decent solution. I can submit a merge request once I test it out.

Should note that I determined this was an issue with a static analysis because I'm far to lazy to wait for a partial packet to be received. Was trying to get fancy with the exchange packet and realized there are a couple other issues.
Hm? If 70 bytes are received and only 50 bytes are consumed, the slice of 50 to 70 (20 bytes in total) will be copied to the front of the array. Are you saying a total of 70 bytes will attempt to be copied from the source if the destination is that size? That's fundamentally wrong from a language design perspective and would be a very bad language bug if the case. I'll check when I get off work today... but do you have an example that reproduces this behavior?
Spirited is offline  
Thanks
1 User
Old 05/11/2020, 19:17   #8
 
elite*gold: 0
Join Date: Sep 2007
Posts: 601
Received Thanks: 125
It isn't a language bug, it is improper use of Slice. Slice(int start, int length) you are using it as Start(int start, int end) which is incorrect. You seem to use Slice correctly in the other instances I see in the immediate code surrounding this one use.

Need to keep track of the remaining unconsumed bytes anyway so you don't decipher them twice

edit: Example, log in two clients. I'm not sure if it will reproduce with <=5017 but is happening on client version 5517.
StarBucks is offline  
Thanks
1 User
Old 05/11/2020, 19:45   #9
 
elite*gold: 12
Join Date: Jul 2011
Posts: 7,699
Received Thanks: 3,805
Quote:
Originally Posted by StarBucks View Post
It isn't a language bug, it is improper use of Slice. Slice(int start, int length) you are using it as Start(int start, int end) which is incorrect. You seem to use Slice correctly in the other instances I see in the immediate code surrounding this one use.

Need to keep track of the remaining unconsumed bytes anyway so you don't decipher them twice

edit: Example, log in two clients. I'm not sure if it will reproduce with <=5017 but is happening on client version 5517.
Oh, yep. That's a bug. I'm used to how Golang, Python, Javascript, and any other language does slices which is start to end. Lol... **** it C#. I'll get a fix in for that. Thanks for the catch. The copy is bad, but I'm still tracking unconsumed bytes correctly, right? It shouldn't be decrypting data twice. Why would logging in two clients affect this logic? That task is per client connection.

Edit: Ah, it does decrypt twice. I see that slice is also wrong. I'll correct that.
I guess this is what I get for rushing this project.
Spirited is offline  
Thanks
1 User
Old 05/11/2020, 20:09   #10
 
elite*gold: 0
Join Date: Sep 2007
Posts: 601
Received Thanks: 125
Not directly caused by two clients being logged in but have the best results replicated it that way.
StarBucks is offline  
Old 05/12/2020, 03:44   #11
 
elite*gold: 12
Join Date: Jul 2011
Posts: 7,699
Received Thanks: 3,805
Quote:
Originally Posted by StarBucks View Post
Not directly caused by two clients being logged in but have the best results replicated it that way.
Oh, you mean two clients on different versions. Got it.
Again, good catch. Thanks.


Spirited is offline  
Reply



« Poison Blade, HP and MP Backsword | Case file numbers? »



All times are GMT +2. The time now is 02:50.


Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
SEO by vBSEO ©2011, Crawlability, Inc.

BTC: 33E6kMtxYa7dApCFzrS3Jb7U3NrVvo8nsK
ETH: 0xc6ec801B7563A4376751F33b0573308aDa611E05

Support | Contact Us | FAQ | Advertising | Privacy Policy | Terms of Service | Abuse
Copyright ©2020 elitepvpers All Rights Reserved.