On 10/14/2016 04:02 PM, Eric Blake wrote:
> Any client attempting to probe support for a new option, such as
> NBD_OPT_STARTTLS or NBD_OPT_GO, with plans to do a graceful
> fallback to older methods, will fail in its attempt if the server
> does not ignore the length field and potential payload of the
> unrecognized (or rejected) option, because the server will then
> be reading out of sync and not see the client's magic for the
> next option.  This bug has been latent in the reference
> server since commit 626c2a3 in 2012, even though it is EXACTLY
> the bug that NBD_FLAG_FIXED_NEWSTYLE was designed to prevent.

Given that we have 4 years of buggy servers that will fail to react
correctly to NBD_OPT_GO and friends, is it worth enhancing the docs to
suggest that a robust client should be prepared for (buggy) servers that
mistakenly hang up after sending an NBD_OPT_ERR_UNSUP, and try
reconnecting to the server while avoiding the command that failed on the
previous run?  Eventually, buggy servers will disappear, so we can't
mandate that clients take that extra step, but since it is a very common
problem at the present, it might help client implementations to be aware
of it.  Then again, most client implementors read this list, so
documenting it in the protocol may be overkill.

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Nbd-general mailing list

Reply via email to