[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Nbd] [PATCH 3/1] doc: Propose Structured Replies exten

From: Wouter Verhelst
Subject: Re: [Qemu-devel] [Nbd] [PATCH 3/1] doc: Propose Structured Replies extension
Date: Tue, 29 Mar 2016 19:53:19 +0200
User-agent: Mutt/1.5.24 (2015-08-30)

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)


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]