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