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

[Alex Bligh]

Wouter,

On 12 Apr 2016, at 10:20, Wouter Verhelst <address@hidden> 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