Wouter, On 12 Apr 2016, at 10:20, Wouter Verhelst <w...@uter.be> wrote:
> To summarize, there are three ways for the connection to end: > > - The client wishes to end the session, and sends the appropriate > termination message (OPT_ABORT or CMD_DISC). This is a normal > disconnect. > - Either peer violates a MUST in the spec, and the other side doesn't > know how to handle the resulting inconsistency. The only proper > solution at that point is to drop the connection, but that's only > because there's really nothing else we *can* do. This is an abnormal > disconnect. > - The server wishes to terminate the session. There isn't actually a > message for this, so it also results in an abnormal disconnect. The last case includes (e.g.) 'NBD_OPT_EXPORT_NAME' issued to a non-existing mount) > Perhaps we could state that the server can send a message (offset 0, > length 0, handle 0, error EINTR) when it wants to terminate the session > for whatever reason (e.g., because it's being restarted). I think that will make clients' life harder. Most clients don't expect messages from the server which aren't replies, so I can see them treating it as a reply to the next message they issue, or getting into some horrible blocking situation. (Also please don't use EINTR - that implies you can retry. ETERM?) > Originally, there were a number of termination points where we could > drop the connection without further explanation. It was a mess, because > it resulted in confusing messages (e.g., the server would produce error > messages in system logs for every disconnect because it couldn't > distinguish between clean disconnects and unclean disconnects). > > I don't want to go there again. I think what we should probably say is this (wording needs tweaking I know): * One side MAY drop the connection if the other end violates a MUST condition. * The server MUST drop the connection in the 'no way out' situations during the negotiation phase (error on NBD_OPT_EXPORT_NAME, error in negotiating text). * As protocol authors we should minimise the number of 'no way out' situations. * The server SHOULD NOT otherwise drop the connection. It can wait and error the next command. Clearly there are situations where this is going to happen (e.g. server shutdown). * If the server does need to drop the connection, it SHOULD wait until there are no commands in-flight in transmission mode, it possible. * If he client is going to drop the the connection, then other than in the event of a protocol violation or a 'no way out' situation (e.g. TLS negotiation fails), it MUST use NBD_CMD_DISC or NBD_OPT_ABORT * We should tidy up the semantics and descriptions of NBD_CMD_DISC and NBD_OPT_ABORT, viz replies or not to the latter, shutting down TLS properly etc. -- Alex Bligh
