Re: [Nbd] [Qemu-devel] [PATCH 3/1] doc: Propose Structured Replies extension
- To: Eric Blake <eblake@...696...>
- Cc: "nbd-general@lists.sourceforge.net" <nbd-general@lists.sourceforge.net>, "qemu-devel@...530..." <qemu-devel@...530...>
- Subject: Re: [Nbd] [Qemu-devel] [PATCH 3/1] doc: Propose Structured Replies extension
- From: Wouter Verhelst <w@...112...>
- Date: Tue, 29 Mar 2016 20:03:14 +0200
- Message-id: <20160329180314.GA12469@...3...>
- In-reply-to: <56FABF49.8080205@...696...>
- References: <1459173555-4890-1-git-send-email-eblake@...696...> <1459223796-28474-2-git-send-email-eblake@...696...> <55B49D68-2F63-4742-9B60-F6B428ABB3E9@...872...> <56FA8F5B.8060800@...696...> <88E5F63B-B036-45C7-B2FD-B555D54E88F4@...872...> <56FA9B42.2020503@...696...> <08706CF2-6DA1-421E-827D-6C08CC08A9EA@...872...> <56FABF49.8080205@...696...>
On Tue, Mar 29, 2016 at 11:45:45AM -0600, Eric Blake wrote:
> On 03/29/2016 11:34 AM, Alex Bligh wrote:
> > I would agree. I think if it supports the structured reply semantics,
> > it should also support 'DF'. So if you know the server supports
> > structured replies, you know you can set DF on them without any
> > further requirements.
>
> Supporting DF merely transfers the burden of collection between server
> and client. I suspect that there are cases where the server does NOT
> want to support DF (because it would require the server to allocate
> memory to collect the data before sending a single structured read
> reply),
There are other ways to handle that; e.g., the server could have a
"request too large for non-fragmented read" error message. The spec
should give a minimum size that the server MUST support (which should be
reasonably large), and should state that a server MAY reply to any
request with DF set for a block larger than that minimum, with that
error.
Otherwise the client could conceivably send out heaps of requests for
(UINT32_MAX - 8) bytes with DF set and basically DoS the server.
> just as you have stated that there are cases where the client
> has an additional burden if DF is not supported. So for v2, I'm going
> to explicitly document a DF export flag, and recommend (but not require)
> that the server support it.
I'd prefer not to see that.
--
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
people in the world who think they really understand all of its rules,
and pretty much all of them are just lying to themselves too.
-- #debian-devel, OFTC, 2016-02-12
Reply to: