From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60152) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1apxd5-0001HP-LP for qemu-devel@nongnu.org; Tue, 12 Apr 2016 08:41:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1apxd1-00023P-Dx for qemu-devel@nongnu.org; Tue, 12 Apr 2016 08:41:15 -0400 Received: from barbershop.grep.be ([89.106.240.122]:47164) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1apxd1-00023H-7v for qemu-devel@nongnu.org; Tue, 12 Apr 2016 08:41:11 -0400 Date: Tue, 12 Apr 2016 14:40:55 +0200 From: Wouter Verhelst Message-ID: <20160412124055.GA15484@grep.be> References: <1460292452-1348-1-git-send-email-alex@alex.org.uk> <20160411061013.GE28660@grep.be> <4942E119-AFFA-42B4-A6DF-2BD6F729D84D@alex.org.uk> <570C059E.6090000@redhat.com> <20160412060155.GF4281@grep.be> <0D0FC6E7-F6DA-4B70-A2DD-66ADCD038CA2@alex.org.uk> <20160412092058.GA30686@grep.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [Nbd] [PATCHv8] Improve documentation for TLS List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Bligh Cc: "nbd-general@lists.sourceforge.net" , "Daniel P. Berrange" , "qemu-devel@nongnu.org" On Tue, Apr 12, 2016 at 10:53:57AM +0100, Alex Bligh wrote: > Wouter, > > On 12 Apr 2016, at 10:20, Wouter Verhelst 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