On 09/22/2017 09:57 AM, Vladimir Sementsov-Ogievskiy wrote: >> If you have suggestions for improving the NBD spec wording, feel free to >> propose a doc patch. >> > > Thanks, now I understand.. However I don't have good idea of wording.. > > > Another thing: server can send several error and success chunks on > CMD_READ.. Yes, and that is intentional. A server that spawns sub-tasks to read portions of the request to various parallel workers, and then sends those responses back to the client as sub-tasks finish, can indeed send multiple errors before sending the final chunk complete message. > > The obvious behavior of client is to fail the whole read if it received > one error chunk. Yes, the read has failed if the client sees at least one error chunk. The read is not successful unless there are no error chunks, and the server has sent chunks describing every portion of the request (the server is not allowed to send chunks that overlap, nor to send a successful chunk after sending an error for the same offset, nor to send a success message if it has not covered the entire request - but IS allowed to send multiple error chunks). > And, actually, client is not interesting in all following chunks for > this request. Perhaps not, but the client is not in control of how much the server sends, so it must gracefully deal with the remaining traffic from the server while waiting for the server to finally send the last chunk. > I think > we need some additional negotiation flag for this, which says that error > chunk > must be final. Why? It adds complexity, for no real reason. (Read errors are not common, so it is okay if dealing with read errors requires more network traffic than normal). > > May be we need also a method (command) to cancel one of inflight > requests, but it > is not so important. Again, that would add complexity that may be really hard to justify (we want to be able to implement stateless servers; a server that has to parse a second message from a client requesting to abort an in-flight command has to track state). So I don't think it is worth it. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature