Re: [Nbd] [PATCH] server: Read client's length data before next option
- To: Alex Bligh <alex@...872...>
- Cc: "nbd-general@lists.sourceforge.net" <nbd-general@lists.sourceforge.net>
- Subject: Re: [Nbd] [PATCH] server: Read client's length data before next option
- From: Wouter Verhelst <w@...112...>
- Date: Mon, 17 Oct 2016 21:55:07 +0200
- Message-id: <20161017195507.yv7wp3vjkqbldipd@...3...>
- In-reply-to: <42C35145-5662-4153-B59E-5C2133184F02@...872...>
- References: <1476478938-8121-1-git-send-email-eblake@...696...> <7d976adf-193e-1bae-ac2a-98f6480fb640@...696...> <42C35145-5662-4153-B59E-5C2133184F02@...872...>
On Sun, Oct 16, 2016 at 02:19:54PM +0100, Alex Bligh wrote:
>
> > On 14 Oct 2016, at 22:11, Eric Blake <eblake@...696...> 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
Reply to: