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 <
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk