CODEWITHSUNDEEP
c#.net
Fetrix
Fetrix

Reputation: 13

Asynchronous TCP socket bytes merging

I wasn't quite sure how to explain my problem in the title, but I'll try to elaborate on my problem.

Basically I'm coding a chat that is not P2P, but where all users connect to a central server, similar to IRC. The connections are asynchronous and it almost works flawlessly. The main issue is that, when a lot of data is sent to one user (or to the server from one user) at once, the bytes may merge, resulting in errors. I've approached this by adding a header of 4 bytes containing the length of the data in front of the rest of the data. Still, the bytes seem to merge. I've also tried setting NoDelay to true and DontFragment to false; still, it doesn't work.

I'm guessing the problem is that when the bytes merge, I only handle the first bytes and then do nothing with the remaining. What would be the best way to approach this issue?

Receive callback code: http://pastebin.com/f0MvjHag

Upvotes: 1

Views: 1683

Answers (2)

Yasahiro
Yasahiro

Reputation: 56

This usually happens when two or more packets of data are sent at close intervals. I recently had this problem myself, and the way I resolved it was to a separating key. You can then tokenize each message. For example, you could add the ASCII character #4 (the End-of-Transmission character) to the end of each message being sent like I did.

Write("Message1" + ((char)4).ToString())
Write("Message2" + ((char)4).ToString())

Then, when the client receives the data, you can iterate through the received data. When it finds that special character, it knows it's the end of one message, and (maybe) the beginning of a new one.

"Message1(EOT char)Message2(EOT char)"

\n may be easier to work with than using ASCII characters.

Upvotes: 2

HABO
HABO

Reputation: 15816

That's why they call it a stream. You put bytes in at one end and TCP guarantees they come out in the same order, none missing or duplicated, at the far end. Anything bigger than a byte is your problem.

You have to accumulate enough bytes in a buffer to have your header. Then interpret it and start processing additional bytes. You may have a few left over that start the next header.

This is normal behavior. When your application is not receiving data the system will be buffering it for you. It will try to hand off the available data the next time you make a request. On the other side, a large write may travel over connections that do not support an adequate frame size. They will be split as needed and arrive eventually in dribs and drabs.

Upvotes: 3

Related Questions