Subject: Re: [boost] [http] Formal Review
From: Lee Clagett (forum_at_[hidden])
Date: 2015-08-16 13:16:33
On Sun, Aug 16, 2015 at 10:07 AM, VinÃcius dos Santos Oliveira <
vini.ipsmaker_at_[hidden]> wrote:
> 2015-08-16 0:25 GMT-03:00 Lee Clagett <forum_at_[hidden]>:
>
> > 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