Re: [boost] [http] Formal Review

On Sun, Aug 16, 2015 at 10:07 AM, Vinícius dos Santos Oliveira < vini.ipsmaker@gmail.com> wrote:

2015-08-16 0:25 GMT-03:00 Lee Clagett :

...

Why would there be an excessive read? The implementation knows before the read call that only x bytes can be read, why would it read past that amount? If this interface works for ASIO, it would seem suitable for reading a sequence of bytes from a HTTP payload.

Because it might not even use a buffer. You continue to only think about the HTTP wire format and the standalone/embedded server use case. It could be a hypothetical protocol that uses shared memory that get dropped and must be consumed.

A UDP socket or unix domain datagram socket would be more obvious examples, but I would be interested in seeing how this would occur in shared memory (just not aware of such an example). Do you mean like a (possibly in-order) queue of messages? This actually sounds like a ZeroMQ scenario, most likely using multi-part messages, because its a pseudo in-order datagram system. Anyway, things to note - - The overwhelming common case will be reading from a stream, most likely TCP, and I think the focus should be providing the best interface for this scenario (apparently you feel differently). - The HTTP payload is either a stream (connection:close), a stream of datagrams (chunked), or a datagram (content-length). - Datagrams can also be treated like a stream if the datagram is kept across calls (as you mentioned). - The function is named `async_read_some` after the ASIO buffered_read_stream/buffered_stream concept, so it suggests data is being read from an underlying stream. - The behavior for `async_read_some` in the Socket concept can behave like a typical read from a stream interface, OR read an entire message of unspecified size depending on the implementation. - When reading datagrams/messages, a fixed buffer allocated by the caller is a common read interface, in which case the extra data is dropped. - Even users that expect these types of messages cannot reliably limit the Container expansion through the proposed implementation, as they can with UDP, domain sockets, ZeroMQ, etc. Lee