
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.