Re: [Boost-users] boost::asio::async_read_until fills streambuf less than actually received

Subject: Re: [Boost-users] boost::asio::async_read_until fills streambuf less than actually received
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2018-04-03 01:41:47

On 2/04/2018 20:46, David Demelier wrote:
> I'm using Asio to read IRC messages asynchronously from a server. I use
> boost::asio::async_read_until with "\r\n" as delimiter and a
> boost::asio::streambuf as output buffer.
> 
> I mostly implemented the code like described on my original
> question/answer here:
> 
> https://stackoverflow.com/questions/40561097/read-until-a-string-delimi
> ter-in-boostasiostreambuf
> 
> I sometimes get the bytes_transferred argument bigger that what is
> filled into the buffer.

I haven't looked at your code, but the most common problem with using 
[async_]read_until is correctly preserving the streambuf between calls 
(and realising that you need to do so).

The way that read_until works under the hood is that it reads an 
arbitrary amount of data from the underlying socket into the streambuf, 
and then returns a value *less than* the amount of data it actually read 
to indicate at which point the delimiter was found.

You are required to preserve the same streambuf and pass it to the next 
call (which must also be an [async_]read_until call -- don't alternate). 
  This call will *first* search the existing data in the streambuf for 
your next delimiter and may return immediately with a value less than 
the amount of data remaining in the streambuf, without actually 
performing another network read.  Or it may again append an arbitrarily 
large block of additional data and then return a subset of it up to the 
delimiter.

If you can't avoid alternating read_untils with other kinds of reads, 
then it is your responsibility to check if the streambuf already 
contains sufficient data to satisfy your non-until read, and only issue 
an actual read request for the balance (if any).