Re: [Nbd] [PATCH 3/1] doc: Propose Structured Replies extension
- To: Alex Bligh <alex@...872...>
- Cc: "nbd-general@lists.sourceforge.net" <nbd-general@lists.sourceforge.net>, Eric Blake <eblake@...696...>, "qemu-devel@...530..." <qemu-devel@...530...>
- Subject: Re: [Nbd] [PATCH 3/1] doc: Propose Structured Replies extension
- From: Wouter Verhelst <w@...112...>
- Date: Wed, 30 Mar 2016 00:45:17 +0200
- Message-id: <20160329224517.GB5466@...3...>
- In-reply-to: <044DDAC6-039B-4C29-A83F-445B4E68AB0D@...872...>
- References: <1459173555-4890-1-git-send-email-eblake@...696...> <1459223796-28474-2-git-send-email-eblake@...696...> <20160329175319.GA8628@...3...> <56FAC823.8070206@...696...> <20160329185157.GC12469@...3...> <C18AAD54-A6E4-43D5-AA8B-481E8D9DF752@...872...> <56FADEFA.8070207@...696...> <7E85EC50-7289-43CA-8DCC-D933B4B28A22@...872...> <20160329210545.GB19767@...3...> <044DDAC6-039B-4C29-A83F-445B4E68AB0D@...872...>
On Tue, Mar 29, 2016 at 11:05:38PM +0100, Alex Bligh wrote:
>
> On 29 Mar 2016, at 22:05, Wouter Verhelst <w@...112...> wrote:
>
> >>> For all remaining existing commands, that is just more overhead on the
> >>> wire. The existing non-structured replies do not send any data; they
> >>> are 16 bytes each (only NBD_CMD_READ sends more than 16 bytes in one
> >>> reply). But your proposal inflates that to a minimum of 20 bytes (if
> >>> length is 0) or longer (if an error is set). I'm still strongly in
> >>> favor of keeping the existing non-structured replies to commands that
> >>> don't have to return data.
> >>
> >> I was saying that should be up to the server. If the server wants to
> >> write something easily decodable (and easier to maintain) at the expense
> >> of a few more bytes on the wire, then let it. If it wants to use
> >> unstructured replies occasionally, that's fine.
> >
> > In adding that flexibility, you're adding more code paths on the client
> > (that need to be tested, etc), for (IMO) little benefit.
> >
> > I would instead prefer to specify per command whether the reply is going
> > to be structured or not, and only have the read command be a special
> > case were both are possible, for backwards compatibility only. That way,
> > it can eventually be deprecated, too.
>
> I guess this is what comes of doing more NBD server work than client
> work :-) I'd look at it the other way around and say that only one
> code path is being exercised on the server,
Yes, but both code paths need to _exist_, which isn't the case with
having only one legal reply type per request type. The server just needs
to send header X for replies A, B, C, and header Y for replies D, E, F.
Forming the header is part of producing the reply type, and will be the
same for every conversation -- except for read replies, where it could
possibly be either (but that can't be avoided).
> and that having multiple types of reply depending on command builds
> fragility into the protocol.
I'd think that having the legal reply type depend on context is actually
more fragile.
> If you want no choice in response type for the server for any given
> session (i.e. code path minimisation on the client) my preference would
> be what Eric didn't like, i.e. always send structured replies for
> all commands if you negotiate structured replies, else always send
> unstructured replies.
Doing that requires performing a lookup to negotiated state (and a code
branch) for every response type that can possibly be structured or
nonstructured, and introduces exactly the two code paths that I think
should be avoided.
With what I'm suggesting, this will still be required for read requests,
but only while we retain backwards compatibility.
> We're talking an overhead of 8 bytes here (flags & error offset);
> somehow I suspect the time to transmit 8 bytes is going to be
> negligible compared to disk time or the rest of the network tx/rx
> time.
Sure, but I'm not worried about that.
--
< 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: