22.09.2017 23:36, Eric Blake wrote:
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).
Hmm, when writing error handling, it may seem that the program is processing errors
almost all the time). Ok, really they are not common, so it doesn't really matter.
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.
-- Best regards, Vladimir