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.