Eric, > How will signalling help? > > Let's consider some scenarios: > > 0. Existing state: old client with old server; client sends CMD_DISC and > must not send anything else, but nothing requires whether it waits > around to read replies or just closes the connection early. Old server > can close the connection on any error without receiving CMD_DISC, and is > documented to close the connection without reply even when receiving > CMD_DISC. A server that has out-of-order requests doesn't even have to > flush those replies before disconnecting. Furthermore, the length and > offset fields are documented as unspecified, so we can't even assign > meaning to those fields (as in "if you pass length 1, you want to wait > for a reply") (that's why new commands should explicitly require clients > to send 0 rather than unspecified). This scenario won't change, > regardless of what we do for new. As far as the signalling is concerned, why not just * Add this as a new command, NBD_CMD_SAFE_DISCONNECT. * Add a transmission flag NBD_FLAG_SEND_SAFE_DISCONNECT which indicates whether the server understands a safe disconnect command. If this is set, a client that knows how to issue a NBD_CMD_SAFE_DISCONNECT should use this instead of NBD_CMD_DISCONNECT When the client sends NBD_CMD_SAFE_DISCONNECT, it must be the last command it sends. If it is sent when there are inflight requests, the client recognises the results of those inflight requests may be lost. The server should do a flush prior to replying to the NBD_CMD_SAFE_DISCONNECT. If the client sends a NBD_CMD_SAFE_DISCONNECT and gets a TCP connection reset (or equivalent) subsequently, it can assume the connection was shut down safely even if it does not receive the reply (this copes with the TCP layer eating the reply). If the client wants to be 'doubly safe', it can wait until all the inflight requests have been replied to, send a NBD_CMD_FLUSH, wait for the reply, then send an NBD_CMD_SAFE_DISCONNECT. > In other words, I'm not seeing what value added we have in either choice > 2 or choice 3 (what behavior did we guarantee by extending the > handshake, that we cannot already get by specifying best practice that > server MUST reply, and client SHOULD wait for server to close connection > but SHOULD NOT expect the reply due to back-compat?) This seemed quite a complicated analysis! In short I don't think there's much you can do without (a) changing client behaviour and (b) changing server behaviour, so my assumption is you need another command (which is better than changing the meaning of the current command via signalling which was what I proposed) to get any benefit. -- Alex Bligh
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail