Re: [Nbd] [PATCHv8] Improve documentation for TLS
- To: Wouter Verhelst <w@...112...>
- Cc: "nbd-general@lists.sourceforge.net" <nbd-general@lists.sourceforge.net>, "Daniel P. Berrange" <berrange@...696...>, "qemu-devel@...530..." <qemu-devel@...530...>
- Subject: Re: [Nbd] [PATCHv8] Improve documentation for TLS
- From: Alex Bligh <alex@...872...>
- Date: Tue, 12 Apr 2016 10:53:57 +0100
- Message-id: <ACE271FF-7D80-48CD-A044-780AC6AC4EF9@...872...>
- In-reply-to: <20160412092058.GA30686@...3...>
- References: <1460292452-1348-1-git-send-email-alex@...872...> <20160411061013.GE28660@...3...> <4942E119-AFFA-42B4-A6DF-2BD6F729D84D@...872...> <570C059E.6090000@...696...> <ECBAC2D7-160B-4E86-A469-00594CB45910@...872...> <20160412060155.GF4281@...3...> <0D0FC6E7-F6DA-4B70-A2DD-66ADCD038CA2@...872...> <20160412092058.GA30686@...3...>
Wouter,
On 12 Apr 2016, at 10:20, Wouter Verhelst <w@...112...> 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
Reply to: