Hello,
My 2c: I've found that the easiest way to do this is to use blocking
reads. I'm not sure whether you can get any performance benefit by not
using blocking reads; I kind of doubt it. Also using blocking reads
simplifies things _a lot_, since all you have to do is:
1) read a known number of bytes that tells you how many more you have to read
2) read as many bytes as resulted at step 1)
I'd reserve at least the first two bytes of the message for the size -
you may want to send messages larger than 256 bytes.
Since the requirement is for binary messages, from Aaron's email 1.A
is not applicable, while 1.B complicates things needlessly, having to
use escape characters and such.
Hope this helps,
Radu
On 5/22/07, bringiton bringiton
Thanks for tip aaron.
I'm planning on using a message length byte at the start of the packet. Therefore the reader reads the byte and then waits until there are X bytes in the stream before it reads.
I asssume you are talking about << and >> operators for parsing. My concern here is that if the message has not been completely sent, then the reader will be blocked. I'm using TCP asynchronously.
On 5/22/07, Aaron W. LaFramboise
wrote: bringiton bringiton wrote:
Are there any solutions to this? ie building messages as they come in through the TCP stream.
Parse data from a socket stream the same way you'd parse data from any other sort of stream, such as a file. That is, design the protocol such that end-points can parse the message using its own contents, rather than meta-data such as 'messages.'
Possibilities: 1) Use delimiters. A. Use text and use CRLF for a delimiter. B. Use a special octet as a delimiter, such as the null character. 2) Use message content-length _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users