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

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

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: