On 05/17/2016 10:41 AM, Richard W.M. Jones wrote: > 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? Yes. Consider a client that connects to a server that lists more than 32 exports in NBD_OPT_LIST, then the client calls (the still-experimental) NBD_OPT_INFO on each of those exports, to learn further details about each export, before finally using NBD_OPT_GO to pick the one the user likes best. That's why I wonder if we need to document a minimum cutoff at which clients should assume will always be serviced, and which servers should not treat as an attack, and whether it should be larger than 32. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature