Re: [Nbd] NBD_CMD_DISC
- To: Alex Bligh <alex@...872...>
- Cc: "nbd-general@lists.sourceforge.net" <nbd-general@lists.sourceforge.net>
- Subject: Re: [Nbd] NBD_CMD_DISC
- From: Wouter Verhelst <w@...112...>
- Date: Sat, 9 Apr 2016 11:17:52 +0200
- Message-id: <20160409091752.GC19023@...3...>
- In-reply-to: <9010F687-588A-4061-A37E-A03A63E03787@...872...>
- References: <D4F43553-381E-42EE-838E-AC8729E3D356@...872...> <5705727B.1000802@...696...> <9010F687-588A-4061-A37E-A03A63E03787@...872...>
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: