does tcp/ip conveys complete messages?

I'm building a library that maintainces connection over network between apps in c++. During some debuging I have found that some information I get from socket seems incomplete. It is vital this information is complete because if I decode it with protocol buffers' library, I need complete message.

The phenomenon is not constant. Sometimes I get all data from the socket, sometimes not. The test procedure looks like: start server, start client multiple times. What I get is output from function receive() that depict how values of some variables change. One of them is the si开发者_运维百科ze of the buffer I use to store data. That size tells me how much data is in the buffer. The clients send two messages each of size 3 (bytes) - in this particular test. I expect the buffer size to be multiple of 3. However, sometimes the size is 4!. That means program read one complete message and 1/3 of the second message. I don't understand why I always get first message complete. Otherwise, protobuf would terminate the program.

I thought tcp/ip should take care I get complete messages. My problem is I don't know the size in advance. I expect to receive full message so that I can interpret it corecty.

TCP is a stream based protocol, not a message based protocol. TCP has no idea when your messages begin or end, and so there is no guarentee that you will get a full message in a single call. There is also no guarentee that you'll get only one full message. You must buffer the data you receive, and split it into messages yourself. If you don't get a full message, store what data you have received, and wait until the rest arrives.

TCP is allowed to fragment your data into multiple datagrams, which are assembled in-order at the recipient. You are guaranteed that your data will eventually arrive, in the order it was sent. But some portion of the data you send may arrive earlier than the rest.

What you are experience may be that when you call receive, a portion of the data you sent has arrived at your computer, but some portion of it is still being sent over the network. You will have to buffer the portions of data you receive and wait until you have received a complete "message." One way you can handle this is by sending a fixed-length record at the beginning of each message, which encodes the length of the remaining bytes in the message. For example, you might send a 4-byte unsigned long in network byte order, followed by that many bytes of data.