On Tue, Apr 12, 2016 at 10:53:57AM +0100, Alex Bligh wrote:
> 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.
Right, that sounds good.
--
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
people in the world who think they really understand all of its rules,
and pretty much all of them are just lying to themselves too.
-- #debian-devel, OFTC, 2016-02-12
