通过TCP处理消息

Question

I'm trying to send and receive messages over TCP using a size of each message appended before the it starts.

Say, First three bytes will be the length and later will the message:

As a small example:

005Hello003Hey002Hi

I'll be using this method to do large messages, but because the buffer size will be a constant integer say, 200 Bytes. So, there is a chance that a complete message may not be received eg instead of 005Hello I get 005He nor a complete length may be received eg I get 2 bytes of length in message.

So, to get over this problem, I'll need to wait for next message and append it to the incomplete message etc.

My question is: Am I the only one having these difficulties to appending messages to each other, appending lengths etc.. to make them complete Or is this really usually how we need to handle the individual messages on TCP? Or, if there is a better way?

Answer 1

What you're seeing is 100% normal TCP behavior. It is completely expected that you'll loop receiving bytes until you get a "message" (whatever that means in your context). It's part of the work of going from a low-level TCP byte stream to a higher-level concept like "message".

And "usr" is right above. There are higher level abstractions that you may have available. If they're appropriate, use them to avoid reinventing the wheel.

Answer 2

So, there is a chance that a complete message may not be received eg instead of 005Hello I get 005He nor a complete length may be received eg I get 2 bytes of length in message.

Yes. TCP gives you at least one byte per read, that's all.

Or is this really usually how we need to handle the individual messages on TCP? Or, if there is a better way?

Try using higher-level primitives. For example, BinaryReader allows you to read exactly N bytes (it will internally loop). StreamReader lets you forget this peculiarity of TCP as well.

Even better is using even more higher-level abstractions such as HTTP (request/response pattern - very common), protobuf as a serialization format or web services which automate pretty much all transport layer concerns.

Don't do TCP if you can avoid it.

Answer 3

So, to get over this problem, I'll need to wait for next message and append it to the incomplete message etc.

Yep, this is how things are done at the socket level code. For each socket you would like to allocate a buffer of at least the same size as kernel socket receive buffer, so that you can read the entire kernel buffer in one read/recv/resvmsg call. Reading from the socket in a loop may starve other sockets in your application (this is why they changed epoll to be level-triggered by default, because the default edge-triggered forced application writers to read in a loop).

The first incomplete message is always kept in the beginning of the buffer, reading the socket continues at the next free byte in the buffer, so that it automatically appends to the incomplete message.

Once reading is done, normally a higher level callback is called with the pointers to all read data in the buffer. That callback should consume all complete messages in the buffer and return how many bytes it has consumed (may be 0 if there is only an incomplete message). The buffer management code should memmove the remaining unconsumed bytes (if any) to the beginning of the buffer. Alternatively, a ring-buffer can be used to avoid moving those unconsumed bytes, but in this case the higher level code should be able to cope with ring-buffer iterators, which it may be not ready to. Hence keeping the buffer linear may be the most convenient option.