Re: [Nbd] [Qemu-devel] [PULL 23/28] nbd: always query export list in fixed new style protocol
- To: Eric Blake <eblake@...696...>
- Cc: "nbd-general@lists.sourceforge.net" <nbd-general@lists.sourceforge.net>, Paolo Bonzini <pbonzini@...696...>, "Daniel P. Berrange" <berrange@...696...>, "qemu-devel@...530..." <qemu-devel@...530...>
- Subject: Re: [Nbd] [Qemu-devel] [PULL 23/28] nbd: always query export list in fixed new style protocol
- From: "Richard W.M. Jones" <rjones@...696...>
- Date: Tue, 17 May 2016 17:41:12 +0100
- Message-id: <20160517164112.GB1683@...696...>
- In-reply-to: <573B415E.6080208@...696...>
- References: <1455640486-6101-1-git-send-email-pbonzini@...696...> <1455640486-6101-24-git-send-email-pbonzini@...696...> <20160517095339.GD28935@...696...> <573B342E.8030208@...696...> <5ED6FB6F-5023-4833-83F9-B24BD379E2CD@...872...> <573B3E3E.60902@...696...> <20160517155820.GZ1683@...696...> <573B415E.6080208@...696...>
On Tue, May 17, 2016 at 10:05:50AM -0600, Eric Blake wrote:
> On 05/17/2016 09:58 AM, Richard W.M. Jones wrote:
> > On Tue, May 17, 2016 at 09:52:30AM -0600, Eric Blake wrote:
> >> so it might be nicer to
> >> make a change to the protocol document that instead permits current
> >> nbdkit behavior and puts the burden on clients to interoperate when
> >> NBD_OPT_LIST is not supported.
> >
> > The purpose of nbdkit is to be a server for qemu, to be a replacement
> > for qemu-nbd in cases where proprietary code cannot be combined with
> > qemu for copyright/licensing/legal reasons. So we aim to make sure we
> > can interoperate with qemu. No need to change any standards for
> > nbdkit! Clarifying standards documents is OK though.
>
> I also noticed that nbdkit forcefully rejects a client that sends more
> than 32 NBD_OPT_ commands, even though this is perfectly valid behavior
> on the part of the client. Maybe the protocol should document a
> (higher) limit on minimum number of options a client can expect to be
> serviced before the server dropping the connection because the client is
> wasting the server's time.
This, as you say, is a brake on clients that try to waste time by
sending infinite numbers of options. Is there any danger that 32 is
too small?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
Reply to: