Re: [Boost-users] [asio] continuous reads into streambuf

Subject: Re: [Boost-users] [asio] continuous reads into streambuf
From: Stephan Menzel (stephan.menzel_at_[hidden])
Date: 2018-05-24 17:49:07

Hello Vinnie,

thanks for your reply

On Thu, May 24, 2018 at 5:22 PM, Vinnie Falco via Boost-users <
boost-users_at_[hidden]> wrote:

>
> However, let me propose a wild idea. Set your current code aside for
> the moment and reimplement it a different way. Instead of doing three
> asynchronous reads, call async_read_some once into your
> basic_streambuf. Use a reasonably large size in the call to prepare
> (say, 2048 or higher). When you have data in your buffer, inspect the
> contents and determine if you have a complete message. If not, then
> keep looping and calling async_read_some until your buffer has an
> entire message. Then extract the message, consume the bytes used, and
> repeat. When extracting the bytes do not use asynchronous I/O.
>

Not a wild idea at all. Yet a see a two problems with it.
This pretty much means taking over what asio calls 'composed operations'
myself. Instead of letting asio do read_some calls and figure out when I
have, say, a line completely read (until CRL), I read and figure it out
myself. Which is very much what I wanted to avoid by going the streambuf
approach in the first place.
The second issue to me is the inspection of the contents. The packets are
of variable size and can theoretically (though not practically) range up to
about 64k. I don't know how large the payload is until I read and parsed
the header. Which means I would hav to do just that: Inspect the contents
of the buffer. Which I have no idea how to do. Over the years, this is not
the first time I'm trying this approach and I always folded when it came to
inspecting the contents of a streambuf. I simply don't know how this can be
done. I can't even reliably do it in the debugger. Sure, I see data but
which is input and which is output and where are all those position markers
and what would I really get if I read...

I guess you are right though. An new implementation using fixed buffers
would probably solve the bug as well. As it always did in the past. I guess
I just wanted to be fancy again.

Thanks for your suggestion...

Stephan