Em sex., 8 de abr. de 2022 às 12:10, Marcelo Zimbres Silva via Boost < boost@lists.boost.org> 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 (ignored). co_await resp3::async_read(socket, dynamic_buffer(read_buffer), adapt(response)); // Set co_await resp3::async_read(socket, dynamic_buffer(read_buffer)); // Quit (ignored) 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 thoughts? -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/