From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41630) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b2i3b-0007vD-Dy for qemu-devel@nongnu.org; Tue, 17 May 2016 12:41:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b2i3X-0005DY-4u for qemu-devel@nongnu.org; Tue, 17 May 2016 12:41:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47473) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b2i3W-0005DO-Vc for qemu-devel@nongnu.org; Tue, 17 May 2016 12:41:15 -0400 Date: Tue, 17 May 2016 17:41:12 +0100 From: "Richard W.M. Jones" Message-ID: <20160517164112.GB1683@redhat.com> References: <1455640486-6101-1-git-send-email-pbonzini@redhat.com> <1455640486-6101-24-git-send-email-pbonzini@redhat.com> <20160517095339.GD28935@redhat.com> <573B342E.8030208@redhat.com> <5ED6FB6F-5023-4833-83F9-B24BD379E2CD@alex.org.uk> <573B3E3E.60902@redhat.com> <20160517155820.GZ1683@redhat.com> <573B415E.6080208@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <573B415E.6080208@redhat.com> Subject: Re: [Qemu-devel] [Nbd] [PULL 23/28] nbd: always query export list in fixed new style protocol List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Alex Bligh , Paolo Bonzini , "Daniel P. Berrange" , "nbd-general@lists.sourceforge.net" , "qemu-devel@nongnu.org" 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