On 04/13/2016 04:25 AM, Alex Bligh wrote: > Wouter, > >>> +A client MAY use a soft disconnect to terminate the session >>> +whenever it wishes, provided that there are no outstanding >>> +replies to options. >> >> NAK. A client MAY use a soft disconnect *at any time*, but the server >> MUST NOT act upon it until there are no outstanding replies, and the >> client MUST NOT send any further options after sending NBD_OPT_ABORT. >> >> (same for CMD_DISC) > > This gets to the root of the unresolved issues I think. I suspect > the answer may be different for NBD_OPT_ABORT and NBD_CMD_DISC. > > NBD commands are asynchronous and can be replied and acted on > in any order (so, from the document): > > "The server MAY process commands out of order, and MAY reply > out of order" > > I wouldn't want to loose that. So if the client sends NBD_CMD_DISC > without waiting for all his inflight commands to complete, those > inflight commands may not be executed at all, because the server > is free to process commands in any order. It's going to make > server design very awkward if you can only process /some/ commands > out of order. We already have that constraint - commands with NBD_CMD_FLAG_FUA must be processed in a particular order, and NBD_CMD_FLUSH must be processed in a particular order. Requiring NBD_CMD_DISC to be processed last is not much different than these other two situations (well, different in that the other two only have to guarantee that commands _with replies_ have hit permanent storage, not ALL commands received). > Another alternative would be to make the server > wait for all commands to complete before acting on the disconnect > (as opposed to or in addition to making the client wait to send > it). I'm reasonably relaxed about which one we do, but I think > we should do one or the other (or at least say that if the > client sends NBD_CMD_DISC without waiting for commands to complete > then those commands must not be executed). There are thus > various choices for NBD_CMD_DISC. I think it is perfectly fair to put the requirement on the server that it MUST wait until all inflight commands have been responded to before disconnecting; and at the same time that a client SHOULD wait until there are no inflight commands before sending NBD_CMD_DISC. > > I think the option haggling phase is different (or rather need > not be the same). Fundamentally options MUST be processed in > the order they are issued, No, we already explicitly state that options may be replied to out-of-order, and that the burden is on the client to wait for particular replies before sending another option of the same type. > and there is only ever one in > flight at a time. No, a client can batch send a bunch of options before waiting for any replies. >> >> It might be good to add a "NBD_REP_ERR_NOSERVICE" error, for "server >> shutting down"? > > I think that's probably a good idea. That only works during handshake phase; you may also want to add a specific error value for use during transmission phase (maybe ECONNRESET? ENOLINK? EPIPE? ESHUTDOWN?) -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature