On Sun, Oct 16, 2016 at 02:19:54PM +0100, Alex Bligh wrote:
>
> > On 14 Oct 2016, at 22:11, Eric Blake 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 sh
> On 14 Oct 2016, at 22:11, Eric Blake 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 sen
On Fri, Oct 14, 2016 at 04:36:38PM -0500, Eric Blake wrote:
> On 10/14/2016 04:02 PM, Eric Blake wrote:
>
> > /**
> > * Consume data from a socket that we don't want
> > *
> > - * @param f a file descriptor
> > + * @param c the client data stream
> > * @param buf a buffer
> > * @param len
On 10/14/2016 04:02 PM, Eric Blake wrote:
> /**
> * Consume data from a socket that we don't want
> *
> - * @param f a file descriptor
> + * @param c the client data stream
> * @param buf a buffer
> * @param len the number of bytes to consume
> * @param bufsiz the size of the buffer
> @
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
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
