Re: [Nbd] NBD_CMD_DISC

[Wouter Verhelst <w@...112...>]

On Sat, Apr 09, 2016 at 03:12:00PM -0600, Eric Blake wrote:
> On 04/09/2016 03:51 AM, Alex Bligh wrote:
> > The space of available flags is limited. Why use one up? Before you
> > say 'well you're using a flag bit anyway', I'm using a flag bit
> > from the server to say it supports this, which we'd need on Eric's
> > proposal too (I think he converted over to the command approach).
> > 
> >> We can just say that the client MUST ensure that enough time has elapsed
> >> for the TLS layer to pass the NBD_CMD_DISC command on to the server,
> > 
> > How would the client know that? I'm using Go's TLS library, and there is
> > no way (as far as I can tell) to ensure that.
> 
> Likewise - if it's qemu's fault for not flushing the outgoing queue,
> then what's the right way to get that NBD_CMD_DISC flushed?

I'm not sure it's necessary for the protocol discussion to figure out
which API a particular implementation should be using. If an
implementation uses write buffers, it should ensure that those buffers
are flushed before dropping the connection.

[...]
-- 
< 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