Re: Simplified protocol?
- To: "Richard W.M. Jones" <email@example.com>
- Cc: firstname.lastname@example.org
- Subject: Re: Simplified protocol?
- From: Wouter Verhelst <email@example.com>
- Date: Tue, 12 Feb 2019 06:50:58 +0100
- Message-id: <[🔎] 20190212055058.GA10546@grep.be>
- In-reply-to: <20181115180353.GT27120@redhat.com>
- References: <CAAQgm-Jr07gTh_8_NZk8i=NByGt+43na3_okGH7iR0VyWvY9Hg@mail.gmail.com> <20181016103545.GE17471@redhat.com> <20181018095315.GB2908@grep.be> <20181115144108.GA6379@grep.be> <20181115180353.GT27120@redhat.com>
This discussion died out a bit, mostly because I have been busy
preparing for a move to Cape Town.
I'm on the plane now \o/
I've committed (but not pushed yet -- no Internet on this flight) all
the suggestions that were made. Once I remember to do so after landing,
I'll push them to github.
Feel free to remind me if you see this mail and it's not there yet ;-)
We really should finish this...
On Thu, Nov 15, 2018 at 06:03:53PM +0000, Richard W.M. Jones wrote:
> On Thu, Nov 15, 2018 at 03:41:08PM +0100, Wouter Verhelst wrote:
> > +### Baseline
> > +
> > +The following MUST be implemented by all implementations, and should be
> > +considered a baseline:
> > +
> > +- NOTLS mode
> > +- The fixed newstyle handshake
> > +- During the handshake:
> > +
> > + - the `NBD_OPT_INFO` and `NBD_OPT_GO` messages, with the
> > + `NBD_INFO_EXPORT` response.
> > + - 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)
> Could drop this, or note that it's only necessary for read/write
> > +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
> > + 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.
> This section mixes clients and servers, and I wonder if it would be
> better to separate them out?
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-p2v converts physical machines to virtual machines. Boot with a
> live CD or over the network (PXE) and turn machines into KVM guests.
To the thief who stole my anti-depressants: I hope you're happy
-- seen somewhere on the Internet on a photo of a billboard