Boost logo

Boost :

From: Vinícius dos Santos Oliveira (vini.ipsmaker_at_[hidden])
Date: 2022-04-08 18:20:35

Em sex., 8 de abr. de 2022 às 12:10, Marcelo Zimbres Silva via Boost <
boost_at_[hidden]> escreveu:

> [...]

I'm not a redis user myself so I won't be able to comment much on this
topic, but here's some early and sloppy feedback...

Link to Aedis Documentation:

The dynamic buffer example from the documentation's front-page seems weird.

Dynamic buffer fills the gap to turn raw IO into buffered IO. Raw IO is all
about passing the read calls directly to the layer immediately below. When
you're parsing streams there's no implicit framing between the messages, so
you buffer. And you do need to buffer because only by chance you'd be able
to receive exactly the contents of a single message. If you receive less
bytes than required, keep the buffer and read more. If you receive more
bytes than required, consume the current message and keep the rest for the
next read.

It follows that the dynamic buffer will abstract a few properties:

   - Capacity (non-used part of the buffer)
   - Ready data

Then Boost.Asio will also introduce the concept of max_size to allow
growing buffers with a level of protection against DoS attacks. Similar
frameworks will do just the same (e.g. bufio.Scanner from Golang). But do
notice a concept is still missing in Boost.Asio's dynamic buffer: a
pointer/marker to the current message size. Boost.Asio's buffered IO
abstraction (dynamic buffer) is different from other frameworks in this
regard (e.g. Golang's bufio.Scanner) and defer this responsibility to the
user (cf. read_until()'s return value). I personally don't like Boost.Asio
choice here, but that's just the way it is.

Now, from your example:

std::string request, read_buffer, response;
// ...
co_await resp3::async_read(socket, dynamic_buffer(read_buffer)); // Hello
co_await resp3::async_read(socket, dynamic_buffer(read_buffer),
adapt(response)); // Set
co_await resp3::async_read(socket, dynamic_buffer(read_buffer)); // Quit

By recreating the dynamic buffer every time, you discard the "native"
capacity property from the dynamic buffer.

Also I don't see a return value to indicate the current message size so I
know what to discard from the current buffer. You always discard the
current message yourself (and a second argument must be supplied if the
user wants to save the response). If the current message was kept in the
buffer then the response could just hold string_views to it. What are your

Vinícius dos Santos Oliveira

Boost list run by bdawes at, gregod at, cpdaniel at, john at