On Tue, Apr 12, 2016 at 10:53:57AM +0100, Alex Bligh wrote:
> Wouter,
>
> On 12 Apr 2016, at 10:20, Wouter Verhelst <[email protected]> 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
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Nbd-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nbd-general
