[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 [Only registered and activated users can see links. Click Here To Register...]

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 ?

Quote:

Originally Posted by Vapx i'm currently studying network programming , i use comet as a reference as it's well documented but i can't understand [Only registered and activated users can see links. Click Here To Register...] 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.

Does CopyTo clean out the buffer before writing at offset 0 ?

Sorry for such questions i can't find any useful documentation about it

Quote:

Originally Posted by Vapx 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.

I really like your design. Thanks Alot ❤ !

Quote:

Originally Posted by Spirited 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.

Quote:

Originally Posted by StarBucks 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?

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.

Quote:

Originally Posted by StarBucks 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... damn 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.

Not directly caused by two clients being logged in but have the best results replicated it that way.

Quote:

Originally Posted by StarBucks 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.