qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Nbd] [PULL 23/28] nbd: always query export list in fix


From: Richard W.M. Jones
Subject: Re: [Qemu-devel] [Nbd] [PULL 23/28] nbd: always query export list in fixed new style protocol
Date: Tue, 17 May 2016 17:41:12 +0100
User-agent: Mutt/1.5.20 (2009-12-10)

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 via email to

[Prev in Thread] Current Thread [Next in Thread]