Re: Simplified protocol?
On Thu, Nov 15, 2018 at 08:59:56AM -0600, Eric Blake wrote:
> On 11/15/18 8:41 AM, Wouter Verhelst wrote:
> > + - the `NBD_OPT_INFO` and `NBD_OPT_GO` messages, with the
> > + `NBD_INFO_EXPORT` response.
>
> Of the required items, this is probably the most recent addition to the
> standard (and therefore the most likely to be missing from older
> implementations); should we mention that clients should be prepared to fall
> back to NBD_OPT_EXPORT_NAME, or are we sufficiently long enough into the
> existence of this addition (and with multiple implementations that DO
> support it) to now make it mandatory?
My train of thought was something along the latter lines, yes. Even so,
I do mention the fact that NBD_OPT_EXPORT_NAME is necessary for older
implementations in the "maximum interoperability" section. I think
that's a reasonable tradeoff, but don't feel too strongly about it; if
others disagree, I'm happy to move OPT_INFO/OPT_GO to "Future
considerations" and mention NBD_OPT_EXPORT_NAME here.
> > + - Servers that receive messages which they do not implement MUST
> > + reply to them with `NBD_OPT_UNSUP`, and MUST NOT fail to parse
> > + the next message received.
> > + - the `NBD_OPT_ABORT` message, and its response.
> > + - the `NBD_OPT_LIST` message and its response.
> > +
> > +- During the transmission phase:
> > +
> > + - Simple replies
> > + - the `NBD_CMD_READ` message (and its response)
> > + - the `NBD_CMD_WRITE` message (and its response)
>
> I'd add clarification: NBD_CMD_WRITE is optional if the server only exports
> read-only images.
In that case the server should still be able to understand them, and
reply with the correct error message.
However, a client that doesn't want to write does indeed not need to
implement it.
> > + - the `NBD_CMD_DISC` message
>
> Do we want to require that servers SHOULD fail unknown commands with EINVAL?
> Or are okay with stating that a client sending a non-negotiated command is
> the client's fault, and it deserves whatever happens at the server.
Yeah, I think so.
On that note, the three commands that I mention in this section are the
only three commands that don't have a negotiation flag (i.e., a client
may assume they're always available), so I think it's reasonable to make
them be part of the baseline.
> > +### Maximum interoperability
> > +
> > +Clients and servers that desire maximum interoperability SHOULD
> > +implement the following features:
> > +
> > +- TLS-encrypted communication, which may be required by some
> > + implementations or configurations;
> > +- Servers that implement block constraints through `NBD_INFO_BLOCK_SIZE`
> > + and desire maximum interoperability SHOULD NOT require them.
> > + Similarly, clients that desire maximum interoperability SHOULD
> > + implement querying for block size constraints. Since some older
> > + clients default to a block size of 1024 bytes, implementations
>
> s/1024/512/
Actually, nbd-client defaults to 1024, and has done that for a *long*
time :-)
That's probably not a good idea, but it is a clean multiple of 512, so
should be fine for these purposes.
> > + desiring maximum interoperability MAY default to that size.
> > +- Clients or servers that desire interoperability with older
> > + implementations SHOULD implement the `NBD_OPT_EXPORT_NAME` message in
> > + addition to `NBD_OPT_INFO` and `NBD_OPT_GO`.
> > +- For data safety, implementing `NBD_CMD_FLUSH` and the
> > + `NBD_CMD_FLAG_FUA` flag to `NBD_CMD_WRITE` is strongly recommended.
>
> Is it worth mentioning 32M as a reasonable max packet size to
> NBD_CMD_READ/WRITE?
Good point, didn't think of that; thanks for pointing that out.
--
To the thief who stole my anti-depressants: I hope you're happy
-- seen somewhere on the Internet on a photo of a billboard
Reply to: