[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Nbd] NBD_CMD_DISC



On Wed, Apr 06, 2016 at 10:31:43PM +0100, Alex Bligh wrote:
> Eric,
> 
> > How will signalling help?
> > 
> > Let's consider some scenarios:
> > 
> > 0. Existing state: old client with old server; client sends CMD_DISC and
> > must not send anything else, but nothing requires whether it waits
> > around to read replies or just closes the connection early.  Old server
> > can close the connection on any error without receiving CMD_DISC, and is
> > documented to close the connection without reply even when receiving
> > CMD_DISC.  A server that has out-of-order requests doesn't even have to
> > flush those replies before disconnecting.  Furthermore, the length and
> > offset fields are documented as unspecified, so we can't even assign
> > meaning to those fields (as in "if you pass length 1, you want to wait
> > for a reply") (that's why new commands should explicitly require clients
> > to send 0 rather than unspecified).  This scenario won't change,
> > regardless of what we do for new.
> 
> 
> As far as the signalling is concerned, why not just
> 
> * Add this as a new command, NBD_CMD_SAFE_DISCONNECT.

No. There's no need, we can fix the problem without introducing yet more new
messages.

It makes sense to add new messages if that's necessary, but that doesn't seem
to be the case here.

[...]
> > In other words, I'm not seeing what value added we have in either choice
> > 2 or choice 3 (what behavior did we guarantee by extending the
> > handshake, that we cannot already get by specifying best practice that
> > server MUST reply, and client SHOULD wait for server to close connection
> > but SHOULD NOT expect the reply due to back-compat?)
> 
> This seemed quite a complicated analysis!
> 
> In short I don't think there's much you can do without (a) changing
> client behaviour and (b) changing server behaviour, so my assumption
> is you need another command (which is better than changing the
> meaning of the current command via signalling which was what
> I proposed) to get any benefit.

Disagree.

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



Reply to: