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

[Wouter Verhelst <w@uter.be>]

On Tue, Apr 12, 2016 at 08:47:49AM +0100, Alex Bligh wrote:
> 
> On 12 Apr 2016, at 07:01, Wouter Verhelst <w@uter.be> wrote:
> 
> > hat doesn't mean OPT_ABORT not having a reply is necessarily a good
> > idea. Since it's only used by reference nbd-client in just one use case
> > at this point, I don't think it's particularly bad to change the
> > definition to say that the server SHOULD send a reply (NBD_REP_ACK),
> > upon which the server drops the connection.
> > 
> > The client should probably wait for that too, and not close its socket
> > until either it gets a zero read (indicating that the server closed it
> > already) or it gets an NBD_REP_ACK from the NBD_OPT_ABORT message.
> 
> Yeah. That way would be a safe change (as the worst that can
> happen is the client thinks the server has rudely dropped
> the connection).

Right.

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.

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).

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.

-- 
< 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