Hi Eric,
Having read this in more detail now:
On Mon, Mar 28, 2016 at 09:56:36PM -0600, Eric Blake wrote:
> + The server MUST ensure that each read chunk lies within the original
> + offset and length of the original client request, MUST NOT send read
> + chunks that would cover the same offset more than once, and MUST
> + send at least one byte of data in addition to the offset field of
> + each read chunk. The server MAY send read chunks out of order, and
> + may interleave other responses between read replies. The server
> + MUST NOT set the error field of a read chunk; if an error occurs, it
> + MAY immediately end the sequence of structured response messages,
> + MUST send the error in the concluding normal response, and SHOULD
> + keep the connection open. The final non-structured response MUST
> + set an error unless the sum of data sent by all read chunks totals
> + the original client length request.
I'm thinking it would probably be a good idea to have the concluding
response (if the error field is nonzero) have an offset too; the server
could use that to specify where, exactly, the error occurred (so that a
client which sent a very large read request doesn't have to go through a
binary search or some such to figure out where the read error happened)
i.e.,
C: read X bytes at offset Y
S: (X bytes)
S: (error, offset Z)
client now has Z-1 bytes of valid data (with the rest being garbage,
plus a read error)
The alternative (in the above) would be that the client has 0 bytes of
valid data, and would have to issue another read request to figure out
which parts of the data are valid.
> + The client SHOULD immediately close the connection if it detects
> + that the server has sent an offset more than once (whether or not
> + the overlapping data claimed to have the same contents), or if
> + receives the concluding normal reply without an error set but
> + without all bytes covered by read chunk(s). A future extension may
I would reword this to...
The client MAY immediately close the connection if it detects that
[...]. The server MUST NOT send an offset more than once.
> + add a command flag that would allow the server to skip read chunks
> + for portions of the file that read as all zeroes.
Not sure if that part is necessary or helpful, really.
--
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
people in the world who think they really understand all of its rules,
and pretty much all of them are just lying to themselves too.
-- #debian-devel, OFTC, 2016-02-12
