From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45437) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akxpk-0005N9-Ac for qemu-devel@nongnu.org; Tue, 29 Mar 2016 13:53:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akxph-0001ad-2Z for qemu-devel@nongnu.org; Tue, 29 Mar 2016 13:53:40 -0400 Received: from barbershop.grep.be ([89.106.240.122]:39588) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akxpg-0001aU-So for qemu-devel@nongnu.org; Tue, 29 Mar 2016 13:53:36 -0400 Date: Tue, 29 Mar 2016 19:53:19 +0200 From: Wouter Verhelst Message-ID: <20160329175319.GA8628@grep.be> References: <1459173555-4890-1-git-send-email-eblake@redhat.com> <1459223796-28474-2-git-send-email-eblake@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1459223796-28474-2-git-send-email-eblake@redhat.com> Subject: Re: [Qemu-devel] [Nbd] [PATCH 3/1] doc: Propose Structured Replies extension List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: nbd-general@lists.sourceforge.net, qemu-devel@nongnu.org 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