Re: [Boost-users] [asio] socket::read_some() splits data into twoparts.

Subject: Re: [Boost-users] [asio] socket::read_some() splits data into twoparts.
From: Andrew Holden (aholden_at_[hidden])
Date: 2011-05-11 10:36:11

On Wednesday, May 11, 2011 9:57 AM, Slav wrote:
> Then messages of length not multiple of 128 (BUFFER_SIZE)
> will not be read - tested it, anyway, after
> last socket::read_some() (with readBytes > 0 && <
> BUFFER_SIZE) next socket::read_some() never ends.

It would probably help to understand that TCP has no concept of a
"message".  Anything you write to a socket is appended to a stream of
*bytes*.  Several subsystems on both the sending and receiving computers
will have the option of splitting and combining adjacent buffers with no
consideration to how big each individual write was.  Read_some has the
option of reading any size up to and including the buffer size, but a
read of less than that size does not mean "end of message".  It could
also mean "network congestion", "cable unplugged", or "Windows just felt
lazy".

On further thought, I think I see the problem (and I apologize for the
bad recommendation in my last email).  Your sender somehow needs to
communicate the message size or flag the end of the message.  A partial
list of options includes:

* Begin the message with a field specifying its total length.  The
receiving loop must read this length and then count bytes until it has
the whole message, keeping in mind that each read_some can read any
number of bytes.

* Begin each message with a message id, where each message id has a
known length.  Once you calculate the length, count bytes as I described
above.

* End the message with a terminator.  You could set up a line-oriented
protocol where a newline terminates the read.  With some thought, you
might think of some other terminating byte or string appropriate to your
protocol.

In all cases, unless your final read_some has a carefully controlled
size, remember that your buffer may contain the beginning of the next
message, or even multiple complete messages.  If so, it is your
responsibility to retain this until you are ready to process the next
message.