Re: [Qemu-devel] [Nbd] [PATCHv8] Improve documentation for TLS

[Wouter Verhelst <w@uter.be>]

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