On 29 Mar 2016, at 22:05, Wouter Verhelst <w...@uter.be> 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, and that having multiple types of reply depending on command builds fragility into the protocol. 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. 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. -- Alex Bligh
