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
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Mobile security can be enabling, not merely restricting. Employees who bring their own devices (BYOD) to work are irked by the imposition of MDM restrictions. Mobile Device Manager Plus allows you to control only the apps on BYO-devices by containerizing them, leaving personal data untouched! https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
