On Sun, Oct 16, 2016 at 02:19:54PM +0100, Alex Bligh wrote:
> > On 14 Oct 2016, at 22:11, Eric Blake <ebl...@redhat.com> wrote:
> > 
> > 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.
> I think the answer there is 'fix the server' rather than work
> around it in the client.

Except we're talking here about "known buggy in-the-wild
implementations". Yes, you can fix the newer versions of the known buggy
implementations, but that doesn't help what's already out there.

< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

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